Hi all - BIP repo maintainers [requested](https://github.com/bitcoin/bips/pull/2017#issuecomment-3462134337) that I update this list before pushing a significant change, so I am doing that now.
Please consider this my formal request for the BIP PR to be unlocked so that discussion can resume. 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. I welcome any and all feedback, as I think this proposal or something similar to it stands an excellent chance of gaining consensus and activating, and I think if that happens, it could be curative for the Bitcoin community. Thanks again for all of your feedback and support, it means a lot. Sincerely, Dathon On Wednesday, October 29th, 2025 at 8:57 PM, Erik Aronesty <[email protected]> wrote: >> Case law in the USA regarding illegal content has always rested squarely on >> those who: > > 1 - provide broad public access, in this case a company like OpenSEA (which > has had to block content) > 2 - the original author > > if punishing "relays" was a thing, then every CISCO router, SMTP relay and > DISCORD server that provided access would be in court all day long > > instead, it's the users of the illegal data and the publishers that actually > wind up in trouble - not the internet providers > > the bitcoin ledger is neither a browser or web server, nor is it an image > uploader. there is zero ability to view images built into the system > > and even if it was > > the purpose of this software is to be a distributed and effectively > uncensorable ledger. > > hopefully it doesn't change because someone launched a meme campaign with > vague threats of legal action > > if a transaction has /no reasonable expectation of being mined/ (too > expensive to validate, too large, too low fees), there's also no reason to > relay it > > this is probably the best way to set policy > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAJowKgKBBa%2BvD%3D5X0VMV2OFiBBM23Ok6nmvfoLTr8fia141%3DFQ%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/bJL7UshcsXUpiQiC85dQeafQrRvtovH1aRcUxggjD1S09Md9qWHi9GpJOBdcPGq2NNQMK2XK-REMVlWjHLkh3aKUIktnYQccUWqg0DHgNXc%3D%40proton.me.
bip-????.mediawiki
Description: Binary data
