From: Greg Maxwell <gmaxwell@gmail.com>
To: dathonohm@proton.me
Cc: Erik Aronesty <erik@q32.com>,
Antoine Riard <antoine.riard@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork
Date: Sat, 8 Nov 2025 15:38:16 +0000 [thread overview]
Message-ID: <CAAS2fgQy+qiRv=wGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g@mail.gmail.com> (raw)
In-Reply-To: <bJL7UshcsXUpiQiC85dQeafQrRvtovH1aRcUxggjD1S09Md9qWHi9GpJOBdcPGq2NNQMK2XK-REMVlWjHLkh3aKUIktnYQccUWqg0DHgNXc=@proton.me>
[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]
On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development Mailing
List <bitcoindev@googlegroups.com> 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4937 bytes --]
next prev parent reply other threads:[~2025-11-08 15:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-25 20:43 dathonohm via Bitcoin Development Mailing List
2025-10-26 20:47 ` Jameson Lopp
2025-10-27 4:22 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 12:14 ` Jameson Lopp
2025-10-27 16:35 ` TheWrlck
2025-10-26 22:27 ` Peter Todd
2025-10-27 3:41 ` Jal Toorey
2025-10-27 17:27 ` Max
2025-10-27 4:08 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 18:29 ` Kyle Stout
2025-10-27 19:56 ` Greg Maxwell
2025-10-28 5:13 ` dathonohm via Bitcoin Development Mailing List
2025-10-30 0:31 ` Antoine Riard
2025-10-30 2:43 ` Erik Aronesty
2025-11-08 0:51 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 3:43 ` Edil Guimarães de Medeiros
2025-11-08 9:30 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List
2025-11-08 15:38 ` Greg Maxwell [this message]
2025-11-08 16:40 ` Daniel Buchner
2025-11-08 17:55 ` Chris Riley
2025-11-08 21:02 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 21:39 ` Greg Maxwell
2025-11-09 20:07 ` dathonohm via Bitcoin Development Mailing List
2025-11-11 7:43 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List
2025-11-11 16:23 ` Greg Maxwell
2025-11-09 1:21 ` Murch
2025-11-09 20:56 ` onyxcoyote
2025-11-09 21:34 ` Peter Todd
2025-11-10 19:46 ` Lucas Barbosa
2025-10-28 9:16 ` /dev /fd0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgQy+qiRv=wGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g@mail.gmail.com' \
--to=gmaxwell@gmail.com \
--cc=antoine.riard@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=dathonohm@proton.me \
--cc=erik@q32.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox