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.