New research proposes changes to BIP 173 to reduce errors in Bech32 addresses. The update would bring greater compatibility for the Taproot integration.
Bitcoin pioneer developers Pieter Wuille and Gregory Maxwell proposed making adjustments to BIP 173 to reduce the impact of some bugs in the use of bech32 (SegWit) addresses and make it more compatible with Taproot.
Although regarding the researchers’ consideration, the native version of the Bech32 addresses (BIP 173) is quite robust, it is not the case of Taproot when it comes to implementation.
The proposed changes would help extend the integrity of the native version of the Bech32 addresses to its Taproot version, making possible the detection of errors in substitution, deletion, insertion, changes, and duplication of characters.
The investigation concluded this December, and the results are on a Linux foundation mailing list that was reviewed by the Bitcoin Optech Newsletter in recent days.
“The investigation revealed that most of the wallets need an update to be able to make payments to Taproot addresses even if users continue to use an unmodified version of the BIP173 address format,” the newsletter reads.
Although the research is still ongoing and receiving thoughts and opinions from other developers, who may oppose the research, Wuille plans to write a new Bitcoin Scalability Proposal (BIP) to allow native SegWit addresses to be compatible with Taproot. The code that Wuille and Maxwell have in their hands is on a post on GitHub for community review.
The native SegWit addresses can continue to be used to send and receive funds without affecting their format. However, those who use other versions of SegWit and their corresponding addresses will not have compatibility with Taproot through the new Wuille proposal. These wallets would be Bitcoin Core and BRD, according to a survey the developer conducted.
Although most wallets would not have to update and stick to these changes in BIP 173 to remain compatible, Wuille points out that eventually, all will have to do so, once the users start to demand the implementation of Taproot and the address format that comes from SegWit to use. However, this update should be easy, he considers, because the algorithm changes are small.
What is the Bech32 address mutability problem?
In posing this problem, conducted in 2019, Wuille mentions that in the worst case, a misspelled bech32 address has a probability of showing an error of 1 in a billion. Anyway, it points to a discovery that noted that those bech32 addresses with a p character, any number of q characters at the end, can be added or removed without affecting the integrity of the address.
This is not a problem for bech32 addresses in SegWit, as at least 19 consecutive characters would have to be added or removed to change the address, plus any other length would invalidate these addresses, he says.
Wuille also points out that the same will not happen to the new version of SegWit addresses planned for Taproot, “where adding or removing a single character in a vulnerable address can lead to loss of funds.”
Another relevant benefit would be that more applications can use bech32 addresses and other formats, in addition to reinforcing the differentiation between Bitcoin addresses and Bitcoin Cash addresses.
By: Jenson Nuñez.
