From: "David A. Harding" <dave@dtrt•org>
To: Pieter Wuille <pieter.wuille@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
Date: Thu, 7 Nov 2019 16:15:41 -1000 [thread overview]
Message-ID: <20191108021541.n3jk54vucplryrbl@ganymede> (raw)
In-Reply-To: <CAPg+sBjC-D2iWYywj_X-evQoWx56nb0YnASLVwCSCzWT6Guu3A@mail.gmail.com>
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.
-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
next prev parent reply other threads:[~2019-11-08 2:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-07 22:35 Pieter Wuille
2019-11-07 22:45 ` Greg Sanders
2019-11-08 0:41 ` Matt Corallo
2019-11-08 2:15 ` David A. Harding [this message]
2019-11-08 3:15 ` Eric Voskuil
2019-11-10 21:51 ` Pieter Wuille
2019-11-11 1:02 ` Matt Corallo
2019-11-13 2:56 ` Clark Moody
2019-11-13 5:32 ` ZmnSCPxj
2019-11-13 6:30 ` Pieter Wuille
2020-07-15 20:56 ` Russell O'Connor
2020-07-15 21:05 ` Greg Sanders
2020-07-15 21:11 ` Russell O'Connor
2019-11-08 5:11 ` ZmnSCPxj
2019-11-08 13:03 ` Russell O'Connor
2019-11-08 13:42 ` Damian Mee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191108021541.n3jk54vucplryrbl@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox