pull down to refresh
@Murch
stacking since: #127838
100 sats \ 1 reply \ @Murch 17h \ parent \ on: Are you really a Bitcoiner? bitcoin_beginners
Would you give some examples of how "the protocol is being captured"? I see a bunch of suits starting treasury companies and ETFs, but the influx of protocol development must have eluded me.
You're projecting your personal philosophy on all bitcoiners in what amounts to a True Scotsman fallacy. Meh.
Real Bitcoiners post at least one question or answer on Bitcoin Stack Exchange every day!!!1
See what I did there?
If Knots were to introduce soft fork rules that forbid some types of data transactions at the consensus level, they would probably have some method for activating this soft fork. If the activation fails to get broad support, they would be forced to decide to either create a minority fork that enforces the new consensus rules, or to "take the loss" and forego enforcing the new rules.
Mostly right, a few comments:
- The overhead to publishing data in an Inscription is bigger because you first have to make a commitment in the output and then create a P2TR scriptpath spend to reveal the inscription. After paying for that, the data is subject to the witness discount, so the data bytes only weigh one 1 weight unit. OP_RETURN outputs are not subject to the witness discount, so they weigh 4 weight units, but they have less overhead. So, smaller data payloads are slightly less expensive to be published in OP_RETURN than in Inscriptions, larger data payloads are cheaper to publish in Inscriptions. The border between the two is around 144 bytes. So, this change would make it slightly cheaper to publish data payloads of up to 144 bytes, and make no difference for larger payloads as they would continue to be published as inscriptions, assuming the sender optimizes for cost.
- Since hashes and public keys mostly look like random data, people have been using them to publish very small chunks of data since pretty much forever. Such payment outputs cannot be discarded, because they are theoretically spendable, and if one were spent, it would split the network between nodes that accept the transaction and those that do not. Therefore they are permanent additions to the UTXO set, which represents the minimal state that every full node must retain to validate transactions. For extremely small data amounts, the overhead of fake payment outputs is similar to OP_RETURN outputs, but it’s slightly more expensive. By dropping the limit on OP_RETURN outputs, it is always be cheaper to publish data into an OP_RETURN than to publish it into a fake payment output. OP_RETURN outputs do not need to be stored in the UTXO set, because they are provably unspendable.
So far their reaction to the evidence has been to continue claiming that filters work. I have not seen anyone actually propose a fork over this, but I doubt that a hard fork would be necessary. Forbidding things only takes a soft fork.
100% Knots would be insufficient if the people that want bare multisig directly hand them to miners who include them in blocks.
In case you missed it. The chart appears to compare by volume consumed. 30 ml is one espresso shot, but about 1/8th of a small cup of coffee.
Yeah, the actual monetary inflation is very close to my estimate beforehand — it only is affected by the actual number of blocks found.
What do you mean with "individual inflation"?
I also lived Ready Player One. The Wikipedia article makes the sequel sound like a dud, though.
Just like Matrix—too bad they never made a sequel. :p
Would be pretty awesome, if people worked on bills in public in a git repository just like an opensource project, wouldn’t it? And why not, they’re public servants.
Taiwan has adopted a few such ideas in the past years. I listened to this podcast a while back: https://www.eff.org/deeplinks/2024/02/podcast-episode-open-source-beats-authoritarianism
Bitboy made that logo in November 2010: https://bitcointalk.org/index.php?topic=1631.0
The blog post by scronty is full of crap. Tried to gain some fame for being part of Satoshi with that silly tale.