Published on: 2020-07-15T21:11:11+00:00
The Bitcoin development community is engaged in discussions regarding potential amendments to BIP173, specifically related to the "bc" and "tb" segwit address formats. Russell O'Connor has proposed restricting these formats to specific witness program sizes, ranging from 20 to 40 bytes. The aim is to enhance security by excluding shorter witness program sizes with insufficient entropy. This proposal comes as a response to Pieter Wuille's suggestion that such restrictions are unnecessary. Greg Sanders seeks clarification on the significance of bold vs not-bold numbers in relation to witness and address lengths.Another proposal by Russell O'Connor suggests length-prefixing the witness program to address the unused characters in the bech32 alphabet. He proposes creating a new human-readable prefix, potentially "btc1," for length-prefixed bitcoin witness programs. However, ZmnSCPxj's proposal to modify the Bech32 SegWit address format was considered impractical.The discussion also includes considerations for accommodating the taproot program, which corresponds to a witness program length of 32 bytes. The use of alternate checksums for Segwit outputs of various lengths is another topic under discussion. Two options have been presented: implementing a consensus or standardness rule to enforce library upgrades, or addressing the issue within the bech32 algorithm itself. David A. Harding advocates for addressing the issue within the bech32 algorithm, despite potential disruptions to batched transactions.In the context of these discussions, Pieter Wuille proposes amending BIP173 to limit witness programs to lengths of 20 or 32, while still allowing other versions besides 0. The idea is to modify the XOR constant in the checksum encoding process to handle various program lengths without creating a new address format or increasing cognitive load for users.Overall, the Bitcoin development community is focused on exploring amendments and improvements to address formats, witness program lengths, and checksums. The goal is to enhance security, prevent unintended spending, and accommodate future developments while minimizing disruption to existing infrastructure.On the Bitcoin-dev mailing list, a discussion has been initiated regarding the implementation of a rule to prevent witness v1 outputs of length other than 32. Currently, these outputs remain unencumbered, allowing anyone to spend them. One option is to outlaw v1 witness outputs of length 31 and 33, but this would require library upgrades for users of v1+ segwit. This issue was previously addressed in problem #15846, and there are two potential ways to address it: implementing a consensus rule or a standardness rule.A vulnerability has been discovered in the bech32 address format where inserting or erasing "q"s before a final "p" does not invalidate it. While this issue may influence design decisions around bip-taproot, it has little effect on the security of P2WPKH/P2WSH addresses as they are only valid for specific lengths. Outlawing unencumbered witness v1 outputs of length other than 32 could prevent such an insertion or erasure from resulting in an output that can be spent by anyone. However, instead of implementing a consensus/standardness fix, it is suggested to redefine bech32 to disallow such addresses.Pieter Wuille, a developer of bitcoin, posted about a mutation weakness in bech32 on the Bitcoin-dev mailing list. Inserting or erasing "q"s before the final "p" in a bech32 string does not invalidate it due to an oversight in the original design. This mutation weakness has little effect on the security of P2WPKH/P2WSH addresses but may impact design decisions around bip-taproot. In the current draft of bip-taproot, witness v1 outputs of length other than 32 remain unencumbered, allowing anyone to spend them. To prevent this, one option is to outlaw v1 witness outputs of length 31 and 33. Pieter apologizes for not catching this issue earlier and seeks thoughts from the community on preventing similar issues in the future.
Updated on: 2023-08-02T01:30:47.272776+00:00