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 <
bitcoin-dev@lists.linuxfoundation.org> 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
>