From: "David A. Harding" <dave@dtrt•org>
To: Rusty Russell <rusty@rustcorp•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)
Date: Thu, 8 Oct 2020 10:59:38 -0400 [thread overview]
Message-ID: <20201008145938.vrmm33f6sugdc7qm@ganymede> (raw)
In-Reply-To: <87imblmutl.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]
On Thu, Oct 08, 2020 at 10:51:10AM +1030, Rusty Russell via bitcoin-dev wrote:
> Hi all,
>
> I propose an alternative to length restrictions suggested by
> Russell in https://github.com/bitcoin/bips/pull/945 : use the
> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb variant,
> unless the first byte is 0.
>
> Here's a summary of each proposal:
>
> Length restrictions (future segwits must be 10, 13, 16, 20, 23, 26, 29,
> 32, 36, or 40 bytes)
> 1. Backwards compatible for v1 etc; old code it still works.
> 2. Restricts future segwit versions, may require new encoding if we
> want a diff length (or waste chainspace if we need to have a padded
> version for compat).
>
> Checksum change based on first byte:
> 1. Backwards incompatible for v1 etc; only succeeds 1 in a billion.
> 2. Weakens guarantees against typos in first two data-part letters to
> 1 in a billion.[1]
Excellent summary!
> I prefer the second because it forces upgrades, since it breaks so
> clearly. And unfortunately we do need to upgrade, because the length
> extension bug means it's unwise to accept non-v0 addresses.
I don't think the second option forces upgrades. It just creates
another opt-in address format that means we'll spend another several
years with every wallet having two address buttons, one for a "segwit
address" (v0) and one for a "taproot address" (v1). Or maybe three
buttons, with the third being a "taproot-in-a-segwit-address" (v1
witness program using the original bech32 encoding).
It took a lot of community effort to get widespread support for bech32
addresses. Rather than go through that again, I'd prefer we use the
backwards compatible proposal from BIPs PR#945 and, if we want to
maximize safety, consensus restrict v1 witness program size, e.g. reject
transactions with scriptPubKeys paying v1 witness programs that aren't
exactly 32 bytes.
Hopefully by the time we want to use segwit v2, most software will have
implemented length limits and so we won't need any additional consensus
restrictions from then on forward.
-Dave
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-10-08 15:00 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 0:21 Rusty Russell
2020-10-08 14:59 ` David A. Harding [this message]
2020-10-08 15:21 ` Russell O'Connor
2020-10-15 1:40 ` Rusty Russell
2020-10-16 21:09 ` Pieter Wuille
2020-10-19 0:49 ` Rusty Russell
2020-10-19 22:55 ` Pieter Wuille
2020-10-20 0:42 ` Rusty Russell
2020-10-20 3:31 ` Rusty Russell
2020-10-20 9:21 ` Riccardo Casatta
2020-10-20 10:29 ` David A. Harding
2020-10-20 20:12 ` Pieter Wuille
2020-10-20 23:52 ` Mike Schmidt
2020-10-21 4:51 ` Rusty Russell
2020-11-06 19:49 ` Mike Schmidt
2020-12-05 23:10 ` Pieter Wuille
2020-12-06 13:04 ` David A. Harding
2020-12-06 20:43 ` Pieter Wuille
2020-12-08 17:39 ` Ryan Grant
2020-12-18 2:02 ` Pieter Wuille
2020-10-21 3:05 ` ZmnSCPxj
2020-10-21 4:39 ` Rusty Russell
2020-10-28 0:20 ` Pieter Wuille
2020-12-05 22:59 ` Pieter Wuille
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=20201008145938.vrmm33f6sugdc7qm@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rusty@rustcorp$(echo .)com.au \
/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