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
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
Return-Path: <aritter@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 08412B2B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Jan 2018 10:05:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com
[209.85.216.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 64EB314D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Jan 2018 10:05:13 +0000 (UTC)
Received: by mail-qt0-f177.google.com with SMTP id e2so8551109qti.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 06 Jan 2018 02:05:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=1KdTrY7DsSG114subWYYKFqIjD5CWfB7w8DhCgsxWUc=;
b=RRHSHOeTCNasH6ZJTltCMSh394tZdIV0H3CSSdnwo0llw1FHj2e2MmgaV469yi8Cfo
g3kZHIHY1I3v2ZGYTF82r26E88oy9yrAQUaii1ekAoVfCxFqWHUre3Saks44ttv6Pw/s
1PdzLrN5P06KamBGfjZoTOoHBKC3tdWpLHJ3dBLsYAuOhxUDSKpr7rCAtmkbcgUszAX4
Un6AUiTkoJQ2t/7bn9dSxVCix1isdVf1A3hXubo+QJeiOysC5lzazfJz6zwPaFayjY0w
HW9j0Nvj2o3DEtYKCv4nKbbX/JQc7hniO5E+YWre7TVh9uSSyZHN/cWynStjktF5pBkq
12/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=1KdTrY7DsSG114subWYYKFqIjD5CWfB7w8DhCgsxWUc=;
b=ozoftmhzCvJxR+gLR/KZ/8z7QdABY4mdDJfE+UXZYx9yoknZHSsyU/AZRfHn97BuTe
7e9i62QlObCIVSwhje0qr86EgRA5DR9DbbNbF7q6hox1zLgHeEnPSF95zIXPV6MznZPy
fporA6b9BT0QpVlk5uoAbGWAEyUyuTuf7XRzrYeiuJMtzlT9zCrdg1OB1U2p8s3GaFn7
zuDZIY1lKZMfHhVrGGfiXc3+VkPaZlaBAw+z11zbhZknonaBCFCQu7MLRslVRCrd9FOo
f+FObY2LUGxLGcMWF1bRJNEp9FuCLCI0ihe+Ns7oDkd6Y0EKEWxrcsLis1CTwe4Mo88N
n1KA==
X-Gm-Message-State: AKwxytfIWxhMOOyWAjQ6o8OGPQZBCVGJBWdEzxSPZPV/MgpUB10ypf54
8h9uQRx9OzXa3fjfhXNl1RhVEvvleXGkUQKIMn3KIA==
X-Google-Smtp-Source: ACJfBosoHACOXhS4SPn1RYpnjpiFAAwK2btv5WLwe6RPngh2WyXkP28c9elpDPFJaw9CgLO5ZINSLJLYZLS2/umJjps=
X-Received: by 10.200.42.80 with SMTP id l16mr7988723qtl.164.1515233112467;
Sat, 06 Jan 2018 02:05:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.166.137 with HTTP; Sat, 6 Jan 2018 02:05:11 -0800 (PST)
In-Reply-To: <CAAS2fgQT33QhZrSoGvi=_i0pREuqU+A82zSekFkC1M8av+ufRA@mail.gmail.com>
References: <201801041423.05959.luke@dashjr.org>
<CAAS2fgQT33QhZrSoGvi=_i0pREuqU+A82zSekFkC1M8av+ufRA@mail.gmail.com>
From: Adam Ritter <aritter@gmail.com>
Date: Sat, 6 Jan 2018 08:05:11 -0200
Message-ID: <CAKuKjyV9aFzVY0__N=P1U4+_zbidZruRFsnD1H9W0aAZhOwsQg@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113eff4e6bb062056218b3bb"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 06 Jan 2018 14:21:49 +0000
Subject: Re: [bitcoin-dev] =?utf-8?q?Bech32_and_P2SH=C2=B2?=
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sat, 06 Jan 2018 10:05:14 -0000
--001a113eff4e6bb062056218b3bb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
The question that I didn't see answered in the Bech32 proposal is why
something like the BIP39 mnemoic format is not used for addresses as well.
There was a lot of math involved in creating it, but I'm not sure how much
user experience testing.
I realized how much harder it is to copy random letters and numbers than
simple words only when I copied an addresses and a private keys by hand,
and even after I knew that I made a mistake, it took significant effort to
find the place of the mistake.
In contrast with BIP39 seeds I never made a mistake when writing down
(although I have seen a case where somebody made a mistake because a word
was twice in the same seed, but this is something that could be fixed).
On Fri, Jan 5, 2018 at 10:44 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> P2SH^2 wasn't a serious proposal-- I just suggested it as a thought
> experiment. I don't think it offers much useful in the context of
> Bitcoin today. Particularly since weight calculations have made output
> space relatively more expensive and fees are at quite non-negligible
> rates interest in "storing data" in outputs should at least not be
> increasing.
>
> Moreover, unfortunately, people already rushed bech32 to market in
> advance of practically any public review-- regrettable but it is what
> it is... I don't think adding more address diversity at this time
> wouldn't be good for the ecosystem.
>
> What we might want to do is consider working on an address-next
> proposal that has an explicit timeframe of N years out, and very loud
> don't deploy this--- layered hashing is just one very minor slightly
> nice to have... things like coded expiration times, abilities to have
> amounts under checksum, etc. are probably more worth consideration.
>
>
>
> On Thu, Jan 4, 2018 at 2:23 PM, Luke Dashjr via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I know I'm super-late to bring this up, but was there a reason Bech32
> omitted
> > the previously-discussed P2SH=C2=B2 improvements? Since deployment isn'=
t too
> > widespread yet, maybe it'd be worth a quick revision to add this?
> >
> > For those unfamiliar with the concept, the idea is to have the address
> include
> > the *single* SHA256 hash of the public key or script, rather than
> > RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would
> then
> > perform the second hash to produce the output. Doing this would in the
> future
> > enable relaying the "middle-hash" as a way to prove the final hash is i=
n
> fact
> > a hash itself, thereby proving it is not embedded data spam.
> >
> > Bech32 seems like a huge missed opportunity to add this, since everyone
> will
> > probably be upgrading to it at some point.
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113eff4e6bb062056218b3bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The question that I didn't see answered in the Bech32 =
proposal is why something like the BIP39 mnemoic format is not used for add=
resses as well. There was a lot of math involved in creating it, but I'=
m not sure how much user experience testing.<div><br><div>I realized how mu=
ch harder it is to copy random letters and numbers than simple words only w=
hen I copied an addresses and a private keys by hand, and even after I knew=
that I made a mistake, it took significant effort to find the place of the=
mistake.</div><div><br></div><div>In contrast with BIP39 seeds I never mad=
e a mistake when writing down (although I have seen a case where somebody m=
ade a mistake because a word was twice in the same seed, but this is someth=
ing that could be fixed).</div><div><br></div></div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Fri, Jan 5, 2018 at 10:44 PM, G=
regory Maxwell via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">P2S=
H^2 wasn't a serious proposal-- I just suggested it as a thought<br>
experiment. I don't think it offers much useful in the context of<br>
Bitcoin today. Particularly since weight calculations have made output<br>
space relatively more expensive and fees are at quite non-negligible<br>
rates interest in "storing data" in outputs should at least not b=
e<br>
increasing.<br>
<br>
Moreover, unfortunately, people already rushed bech32 to market in<br>
advance of practically any public review-- regrettable but it is what<br>
it is... I don't think adding more address diversity at this time<br>
wouldn't be good for the ecosystem.<br>
<br>
What we might want to do is consider working on an address-next<br>
proposal that has an explicit timeframe of N years out, and very loud<br>
don't deploy this--- layered hashing is just one very minor slightly<br=
>
nice to have... things like coded expiration times, abilities to have<br>
amounts under checksum, etc. are probably more worth consideration.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On Thu, Jan 4, 2018 at 2:23 PM, Luke Dashjr via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>> wrote:<br>
> I know I'm super-late to bring this up, but was there a reason Bec=
h32 omitted<br>
> the previously-discussed P2SH=C2=B2 improvements? Since deployment isn=
't too<br>
> widespread yet, maybe it'd be worth a quick revision to add this?<=
br>
><br>
> For those unfamiliar with the concept, the idea is to have the address=
include<br>
> the *single* SHA256 hash of the public key or script, rather than<br>
> RIPEMD160(SHA256(pubkey)) or SHA256(SHA256(script)). The sender would =
then<br>
> perform the second hash to produce the output. Doing this would in the=
future<br>
> enable relaying the "middle-hash" as a way to prove the fina=
l hash is in fact<br>
> a hash itself, thereby proving it is not embedded data spam.<br>
><br>
> Bech32 seems like a huge missed opportunity to add this, since everyon=
e will<br>
> probably be upgrading to it at some point.<br>
><br>
> Luke<br>
> ______________________________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
--001a113eff4e6bb062056218b3bb--
|
