From: Peter Todd <pete@petertodd.org>
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: Sun, 9 Nov 2025 21:34:33 +0000 [thread overview]
Message-ID: <aREI6ZdvJmsZ-J6U@petertodd.org> (raw)
In-Reply-To: <bJL7UshcsXUpiQiC85dQeafQrRvtovH1aRcUxggjD1S09Md9qWHi9GpJOBdcPGq2NNQMK2XK-REMVlWjHLkh3aKUIktnYQccUWqg0DHgNXc=@proton.me>
[-- Attachment #1: Type: text/plain, Size: 3377 bytes --]
On Sat, Nov 08, 2025 at 12:51:49AM +0000, dathonohm via Bitcoin Development Mailing List wrote:
> 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.
I see that a block-height-based activation date has been proposed,
approximately Feb 1st 2026 depending on how fast blocks are mined.
Your BIP does not discuss the fact that such a UASF activation is highly likely
to lead to two different coins, the unmodified chain accepted by the majority
of hash power, and the minority hash power fork. If you thought you could get
supermajority hashpower support, you would have simply proposed a hash-power
activation, e.g. the 95% treshold used by my own BIP-65 soft-fork,
CheckLockTimeVerify. Clearly you do not believe you can get supermajority
hashpower support.
Even without commenting on the desirability of such a fork, you need to openly
discuss it in your BIP and explain how the community will be able to deal with
it. For example, how wallets can safely "split" coins between either side of
the fork, and how you intend to modify Bitcoin addresses so people don't
accidentally send coins to the wrong side.
Of course - again without commenting on the desirability of this fork - I
personally believe that such a short timeframe is utterly absurd for a UASF
with no miner activation mechanism at all.
> This update addresses several concerns from the previous draft:
The BIP continues to fail to answer obvious questions. For example the very
first paragraph in your technical rational states:
> ''Why limit scriptPubKeys to 34 bytes?'''
>
> scriptPubKeys must be stored indefinitely in quick-access memory (often RAM) by all fully validating nodes.
> It generally cannot be pruned.
> It is also a direct cost to the sender rather than the receiver. For these reasons, modern usage is all 34 bytes or smaller in practice:
> actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash.
Obviously, entities that actually need to publish data in scriptPubKey's will
simply use more of them instead of OP_Return. You write this section as though
your argument is an actual rationale. But clearly, this rational is simply
bogus.
You're actual rationale appears to be simply a moral one: you want to put
restrictions on transactions to send a *message* that use of Bitcoin for data
publishing is wrong. Even though otherwise you appear to admit that this BIP
will not in fact provide any real technical obstacle to publishing data in
Bitcoin (as me publishing the previous draft in the chain itself proved).
Unless you have an actual technical justification, arguments such as the above
are highly dishonest and need to be removed from your BIP.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/aREI6ZdvJmsZ-J6U%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-11-09 23:33 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
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 [this message]
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=aREI6ZdvJmsZ-J6U@petertodd.org \
--to=pete@petertodd.org \
--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