Hi everyone, Some previously raised points regarding BIP 54 have come up again recently, and i would like to address them here for the record.
The first one is Luke Dashjr's comment [0] that giving meaning to the coinbase transaction nLockTime is undesirable as it's the ideal position for an extranonce. But this extranonce only enables a theoretical optimisation for a non-bottleneck operation: saving an ASIC controller one SHA256 of the coinbase transaction. Besides, committing to block height in nLockTime is the most elegant way to guarantee coinbase transaction uniqueness without relying on non-portable BIP 30 validation. The field is intended for this purpose and timelock validation neatly guarantees historical uniqueness. Furthermore, it makes it possible to extract the block height from the coinbase transaction without having to parse Script, and enables constant-time proofs of block height [1]. The second one is Jeremy Rubin's comment [2] that we may want to keep 64-byte transactions, that the validity "seam" this introduces may bring unforeseen complexity [3] in the design of smart contracts, and that it might be preferable to introduce a whole new (sparse) Merkle tree instead. But as long as Bitcoin remains remotely similar to today, any transaction that does not burn funds will serialize as more than 64 witness-stripped bytes. This is valid regardless of where the transaction is crafted. Not burning funds is already a concern when designing smart contracts: as long as this is covered, invalidating 64-byte transactions does not introduce an additional edge case. Moreover, the sparse Merkle tree suggestion would be a major change to a core protocol component, with far-reaching implications. Such a "soft" fork would blind unupgraded nodes, not only to others' transaction signatures like with Segwit, but to the entirety of the transaction traffic. This is not the right tradeoff. I certainly agree that introducing an explicit restriction on a specific transaction size is inelegant, and i'm partial to arguments about unforeseen complexity. But when the alternatives are leaving a notorious footgun to upper-layer developers [4], or making a far more invasive change that effectively mandates an extension block, this is pragmatically the least bad solution. Antoine Poinsot [0]: Initially raised on the PR to the BIPs repository, but the latest iteration is in response to my recent email to the Bitcoin mining development mailing list. See here https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk/m/RBT_LBWQAgAJ and the thread thereafter. [1]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/26 [2]: To the best of my knowledge, Jeremy has not published a description of his proposal. So i'm basing my response on this interview: https://youtu.be/FNKipXl5DTY?t=769. [3]: An argument previously raised by Eric Voskuil and weighed in the Consensus Cleanup's Delving thread. See this comment for an attempt at summarizing the discussion up to that point: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41 [4]: Even the BitVM bridge developers overlooked the need for implementing a mitigation for this (https://github.com/BitVM/BitVM/issues/285). -- 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/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do%3D%40protonmail.com.
