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
235
236
237
238
239
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 13F074A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 May 2017 21:39:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E0FC86
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 May 2017 21:39:16 +0000 (UTC)
Received: by mail-wm0-f42.google.com with SMTP id u65so12342209wmu.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 07 May 2017 14:39:15 -0700 (PDT)
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=T0YBATiPg7d8J1oB5Sb4dTzR91ZPrt7z+SYxH6zXBLQ=;
b=Wl1e2z3BkI+WIu2Ope/IzRwh6Na6w9lEa0k464eI5drngyFr45Sx549MlUcz+RHrNP
OtfYW9x8RbBGbejXR5KeF2G0lOOT9MKb/3gEnDsdDKp33Np8sSuDJfGfcRPeB9ug6Nu6
2J/+IUq5H3jZonoxar8O6EnXS0QsqgPgjYMwsQUDOqi9iMi55HqB5msG49y3My8SLXEN
uYqJG9eYqrzvLGimUrj7AZ7s8fQZ3B21VHXPeTt/+0e/uB64C2qJr1YzC1vZRB4w0WPB
LcoYYUO1UbQ0StUBjGSlP52OEfC8BVWYsFSLvyMB801UvRyQ9D0/r45HzYr9T1AK05p1
cJgA==
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=T0YBATiPg7d8J1oB5Sb4dTzR91ZPrt7z+SYxH6zXBLQ=;
b=Q3cgVqw2JpeJpHZ70g72Egepb2E3FxqlwYZArgQSNLNkW7jEwgKXDgMV6qDakUqFj8
iaiDOBTE3OaByqZ/zZIg3rUzpauDhD3f0rrfppcNGMvdIleDBStS+PIf1vFG6wIZY0Av
NnPYF2NKOewh1tlNyIRT0lJx6xzh3z55c7ydA/nLR2EnnHVnWDo5Mu8AwPiqLTsA4T2r
hBbO8VvsJtl4bzyjVCR4NdlCdwP882M60415b6vJ/9ZlMyMGwswnUM9S+4vF/NorGdkg
gtpB6FvVJDUFieiATeFO2v9xIc1KanrJ29/I7NRjW48+cy4fxSS/dqaqNcPkf6Gl4U5f
JKuA==
X-Gm-Message-State: AN3rC/4HmmJvrrBQW4LX1YvM0M1M1mL+VAA95BDg8YkzYNKLAGBApHR3
CqvAzHCpg5iMTQUKkD9OvkeKD2p6ljFl+vg=
X-Received: by 10.80.174.36 with SMTP id c33mr42471451edd.103.1494193154600;
Sun, 07 May 2017 14:39:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.135.79 with HTTP; Sun, 7 May 2017 14:39:14 -0700 (PDT)
In-Reply-To: <CAPg+sBh0sFA7b6a+48Oojwy655GB9W6Th8JiCpd+2ruQjPev8Q@mail.gmail.com>
References: <CAPg+sBh0sFA7b6a+48Oojwy655GB9W6Th8JiCpd+2ruQjPev8Q@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Sun, 7 May 2017 14:39:14 -0700
Message-ID: <CAPg+sBiPiLHZFoYY=gs6LT+Q2Kb5NmbVU05u7c+0WRPjveBJhQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c1961d034b6ce054ef5f453
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 07 May 2017 21:40:12 +0000
Subject: Re: [bitcoin-dev] A BIP proposal for segwit addresses
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: Sun, 07 May 2017 21:39:17 -0000
--94eb2c1961d034b6ce054ef5f453
Content-Type: text/plain; charset=UTF-8
On Mon, Mar 20, 2017 at 2:35 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> Hello everyone,
>
> You can find the text here:
> https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki
>
Responding to a few comments:
By Andreas Schildbach:
> I'm not convinced that transmitting addresses via voice should be a
usecase to target at
I think it should be. It's certainly not the most important way through
which addresses are communicated or verified, but I am trying to address
all places where humans interact with addresses. I have certainly tried to
verify addresses a few times through voice, when dealing with significant
amounts.
Regarding your QR code comments: it is certainly possible to find a more
compact QR code representation. That is not the goal of the BIP though -
it's trying to introduce one commonly recognizable format that has good
properties for all use cases, even if that means being suboptimal in
certain aspects for some.
> I don't understand your comment about non-english speaking users.
Obviously they cannot voice-communicate at all with only-english-speaking
users, so there is no need to communicate voice-communicate addresses
between them.
I assume that Peter Todd is talking about cases where English speakers are
interacting with non-native English speakers, who may know how to pronounce
numbers or alphabetical characters, but not all special characters.
> Speaking of URLs, actually Base 32 (as well as Base 43) makes QR codes
*bigger* because due to the characters used for URL parameters (?&=) those
QR codes are locked to binary mode.
I believe that is incorrect. Data in QR codes can switch from one mode to
another on a per-character basis (with an overhead of a few bits). I don't
know to what extent common QR encoders make intelligent decisions about
this, but it does not seem very hard.
By Lucas Ontivero:
> Here I think it could worth to mention that 58 requires mathematical
operations over big numbers. This is not very fast and most of the
programming languages don't provide support for big numbers OOB.
It's not that hard to emulate the bignum logic in languages that don't
support it. See for example this code in Bitcoin Core:
https://github.com/bitcoin/bitcoin/blob/v0.14.1/src/base58.cpp#L37L53. So I
think it's not necessary to go into all the possible ways Base58 can be
implemented in the document, and the existing language ("Base58 decoding is
complicated and relatively slow.") is sufficient.
> I understand that if a new generic encoding format is introduced that
could lead to some confusions but what if in the future there is a new type
of address that can also be encoded with bech32? Don't we need a address
type anyway?
I believe that it's likely that new types of outputs that may be introduced
in the future will most likely not be a simple constant byte sequence that
can be computed directly from addresses, but need some processing by the
sender. This is the case for example for Reusable/Stealth addresses and
Confidential Transactions addresses. Such outputs, if ever introduced on a
wide scale, should ideally not be representable as existing address types,
as that could not only lead to confusion, but also to lost privacy and
funds.
And, If there ever is a need for introducing a "constant scriptPubKey" type
address again, the encoding proposed in this document can be reused.
Currently, the header value can be at most 17. In the future new proposals
could give a meaning to values 18 through 31.
In general:
In the past weeks people have contributed two new reference implementations
(Haskell and Rust), and a C++ and Go one are underway (see
https://github.com/sipa/bech32).
I'd like to move forward and request a BIP number assignment for this
proposal.
Cheers,
--
Pieter
--94eb2c1961d034b6ce054ef5f453
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Mar 20, 2017 at 2:35 PM, Pieter Wuille <span dir=
=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">p=
ieter.wuille@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">Hello everyone,<br>
<br>
You can find the text here:<br>
<a href=3D"https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki=
" rel=3D"noreferrer" target=3D"_blank">https://github.com/sipa/<wbr>bech32/=
blob/master/bip-<wbr>witaddr.mediawiki</a><br></blockquote><div><br></div><=
div>Responding to a few comments:<br><br></div><div>By Andreas Schildbach:<=
br><br>> I'm not convinced that transmitting addresses via voice sho=
uld be a usecase to target at<br><br></div><div>I think it should be. It=
9;s certainly not the most important way through which addresses are commun=
icated or verified, but I am trying to address all places where humans inte=
ract with addresses. I have certainly tried to verify addresses a few times=
through voice, when dealing with significant amounts.<br><br></div><div>Re=
garding your QR code comments: it is certainly possible to find a more comp=
act QR code representation. That is not the goal of the BIP though - it'=
;s trying to introduce one commonly recognizable format that has good prope=
rties for all use cases, even if that means being suboptimal in certain asp=
ects for some.<br></div><div><br>> I don't understand your comment a=
bout non-english speaking users. Obviously they cannot voice-communicate at=
all with only-english-speaking users, so there is no need to communicate v=
oice-communicate addresses between them.<br><br></div><div>I assume that Pe=
ter Todd is talking about cases where English speakers are interacting with=
non-native English speakers, who may know how to pronounce numbers or alph=
abetical characters, but not all special characters.<br><br>> Speaking o=
f URLs, actually Base 32 (as well as Base 43) makes QR codes *bigger* becau=
se due to the characters used for URL parameters (?&=3D) those QR codes=
are locked to binary mode.<br><br></div><div>I believe that is incorrect. =
Data in QR codes can switch from one mode to another on a per-character bas=
is (with an overhead of a few bits). I don't know to what extent common=
QR encoders make intelligent decisions about this, but it does not seem ve=
ry hard.<br><br></div><div>By Lucas Ontivero:<br><br>> Here I think it c=
ould worth to mention that 58 requires mathematical operations over big num=
bers. This is not very fast and most of the programming languages don't=
provide support for big numbers OOB.<br><br></div><div>It's not that h=
ard to emulate the bignum logic in languages that don't support it. See=
for example this code in Bitcoin Core: <a href=3D"https://github.com/bitco=
in/bitcoin/blob/v0.14.1/src/base58.cpp#L37L53">https://github.com/bitcoin/b=
itcoin/blob/v0.14.1/src/base58.cpp#L37L53</a>. So I think it's not nece=
ssary to go into all the possible ways Base58 can be implemented in the doc=
ument, and the existing language ("Base58 decoding is complicated and =
relatively slow.") is sufficient.<br><br>> I understand that if a n=
ew generic encoding format is introduced that could lead to some confusions=
but what if in the future there is a new type of address that can also be =
encoded with bech32? Don't we need a address type anyway?<br><br></div>=
<div>I believe that it's likely that new types of outputs that may be i=
ntroduced in the future will most likely not be a simple constant byte sequ=
ence that can be computed directly from addresses, but need some processing=
by the sender. This is the case for example for Reusable/Stealth addresses=
and Confidential Transactions addresses. Such outputs, if ever introduced =
on a wide scale, should ideally not be representable as existing address ty=
pes, as that could not only lead to confusion, but also to lost privacy and=
funds.<br><br></div><div>And, If there ever is a need for introducing a &q=
uot;constant scriptPubKey" type address again, the encoding proposed i=
n this document can be reused. Currently, the header value can be at most 1=
7. In the future new proposals could give a meaning to values 18 through 31=
.<br><br><br></div><div>In general:<br><br></div><div>In the past weeks peo=
ple have contributed two new reference implementations (Haskell and Rust), =
and a C++ and Go one are underway (see <a href=3D"https://github.com/sipa/b=
ech32">https://github.com/sipa/bech32</a>).<br><br></div><div>I'd like =
to move forward and request a BIP number assignment for this proposal.<br><=
br><br></div><div>Cheers,<br><br></div><div>-- <br></div><div>Pieter<br><br=
></div></div></div></div>
--94eb2c1961d034b6ce054ef5f453--
|
