summaryrefslogtreecommitdiff
path: root/a9/2d07ff53cf2c7fb986ed292772dc79ac0832bb
blob: 6a7b615d12bbc9556978cc4d5105f5542ed287b7 (plain)
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
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
Return-Path: <danny.thorpe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A15E5BF0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 30 Oct 2017 16:15:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com
	[209.85.192.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 278AD16A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 30 Oct 2017 16:15:47 +0000 (UTC)
Received: by mail-pf0-f173.google.com with SMTP id z11so11396978pfk.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 30 Oct 2017 09:15:47 -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=gvPOjnyJZ0myWenc018WwjYgRyKYuPl9Mx0XGFnHe/U=;
	b=kZLQ4uDHhCzmE1weCsX1stYdxWS0dbSdc2/GfyCbira7BUz0tI0GiIu6MvYDUoaX6K
	V4qmCc2vAZKI01blTZMqecCfJ0qtg7xETF0ysOJMuDVwH8F97H9cXs2pFb1yLHijs6Vl
	DVJ1JZ0aWg5JD/pWIelsHaNUyTnJruG/r7RGHq5Uif8YOo1xpDcs+eXROrjJirGs2REd
	pr1fWg4b3+R6ZOrVxRd0BggpgHr7ueISY89JwOtSb4+jtH/Hdi5PrTrwcyjl96Rw+epE
	gxUpvRQXED4U/bc0+8uIpx2USK/nlyNkN2jEDRlPJ0Emszt2PnHVeitFLoYSaWnNcdMy
	dM9g==
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=gvPOjnyJZ0myWenc018WwjYgRyKYuPl9Mx0XGFnHe/U=;
	b=VZEXoxwfnh2RDhVMv0iTVr1Act7fYsM00wWgpuNvGBV77Vc6t01hCc7dit7d2UiRm0
	s8q4UDhBTVtdNE1jUsZiz295ln4SMdfalgWqM5YBmLTuRw+r7X+q0BR9r+sYnClyhwjY
	OEfxop5lHq1JllvYD1CB1IHG26IeIYcMHqlJgFj8BDxk73k9cllFnzD5NnqCoUIBQdDj
	WAhIi0prXQiZa6s1YAxyuGbmQL9PNsnDOIoMEI6BFgMqd4jLMutxJhW2EfN73NJ6JcFB
	RT1XJzNPwPQkkAR84ZDtexQL+tdUoSbLcagXNZFjmyG9fw+GXOssFRbmtWhbOGAy0hc8
	H9Eg==
X-Gm-Message-State: AMCzsaW6Vayyf7thi14vGGPTskBVwccH4yKAmo67RIKv6e/o6eu+331t
	CFj632vyippRKwPYul/V0TtTAOuw6tbpbDo3rS3Tvw==
X-Google-Smtp-Source: ABhQp+TIfBYXFHwuopHF8t2Po5M8RXZK4OKzx0a4zhk4dCRy6x+R1sFVjFpKCyiDft4nrKjzpb1cS3ETru0Y3bwnxKk=
X-Received: by 10.98.162.26 with SMTP id m26mr9354387pff.0.1509380146495; Mon,
	30 Oct 2017 09:15:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.179.202 with HTTP; Mon, 30 Oct 2017 09:15:45 -0700 (PDT)
Received: by 10.100.179.202 with HTTP; Mon, 30 Oct 2017 09:15:45 -0700 (PDT)
In-Reply-To: <CACiOHGxYuqCONJzVm=zD2qkS4BR+Pvm9Ccofh_SCH-uzmW-LwA@mail.gmail.com>
References: <CABuOfujV1gAaSOKBB7S0_JKuwp+3iNhY5kN59F3LLndPENUA_Q@mail.gmail.com>
	<CAOxie=En8EqfuEtaPxH_v-2SYfUunudb4Zu0MQ-ZfEiPMxa6AQ@mail.gmail.com>
	<CABuOfui=G_iSaKdeVZ=M_udg-DoqAVxCrHOZaHuSJze4+N7CLw@mail.gmail.com>
	<CACiOHGxYuqCONJzVm=zD2qkS4BR+Pvm9Ccofh_SCH-uzmW-LwA@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
Date: Mon, 30 Oct 2017 09:15:45 -0700
Message-ID: <CAJN5wHW=ySsCxR237TAzXyqXf1VixsA2T7qCA8FCS12PPabU+Q@mail.gmail.com>
To: Moral Agent <ethan.scruples@gmail.com>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403043be61c768379055cc5f38a"
X-Spam-Status: No, score=1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,HTML_OBFUSCATE_05_10,
	RCVD_IN_DNSWL_NONE,TRACKER_ID autolearn=disabled version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Visually Differentiable - Bitcoin 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: Mon, 30 Oct 2017 16:15:47 -0000

--f403043be61c768379055cc5f38a
Content-Type: text/plain; charset="UTF-8"

Humans are very visually oriented, recognizing differences in images more
easily than differences in text.

What about generating an image based on the bytes of an address, using
something like identicon, used by gravatar? Any small change to the text
input produces a significantly different image.

-Danny

On Oct 30, 2017 7:43 AM, "Moral Agent via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If you are going to rely on human verification of addresses, the best way
> might be map it to words.
>
> For example, with a 6000 word list, a 25 byte address (with a checksum)
> could be mapped to 16 words like this:
>
> vocally           acquire        removed     unfounded
> euphemism    sanctuary    sectional     driving
> entree            freckles    aloof           vertebrae
> scribble          surround      prelaw         effort
>
> In my opinion, that is much faster to verify than this:
>
> 13gQFTYHuAcfnZjXo2NFsy1E8JGSLwXHCZ
>
> or
>
> bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
>
> Although I really do love Bech32.
>
> On Mon, Oct 30, 2017 at 9:13 AM, shiva sitamraju via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak
>> in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is
>> 62 bytes ! This is very very long. This will create lot of usability
>> problems in
>>
>> - Blockexplorers (atleast user should be visually able to compare in a
>> transaction having multiple outputs which one his address)
>> - Mobiles
>> - Payment terminals
>>
>> From my limited understanding, the purpose of inventing a bitcoin address
>> format is for usability and ease of identification (versus a ECDSA public
>> key), While I get the error/checksum capabilities Bech32 brings, any user
>> would prefer a 20 byte address with a checksum  over an address that would
>> wrap several lines !!
>>
>>
>> On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <
>> thompson.benedictjames@gmail.com> wrote:
>>
>>> Checking the first few bytes of a Bitcoin Address should not be
>>> considered sufficient for ensuring that it is correct as it takes less than
>>> a second to generate a 3 character vanity address that matches the first 3
>>> characters of an address.
>>>
>>> On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> When I copy and paste bitcoin address, I double check the first few
>>>> bytes, to make sure I copied the correct one. This is to make sure some
>>>> rogue software is not changing the address, or I incorrectly pasted the
>>>> wrong address.
>>>>
>>>>
>>>> With Bech32 address, its seems like in this department we are taking as
>>>> step in the backward direction. With the traditional address, I could
>>>> compare first few bytes like 1Ko or 1L3. With bech32, bc1. is all I can see
>>>> and compare which is likely to be same anyway. Note that most users will
>>>> only compare the first few bytes only (since addresses themselves are very
>>>> long and will overflow in a mobile text box).
>>>>
>>>> Is there anyway to make the Bech32 addresses format more visually
>>>> distinct (atleast the first few bytes) ?
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--f403043be61c768379055cc5f38a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Humans are very visually oriented, recognizing difference=
s in images more easily than differences in text.<div dir=3D"auto"><br></di=
v><div dir=3D"auto">What about generating an image based on the bytes of an=
 address, using something like identicon, used by gravatar? Any small chang=
e to the text input produces a significantly different image.<div dir=3D"au=
to"><br></div><div dir=3D"auto">-Danny</div></div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Oct 30, 2017 7:43 AM, &quot;Moral=
 Agent via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=
=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">If you are=
 going to rely on human verification of addresses, the best way might be ma=
p it to words.<div><br></div><div>For example, with a 6000 word list, a 25 =
byte address (with a checksum) could be mapped to 16 words like this:<div><=
br></div><div><div>vocally =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acquire =C2=
=A0 =C2=A0 =C2=A0 =C2=A0removed =C2=A0 =C2=A0 unfounded</div><div>euphemism=
 =C2=A0 =C2=A0sanctuary =C2=A0 =C2=A0sectional =C2=A0 =C2=A0 driving</div><=
div>entree =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0freckles <span style=3D=
"white-space:pre-wrap">	</span>=C2=A0 =C2=A0aloof =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 vertebrae</div><div>scribble =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s=
urround =C2=A0 =C2=A0 =C2=A0prelaw =C2=A0 =C2=A0 =C2=A0 =C2=A0 effort</div>=
</div></div><div><br></div><div>In my opinion, that is much faster to verif=
y than this:</div><div><br></div><div>13gQFTYHuAcfnZjXo2NFsy1E8JGSLw<wbr>XH=
CZ<br></div><div><br></div><div>or</div><div><br></div><div>bc1qrp33g0q5c5t=
xsp9arysrx4k6zd<wbr>kfs4nce4xj0gdcccefvpysxf3qccfm<wbr>v3<br></div><div><br=
></div><div>Although I really do love Bech32.</div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Mon, Oct 30, 2017 at 9:13 AM, sh=
iva sitamraju via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>=
linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div><div><div>For example bc1qeklep85ntjz4605drds6a=
ww9u0<wbr>qr46qzrv5xswd35uhjuj8ahfcqgf6h<wbr>ak in 461e8a4aa0a0e75c06602c50=
5bd7aa<wbr>06e7116ba5cd98fd6e046e8cbeb003<wbr>79d6 is 62 bytes ! This is ve=
ry very long. This will create lot of usability problems in <br></div><div>=
<br></div>- Blockexplorers (atleast user should be visually able to compare=
 in a transaction having multiple outputs which one his address)<br></div>-=
 Mobiles<br></div>- Payment terminals <br><br></div>From my limited underst=
anding, the purpose of inventing a bitcoin address format is for usability =
and ease of identification (versus a ECDSA public key), While I get the err=
or/checksum capabilities Bech32 brings, any user would prefer a 20 byte add=
ress with a checksum=C2=A0 over an address that would wrap several lines !!=
 <br><div><div><div><br></div></div></div></div><div class=3D"m_28589994469=
94048619HOEnZb"><div class=3D"m_2858999446994048619h5"><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Mon, Oct 30, 2017 at 6:19 PM, Ben =
Thompson <span dir=3D"ltr">&lt;<a href=3D"mailto:thompson.benedictjames@gma=
il.com" target=3D"_blank">thompson.benedictjames@gmail.<wbr>com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Checking the =
first few bytes of a Bitcoin Address should not be considered sufficient fo=
r ensuring that it is correct as it takes less than a second to generate a =
3 character vanity address that matches the first 3 characters of an addres=
s.</div><span>
</span><br><div class=3D"gmail_quote"><div><div class=3D"m_2858999446994048=
619m_-3543602302739662677h5"><div dir=3D"ltr">On Mon, 30 Oct 2017, 11:44 sh=
iva sitamraju via bitcoin-dev, &lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.o=
rg</a>&gt; wrote:<br></div></div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>=
<div class=3D"m_2858999446994048619m_-3543602302739662677h5"><div dir=3D"lt=
r"><div><div><div>Hi,<br><br></div>When I copy and paste bitcoin address, I=
 double check the first few bytes, to make sure I copied the correct one. T=
his is to make sure some rogue software is not changing the address, or I i=
ncorrectly pasted the wrong address.<br><br><br></div>With Bech32 address, =
its seems like in this department we are taking as step in the backward dir=
ection. With the traditional address, I could compare first few bytes like =
1Ko or 1L3. With bech32, bc1. is all I can see and compare which is likely =
to be same anyway. Note that most users will only compare the first few byt=
es only (since addresses themselves are very long and will overflow in a mo=
bile text box).<br><br></div>Is there anyway to make the Bech32 addresses f=
ormat more visually distinct (atleast the first few bytes) ? <br></div></di=
v></div><span>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
</span></blockquote></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
<br></blockquote></div><br></div>
<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>
<br></blockquote></div></div>

--f403043be61c768379055cc5f38a--