1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
Return-Path: <rusty@ozlabs.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 76654C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2020 01:46:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 6592F8871A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2020 01:46:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id WyH+UXb8txLE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2020 01:46:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [203.11.71.1])
by whitealder.osuosl.org (Postfix) with ESMTPS id 54AA788716
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 15 Oct 2020 01:46:28 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 4CBXFG0YVqz9sTR; Thu, 15 Oct 2020 12:46:25 +1100 (AEDT)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "David A. Harding" <dave@dtrt.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <20201008145938.vrmm33f6sugdc7qm@ganymede>
References: <87imblmutl.fsf@rustcorp.com.au>
<20201008145938.vrmm33f6sugdc7qm@ganymede>
Date: Thu, 15 Oct 2020 12:10:30 +1030
Message-ID: <87r1q0e06p.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions
(BIP-173)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2020 01:46:29 -0000
"David A. Harding" <dave@dtrt.org> writes:
> 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).
If we go for option 2, v1 (generated from bitcoin core) will simply fail
the first time you try test it. So it will force an upgrade. There
are fewer places generating addresses than accepting them, so this
seems the most likely scenario.
OTOH, with option 1, anyone accepting v1 addresses today is going to
become a liability once v1 addresses start being generated.
> 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.
Yes, I too wish we weren't here. :(
Deferring a hard decision is not useful unless we expect things to be
easier in future, and I only see it getting harder as time passes and
userbases grow.
The good news it that the change is fairly simple and the reference
implementations are widely used so change is not actually that hard
once the decision is made.
> 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.
If we are prepared to commit to restrictions on future addresses.
We don't know enough to do that, however, so I'm reluctant; I worry that
a future scheme where we could save (e.g.) 2 bytes will impractical due
to our encoding restrictions, resulting in unnecessary onchain bloat.
Cheers,
Rusty.
|
