On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development Mailing List <[email protected]> wrote:
> > 1. "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. > > That doesn't address the confiscation problem (although any reduction in the restriction does reduce it), as there likely exist chains of not yet confirmed (and potentially timelocked) transactions that involve violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren't. It's unclear to me why you haven't yet understood this point. I don't think this concern was in any way limited to the control block of op_if components either, essentially every aspect of the proposal has confiscation issues. Another issue raised which you have not mentioned is that prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement. Will you be correcting the record on the true authorship of this work and on whose behalf its being performed? > "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. Would you then agree that this proposal will fail at its stated purpose, particularly with respect to concerns about potentially 'unlawful' material? As that concern as expressed has a threshold of "any at all" and could just as well be performed via a "less commonly abused" path? Would you also agree the same for essentially all other forms-- that they'd simply made a few line of code changes and then evade these restrictions? In light of that, how would the very real and significant reductions in intentional functionality (such as efficient "few of dozens" multisigs or other such constructs) be justified? How could the confiscation risk be justified? How could the deployment costs be justified? How could the "policy risk" be justified? (E.g. that bitcoin could be driven or forced in to an endless sequences of 'update' blocking actions, each carrying its own risk and disruptions) Although your description of changes is vague and it's not possible to tell for sure without seeing the actual updates-- I don't think your suggested revisions will move your proposal off from having essentially zero risk of adoption, and if it were adopted (which I think is unlikely) I think it's a certainty that there would be a countering fork to continue a Bitcoin without these poorly justified (even essentially useless) restrictions. -- 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/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.com.
