Given the issue is in the address format, not the consensus/standardness layer, it does seem somewhat strange to jump to addressing it with a consensus/standardness fix. Maybe the ship has sailed, but for the sake of considering all our options, we could also redefine bech32 to not allow such addresses. Matt >> On Nov 7, 2019, at 17:47, Greg Sanders via bitcoin-dev wrote: >  > Could the softer touch of just making them non-standard apply as a future preparation for an accepted softfork? Relaxations could easily be done later if desired. > >>> On Thu, Nov 7, 2019, 5:37 PM Pieter Wuille via bitcoin-dev wrote: >> 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev