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
|
Return-Path: <bitcoin-dev@wuille.net>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id E3211C013B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Dec 2020 20:44:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id C2B7E87322
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Dec 2020 20:44:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id bfVoURIR8Oue
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Dec 2020 20:44:03 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by hemlock.osuosl.org (Postfix) with ESMTPS id C79A387315
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 6 Dec 2020 20:44:02 +0000 (UTC)
Date: Sun, 06 Dec 2020 20:43:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net;
s=protonmail2; t=1607287439;
bh=pa5XpcmXre6YdNiIlWlq9gHEl7M7a+IHBGX2pPURM2E=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=LD7ASrCQsg8gsS6AjQ4PjvT+IYYl0jlVeNzZEtUX1eVdAmlagJFZh9f+tPBXTGLqG
Hcf/bjbi4rFj65j85H5X4uUX4O3SeHMVCmNjdaPRERyRzdYzdNQgNdFWVto7/AKLAr
1vQCJdg9sYHnPPw+Pdm3jfcYjxboJ98GwqcOiWHluRqtGCg1qBz12Hl2nUjPIMNehW
DcGLsAWWln+vnweCdiaPqLmDvwzY3+qc5BjXywLhEyji5LnzL5W4gVpjErEtXAeOxo
XwUNJoevFuXhRIVMpFLk6NcAO6WZCA6itpui29V4ZmExZE09Ci1oeJlASyOZsDDwXg
AFJdwfd9UhmuA==
To: "David A. Harding" <dave@dtrt.org>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Reply-To: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <vLjiyu9VKGMXcCP2wNvFG1OuYl0IBHm5DQd1WncpKgaxJFZrwdD5JKvRfT5m9Cyrf4YPvmTPbHdREZmS-msdTBlf2RMwlr2mEgZ9TFYaVRg=@wuille.net>
In-Reply-To: <20201206130453.tiu36iigva2jj5qn@ganymede>
References: <87imblmutl.fsf@rustcorp.com.au>
<S6FCoLsmwaQUhrtSURemcTcG8tUWTXYkBf-0Q0hxCpObfJQ0TXNcmJrQhoqy7ttWwtGnvyS-bJ5RSXJoPizAgjuMognzVnu3SM3wMujKy88=@wuille.net>
<878sc120f5.fsf@rustcorp.com.au> <20201020102952.4iwpugi5dxawufgo@ganymede>
<Kw_jwhASjriebJpsuUyi0u9EQmIVR1pQ3Jocqd9VeVDlmoH9s36bFAwr3PXu_pJd-Xly-hKun_yenLwbJvVIYWmlAiF5lMxuquLO2pTmlLo=@wuille.net>
<CAMeZzJeG00q9DPQacidto5H16Ryb6ou6tnMDK1jnAuncnVXnsA@mail.gmail.com>
<CAMeZzJdQuS1-0qPvY+0-yqRfVXgZV_2hmHB5hZwykm5WxjUkgg@mail.gmail.com>
<5Zb8Vf0nq7_rg04OTJwVIY565lDZowEfBXX9IBVLIuG7lTa_sIe4BL3YbpBK2NUAZV7QasZTPHVo5J2uJoRgjj3TveBC12QEp9oTdnLis0k=@wuille.net>
<20201206130453.tiu36iigva2jj5qn@ganymede>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 06 Dec 2020 20:49:25 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 06 Dec 2020 20:44:05 -0000
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Sunday, December 6, 2020 5:04 AM, David A. Harding <dave@dtrt.org> wrote=
:
> On Sat, Dec 05, 2020 at 11:10:51PM +0000, Pieter Wuille via bitcoin-dev w=
rote:
>
> > I think these results really show there is no reason to try to
> > maintain the old-software-can-send-to-future-segwit-versions property,
> > given that more than one not just didn't support it, but actually sent
> > coins into a black hole.
>
> I don't think this is a good criteria to use for making a decision. We
> shouldn't deny users of working implementations the benefit of a feature
> because some other developers didn't implement it correctly.
>
> > Thus, I agree with Rusty that we should change the checksum for v1+
> > unconditionally.
>
> I disagreed with Rusty previously and he proposed we check to see how
> disruptive an address format change would be by seeing how many wallets
> already provide forward compatibility and how many would need to be
> updated for taproot no matter what address format is used. I think that
> instead is a good criteria for making a decision.
>
> I understand the results of that survey to be that only two wallets
> correctly handled v1+ BIP173 addresses. One of those wallets is Bitcoin
> Core, which I personally believe will unhesitatingly update to a new
> address format that's technically sound and which has widespread support
> (doubly so if it's just a tweak to an already-implemented checksum
> algorithm).
Hi Dave,
You're right to point out there is nuance I skipped over.
Let's look at the behavior of different classes of software/services that e=
xist today when trying to send to v1+ addresses:
(A) Supports sending to v1+ today
* Old proposal: works, but subject to bech32 insertion issue
* New proposal: fails
(B) Fails to send to v1+ today
* Old proposal: fails
* New proposal: fails
(C) Incorrectly sends to v1+ today
* Old proposal: lost funds
* New proposal: fails
So the question is how the support for sending to v1+ in (a) software weigh=
s up against protecting both (a) from the insertion issue, and (c) from los=
t funds. I do think (c) matters in this equation - people may choose to avo=
id adopting v1+ witnesses if it were to be known that some senders out ther=
e would misdirect funds. But the fact that (a) is small also means there is=
very little to gain from the old proposal.
So perhaps I should have formulated it as: the small number of v1+ compatib=
le senders today (regardless of the reasons for that) shows how futile the =
attempt to have one address type for all witness versions was, and the fact=
that there are even some who misdirect(ed) funds is the final nail in the =
coffin. Changing the checksum unconditionally gives us a new attempt at tha=
t.
> Given that, I also now agree with changing the checksum for v1+.
Great.
Cheers,
--
Pieter
|
