Rusty Russell

I made enchiladas, where N = 8.

Token bucket filter for the win: most occasional posters are not *regular*.

Finally read BIP-54 (mirror at https://bips.dev/54/) and it is straightforward,minimal and thorough. At this point I can endorse it as a good idea and worth doing. There's no rush, but I am looking forward to activation.

I am loving listening to the Pieter Wuille interview. It's clear from motivation to technical explanation, and Stephan shepherds the discussion masterfully! https://stephanlivera.com/episode/730/

Here are two of my favorites: Vaults, where your coins can only be spent with a delay, so if you see your coins move and it wasn't you, you can force them to emergency backup address instead. Lightning and other layer 2 protocols get simpler and more efficient. In the case of Ark, it sheds some cases where you need to trust the provider. These ideas came up long after the script stuff was disabled. There are certainly more

https://json5.org/ I *want* JSON5 to take over the world because it allows trailing commas. But I have to accept that most people are just excited because it sounds like a boy band.

Each Bitcoin you send has a "script" which says how it can be spent: usually just a signature for the owner's key. There's lots of other stuff yo can do though. Back in 2010, Satoshi ripped out a pile of Bitcoin script because it had no limits and you could make coin spends which would blow up nodes. Putting reasonable limits in means we can put all those back, so you can make your Bitcoin do fancy tricks, if you want (need?).

https://github.com/bitcoin/bips/pull/2118 Finally, the PR to assign BIP numbers to the first two BIPs of the "script restoration quartet". Here's the corresponding bitcoin-dev the mailing list post: Hi all, I've submitted a PR to the BIPs repo to merge the first two drafts of the previously posted[1] "A Bitcoin Scripting Proposal BIP Quartet": https://github.com/bitcoin/bips/pull/2118 The only substantive change since the last discussion is that the costs have increased for some operations (hashing and copying bytes), as a result of benchmarking on a wider array of machines[2]. This follows our conservative approach to make the worst-case validation times no worse than they are presently, on any viable hardware. The remaining two BIPs (OP_TX, and new opcodes) are not submitted: they are mainly useful to provide a roadmap what functional gaps remain after the script extensions, and do not have full implementations. Cheers! Rusty & Julian. [1] https://groups.google.com/g/bitcoindev/c/GisTcPb8Jco/m/8z… [2] https://github.com/jmoik/varopsData

Kick the can down the road? I cannot see the appeal from any direction...

You are minmaxing again. Enjoy the scenery and sense of wonder!

You don't understand. There are no rulers. You cannot prevent people doing stupid things. This is fundamental, and hardest to emotionally grasp. You can, however, use existing incentives to minimize the damage to the system. That's why OP_RETURN is standard: people used to embed data in outputs, which have to be stored forever and be available for fast lookup. OP_RETURN is straight harm prevention. Luke used the coinbase input to embed prayers, which has the same effect, but you have to be a miner. The only strong incentive is fees. That's unvarnished capitalism, which has the benefit of being *simple* and *distributed*, but it's not *fair*. Assholes with more money than me are a real problem! But not one we know how to solve in a decentralized system.

To check the signature, you hash the transaction. So the only cost that OP_RETURN is doing is the cost to download and hash it. If it's data in the annex you don't even need fi hash it, just download it.