Hello all, A while ago it was discovered that bech32 has a mutation weakness (see https://github.com/sipa/bech32/issues/51 for details). Specifically, when a bech32 string ends with a "p", inserting or erasing "q"s right before that "p" does not invalidate it. While insertion/erasure robustness was not an explicit goal (BCH codes in general only have guarantees about substitution errors), this is very much not by design, and this specific issue could have been made much less impactful with a slightly different approach. I'm sorry it wasn't caught earlier.
This has little effect on the security of P2WPKH/P2WSH addresses, as those are only valid (per BIP173) for specific lengths (42 and 62 characters respectively). Inserting 20 consecutive "p"s in a typo seems highly improbable. I'm making this post because this property may unfortunately influence design decisions around bip-taproot, as was brought up in the review session (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017427.html) past tuesday. In the current draft, witness v1 outputs of length other than 32 remain unencumbered, which means that for now such an insertion or erasure would result in an output that can be spent by anyone. If that is considered unacceptable, it could be prevented by for example outlawing v1 witness outputs of length 31 and 33. Thoughts? Cheers, -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev