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
|
Return-Path: <lucasontivero@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 27FD9B1F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 04:50:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com
[209.85.218.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85C357C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Mar 2017 04:50:55 +0000 (UTC)
Received: by mail-oi0-f42.google.com with SMTP id o67so19419192oib.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 21:50:55 -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=w5x4hg18zA5zGteKLiVXOwK/vufDPS/Eh08LvhoKEDk=;
b=K3ggnB7RQoG8gf+Tp4Zpdoc8llVfMaOBvg2T9rLW2deYPtsHNGz7tup6HpfwS7u4p1
zcOB2994/O1jVoQiSqifLRXpiHRCpRCoZXSbgK5tsLyHRYNw3viqHF8102zncEp+5Ryi
3dgmlvaWEsIfoSqunvQ5a7kllpywnw5XP7xO8sSec4ZDI5emmirD4WnZ9F/Y4yIT6WOM
Ss4ZiMroJcHpG1h2Ur6xValQ/iO4cYkRYGfVlwFQO9SwXdtQF13GXuIwpl9nKeZX35iq
qRvn1eT8+lKmVpMWaa6XMB1GuitOW/Bp4Siy+pqL7WsWhErUb+7UIbv8L4H1r3xqJam+
32iw==
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=w5x4hg18zA5zGteKLiVXOwK/vufDPS/Eh08LvhoKEDk=;
b=kzKOwhvLoTpaHqufwTOFMvFO7D9K0RICUdW8uSyecuxHbtGOb4XtHJH4VV0eH4Ty5h
Wz/a4WGfxUcwtOo8wVBzUV2GtgfHYbWGrJSehasxvbCBUTGx/NSraoYU+SzT25f+l5e/
joZrxG4Qcf1xclDOPCA2hBXxbwSxJjcM1gTlFc0LTy0pe6qhQPhli5m74XORrp4odksd
YWo5bd1dk9PPYXmdRz911dSFhAch7jOCLYysqjI4ZdIyhp2lZVqIYG2tlKtKLxGX/pbI
qsAHrzET3J+aGMJDZfOPShWuT2+FcST9WSTlLOQUa8ZVk9MhsvAIljBYjVpbhJwS120x
OM0g==
X-Gm-Message-State: AFeK/H3++fawIMho9tHW/IuD7GkXH4F3ksgycEwLBm0ypS7AMLA5kQu7C4o1BEXFD4QYy1a4zyut+8nnfv4bjA==
X-Received: by 10.157.5.139 with SMTP id 11mr2012891otd.43.1490849454809; Wed,
29 Mar 2017 21:50:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.28.70 with HTTP; Wed, 29 Mar 2017 21:50:54 -0700 (PDT)
In-Reply-To: <obg116$sa2$1@blaine.gmane.org>
References: <CAPg+sBh0sFA7b6a+48Oojwy655GB9W6Th8JiCpd+2ruQjPev8Q@mail.gmail.com>
<oarjko$8fp$1@blaine.gmane.org>
<20170321191454.GA17834@savin.petertodd.org>
<obg116$sa2$1@blaine.gmane.org>
From: Lucas Ontivero <lucasontivero@gmail.com>
Date: Thu, 30 Mar 2017 01:50:54 -0300
Message-ID: <CALHvQn1pTUeqhgq8pkFEAmmjN+vWk6QUS2hW_jNNfwbCPW4D_Q@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1137281c2b36ef054beb704d
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: Thu, 30 Mar 2017 05:28:40 +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: Thu, 30 Mar 2017 04:50:56 -0000
--001a1137281c2b36ef054beb704d
Content-Type: text/plain; charset=UTF-8
I don't know if i should response to this mail list or make a comment in
commit file (
https://github.com/sipa/bech32/commit/52b5a0fa6d3174c4150393fb7d6b58d34b4f5e0b#diff-d23a42e5c904045098e8f8b1189f481e
)
* Motivation:
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.
* Why not make an address format that is generic for all scriptPubKeys?:
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?
thx
2017-03-29 7:07 GMT-03:00 Andreas Schildbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote:
> > On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via
> bitcoin-dev wrote:
> >> Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
> >> In Bitcoin Wallet, I use Base 43 (alphabet:
> >> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
> >> code encoding. I only leave out the space character because it gets
> >> replaced by "+" in URLs.
> >
> > Doing that only makes addresses a few % shorter, at the cost of
> significant
> > downsides. For example, not everyone knows what those additional
> characters
> > are called, particularly for non-English-speaking users. Non-alphanumeric
> > characters also complicate using the addresses in a variety of contexts
> ('/'
> > in particularly isn't valid in filenames).
>
> I'm not convinced that transmitting addresses via voice should be a
> usecase to target at. 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.
>
> Addresses in QR codes, addresses in URLs and addresses in NFC NDEF
> messages are the three most used forms.
>
> 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. To make them shorter, we'd
> need to use something like "Base 64url" (or ideally Base 94 -- all
> printable ASCII characters).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a1137281c2b36ef054beb704d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't know if i should response to this mail list or=
make a comment in commit file (<a href=3D"https://github.com/sipa/bech32/c=
ommit/52b5a0fa6d3174c4150393fb7d6b58d34b4f5e0b#diff-d23a42e5c904045098e8f8b=
1189f481e">https://github.com/sipa/bech32/commit/52b5a0fa6d3174c4150393fb7d=
6b58d34b4f5e0b#diff-d23a42e5c904045098e8f8b1189f481e</a>)<br><br>* Motivati=
on:<div><br></div><div>Here I think it could worth to mention that 58 requi=
res mathematical operations over big numbers. This is not very fast and mos=
t of the programming languages don't provide support for big numbers OO=
B.<br><br>* Why not make an address format that is generic for all scriptPu=
bKeys?:=C2=A0</div><div><br></div><div>I understand that if a new generic e=
ncoding 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?</div><div><br></div><div>=
thx</div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">2017-03-29 7:07 GMT-03:00 Andreas Schildbach via bitcoin-dev <=
span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span>:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D"">On 03/21/2017 08:14 PM, =
Peter Todd via bitcoin-dev wrote:<br>
> On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via bitco=
in-dev wrote:<br>
>> Why use Base 32 when the QR code alphanumeric mode allows 44 chara=
cters?<br>
>> In Bitcoin Wallet, I use Base 43 (alphabet:<br>
>> "<wbr>0123456789ABCDEFGHIJKLMNOPQRST<wbr>UVWXYZ$*+-./:")=
for most efficient QR<br>
>> code encoding. I only leave out the space character because it get=
s<br>
>> replaced by "+" in URLs.<br>
><br>
> Doing that only makes addresses a few % shorter, at the cost of signif=
icant<br>
> downsides.=C2=A0 For example, not everyone knows what those additional=
characters<br>
> are called, particularly for non-English-speaking users. Non-alphanume=
ric<br>
> characters also complicate using the addresses in a variety of context=
s ('/'<br>
> in particularly isn't valid in filenames).<br>
<br>
</span>I'm not convinced that transmitting addresses via voice should b=
e a<br>
usecase to target at. I don't understand your comment about non-english=
<br>
speaking users. Obviously they cannot voice-communicate at all with<br>
only-english-speaking users, so there is no need to communicate<br>
voice-communicate addresses between them.<br>
<br>
Addresses in QR codes, addresses in URLs and addresses in NFC NDEF<br>
messages are the three most used forms.<br>
<br>
Speaking of URLs, actually Base 32 (as well as Base 43) makes QR codes<br>
*bigger* because due to the characters used for URL parameters (?&=3D)<=
br>
those QR codes are locked to binary mode. To make them shorter, we'd<br=
>
need to use something like "Base 64url" (or ideally Base 94 -- al=
l<br>
printable ASCII characters).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<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>
--001a1137281c2b36ef054beb704d--
|
