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
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
|
Return-Path: <bitcoin-dev@wuille.net>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 07E10C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2020 22:56:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id DC1612E160
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2020 22:56:05 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id O98hMI9i6sHF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2020 22:56:02 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch
[185.70.40.134])
by silver.osuosl.org (Postfix) with ESMTPS id BE6ED20113
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 19 Oct 2020 22:56:01 +0000 (UTC)
Date: Mon, 19 Oct 2020 22:55:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net;
s=protonmail2; t=1603148158;
bh=k/A00TGYeZGH9/C/4y6t1IQ8pPOOTriKDkKPb+hQYrU=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=bT5Ya+WzyYZnJ8Mj45frSicSaDUmk1WfvlkgQzdWJdyAYvm2FtqeDJpvXUOq6MyRt
atpI9I6c6Dv+O6fjwibOMA7BqGdQrU72gOp2Cf+RKpOh8sYP0dQA3B9RKPaauHELd7
x8mOR6dTqr6Tg7N72zoQgAdY4fh5SSSBfOUUtnTMyd43Oz1q5Q1UtkkXBZVaKNPxBG
aGDgoDfE/JvXfykN/klZBB0DI8FL6a1jp4dq3lTZeCrRDdCl6IlHJnq0kB+a8NosGu
N7CUYJ14sB6Lf3BsEkF45Rlzq/NJa8zKvyFDytnBJiNsORB7j/WwBxXMbZWzTn/55B
p08cPx8G2vIcg==
To: Rusty Russell <rusty@rustcorp.com.au>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Reply-To: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <S6FCoLsmwaQUhrtSURemcTcG8tUWTXYkBf-0Q0hxCpObfJQ0TXNcmJrQhoqy7ttWwtGnvyS-bJ5RSXJoPizAgjuMognzVnu3SM3wMujKy88=@wuille.net>
In-Reply-To: <877drn2g6q.fsf@rustcorp.com.au>
References: <87imblmutl.fsf@rustcorp.com.au>
<20201008145938.vrmm33f6sugdc7qm@ganymede> <87r1q0e06p.fsf@rustcorp.com.au>
<sYf9B0e3UaSdMfdBfChon1Vr7BRFdH_6mgzuXIt_xbtlKtdqns9JJp90dRlNfvwBoRq57YEVrKbKX-dHDWz7TE0gobU4u8dGGJTcFFz2n60=@wuille.net>
<877drn2g6q.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 19 Oct 2020 22:58:55 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
John Barboza <johnbarboza@gmail.com>
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: Mon, 19 Oct 2020 22:56:06 -0000
On Sunday, October 18, 2020 5:49 PM, Rusty Russell <rusty@rustcorp.com.au> =
wrote:
> Pieter Wuille bitcoin-dev@wuille.net writes:
>
> > Today, no witness v1 receivers exist. So it seems to me the only questi=
on
> > is what software/infrastructure exist that supports sending to witness =
v1,
> > and whether they (and their userbase) are more or less likely to upgrad=
e
> > before receivers appear than those that don't.
> > Clearly if only actively developed software currently supports sending =
to
> > v1 right now, then the question of forward compatibility is moot, and I=
'd
> > agree the cleanliness of option 2 is preferable.
>
> If software supports v1 today and doesn't get upgraded, and we persue
> option 1 then a trailing typo can make trouble. Not directly lose money
> (since the tx won't get propagated), but for most systems (e.g. hosted
> wallets) someone has to go in and figure out the error and fix it up.
It depends. As is, they'd be relayed even as sending to future witness vers=
ions
or lengths is standard. If option 1 is chosen there may be reasons to add
safeguards using relay policy, though.
> Option 2 means they're likely to fix their systems the first time
> someone tries a v1 send, not the first time someone makes a trailing
> typo (which might be years).
Possibly, but it's also possible that it won't get fixed at all, and instea=
d
receiver software just has to wait a few years longer before being able to =
start
giving out v1 addresses and have a reasonable chance the sender supports it=
.
You're right though that protecting old sender software from being protecte=
d
against the insertion bug is a good argument in favor of Option 2.
Strictly speaking it also has an issue, as the error detection properties a=
ren't
guaranteed for new-scheme-address + intended-detected-error interpreted as
old-scheme-address (in particular, you can make 4 substitution errors in
a new-scheme address and have it be a valid old-scheme address). This is mu=
ch
less of an issue than the insertion bug that remains present with Option 1 =
in
old senders.
> > As for how long: new witness version/length combinations are only rarel=
y needed,
> > and there are 14 length=3D32 ones left to pick. We'll likely want to us=
e those
> > first anyway, as it's the cheapest option with 128-bit collision resist=
ance.
> > Assuming future constructions have something like BIP341's leaf version=
ing, new
> > witness version/length combinations are only required for:
> >
> > - Changes to the commitment structure of script execution (e.g. Graft=
root,
> > different hash function for Merkle trees, ...)
> >
> > - Upgrades to new signing cryptography (EC curve change, PQC, ...).
> > - Changes to signatures outside of a commitment structure (e.g. new s=
ighash
> > modes for the keypath in BIP341, or cross-input aggregation for the=
m).
> >
> >
> > and in general, not for things like new script opcodes, or even for fai=
rly
> > invasive redesigns of the script language itself.
>
> Hmm, good point. These can all be done with version bumps.
>
> The only use for extra bytes I can see is per-UTXO flags, but even then
> I can't see why you'd need to know them until their spent (in which case
> you stash the flag in the input, not the output).
>
> And fewer bytes seems bad for fungibility, since multisig would be
> dangerous.
>
> But the future keeps surprising me, so I'm still hesitant.
Of course, our thinking here may change significantly over time - still, I =
expect
it'll be years before something other than 32-byte addresses is desired.
> > TL;DR: what codebases/services/infrastructure exists today that support=
s
> > sending to witness v1 BIP173 addresses?
>
> OK, time to waste some money!
>
> Can you provide a mainnet v1 address, and I'll try to spam it from as
> many things as I can find. If we're really lucky, you can collect it
> post-fork and donate it to charity. Or a miner can steal it pre-fork :)
Here is a BIP341 witness v1 address, corresponding to just the generator as
inner public key (using TapTweak(pubkey) as tweak, as suggested by the BIP)=
:
bc1pmfr3p9 YOU j00pfxjh WILL 0zmgp99y8zf LOSE tmd3s5pmedqhy MONEY ptwy6lm87=
hf5ss52r5n8
Cheers,
--
Pieter
|
