Author: Johnson Lau 2017-04-04 18:35:01
Published on: 2017-04-04T18:35:01+00:00
The writer raises concerns about a new Bitcoin Improvement Proposal (BIP), expressing disappointment that their proposal was not given more consideration. They criticize the lack of specificity in the proposed approach to resolving transaction malleability and suggest changes to how the merkle root is calculated. Additionally, they question whether direct exit payment to legacy addresses should be allowed and propose limiting the number of soft-fork upgrades, increasing the points for witness v0 outputs, and setting a higher dust threshold.A work-in-progress extension block proposal has been introduced, which is technically sound but increases complexity compared to BIP141 and hardforks. Extension blocks are sidechains tied into Bitcoin directly, potentially creating two classes of "full nodes," leaving some insecure like pseudo-SPV nodes. The maximum extension size should be intentionally high, but this has the same issue as BIP141, with attacks potentially doing more damage than ordinary benefit.The Witness Vector specification details that every 73 bytes in the serialized witness vector is worth one additional point, but it doesn't explain why this number was chosen. The BIPs must be in MediaWiki format and should be submitted for discussion to the bitcoin-dev mailing list instead of social media and news. Extension blocks are more of a hard-fork than a soft-fork and are not compatible with BIP141 in its current form, requiring a few minor additional rules.The UTXO set behaves fundamentally different to old nodes with this proposal, albeit in a mostly compatible manner. Canonical blocks containing entering outputs must contain an extension block commitment, all zeroes if nothing is present in the extension block. The genesis resolution transaction may also include a 1-100 byte pushdata in the first input script, allowing the miner of the genesis resolution to add a special message. Transactions within the extended transaction vector may include a witness vector using BIP141 transaction serialization since extblock transactions are all required to be segwit.To reduce the chance of having redeem scripts which simply allow for garbage data in the witness vector, every 73 bytes in the serialized witness vector is worth 1 additional point. A consensus dust threshold is now enforced within the extension block. If the second highest transaction version bit (30th bit) is set to `1` within an extension block transaction, an extra 700-bytes is reserved on the transaction space used up in the block.The deployment name for this specification is "extblk" and appears as "!extblk" in GBT. The Witness Vector specification leaves room for seven future soft-fork upgrades to relax DoS limits. The deactivation deployment's start time is mentioned, but there is no information about timeout or how to continue the extension block. The writer critiques the lack of clarity and specificity in the new BIP and proposes alternative solutions, emphasizing the importance of these issues. Finally, they comment on the potential negative effects of deactivating unused chains and caution against specifying policy in BIPs.
Updated on: 2023-05-20T01:38:16.293226+00:00