> On Nov 8, 2019, at 11:16, David A. Harding via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev > wrote: >> 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. > > Either a consensus rule or a standardness rule[1] would require anyone > using a bech32 library supporting v1+ segwit to upgrade their library. > Otherwise, users of old libraries will still attempt to pay v1 witness > outputs of length 31 or 33, causing their transactions to get rejected > by newer nodes or get stuck on older nodes. This is basically the > problem #15846[2] was meant to prevent. > > If we're going to need everyone to upgrade their bech32 libraries > anyway, I think it's probably best that the problem is fixed in the > bech32 algorithm rather than at the consensus/standardness layer.
As an implementer of both the address encoding and script validation, I agree. e > -Dave > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017444.html > [2] https://github.com/bitcoin/bitcoin/pull/15846 > > P.S. My thanks as well to the people who asked the question during > review that lead to this discussion: > > > http://www.erisian.com.au/meetbot/taproot-bip-review/2019/taproot-bip-review.2019-11-05-19.00.log.html#l-88 > _______________________________________________ > 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
