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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aREI6ZdvJmsZ-J6U%40petertodd.org.
signature.asc
Description: PGP signature
