The Reduce Data Temporary Soft Fork was proposed pretty much two weeks ago, and now here seems to be a new proposal by dathan ohm.
There is also a mailing list post.
This update addresses several concerns from the previous draft:
- "Funds confiscation": due to the presence of UTXOs that would be made temporarily unspendable by this proposal, commenters were concerned that this would set a precedent of "confiscation". This new draft resolves this concern by adding a UTXO height check to make sure only UTXOs that are created while the softfork is active will be made temporarily unspendable. The "OP_IF in Tapscript" and "257-byte control block limit" were the two main proposed rule changes that caused concern here.
- "This doesn't block all possible methods of arbitrary data insertion": This was already addressed in the previous draft, but to reiterate: this proposal's goal is not to block all methods of arbitary data insertion, just the most commonly abused ones.
- "Blocks other softfork upgrades while active": This was also addressed in the original draft, but to reiterate: it's unlikely that any softfork upgrades will be ready to activate within one year anyway, so this doesn't matter much. But also, the fact that this softfork expires creates an opportunity to activate a more permanent and elegant upgrade that turns on what the community wants, while continuing to reject data storage as a supported use case, after one year.
- "Reactive deployment risks": These concerns have been addressed by removing the reactive deployment method entirely. I still think activating this softfork is a matter of some urgency, but I think it still achieves its goals if we move steadily towards activation within a few months.
- "Missing code": The code is now public here: https://github.com/UASF/bitcoin/tree/29.2.knots20251010%2BBIP444 (please note that, while there are references to "BIP-444" in the code, that is just a placeholder and I will update it to whatever number the BIP editors decide).
- "Temporary expiry risks": "Requires another consensus change before expiry or rules lapse": Yes, as stated in <3>, the community will have to come together in a year either to extend these rules (which shouldn't be difficult), or to activate something more permanent and less blunt. The expiry will not be a hardfork, contrary to some claims I've seen, because opting into this deployment means opting into the expiry as well, so old nodes will follow new ones onto the unrestricted chain
- "Legal/process/conflict-of-interest concerns": all language about legal risks has been stripped from the BIP.
It takes me a very long time to read through and digest code, but perhaps some stackers are interested to have a look.
