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
|
Return-Path: <shiva@blockonomics.co>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 47E87BD7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Oct 2017 13:14:25 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from blockonomics.co (blockonomics.co [52.10.115.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B87D9175
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Oct 2017 13:14:24 +0000 (UTC)
Received: from mail-ua0-f171.google.com (mail-ua0-f171.google.com
[209.85.217.171])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by blockonomics.co (Postfix) with ESMTPSA id 027C81EBC25
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Oct 2017 13:14:24 +0000 (UTC)
Received: by mail-ua0-f171.google.com with SMTP id n38so9410736uai.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Oct 2017 06:14:23 -0700 (PDT)
X-Gm-Message-State: AMCzsaWvcUw74Su+JeHb57UcW7AARXbkhdJBEo4jToXYb37PIOvvu7qX
s9lg96AXx+afaDFh6GeAjY0kR6Bq8G42zabwgw==
X-Google-Smtp-Source: ABhQp+R7HvGv4RpD/U3KVe5CJ3t3oDMwGJrDIvOiQitmz2RG6XJnCyPmNJuRiAqpF3BVaM+wnn03ppOZ8CfRAiILNXY=
X-Received: by 10.176.78.209 with SMTP id x17mr7066028uah.113.1509369262915;
Mon, 30 Oct 2017 06:14:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.7.212 with HTTP; Mon, 30 Oct 2017 06:13:56 -0700 (PDT)
In-Reply-To: <CAOxie=En8EqfuEtaPxH_v-2SYfUunudb4Zu0MQ-ZfEiPMxa6AQ@mail.gmail.com>
References: <CABuOfujV1gAaSOKBB7S0_JKuwp+3iNhY5kN59F3LLndPENUA_Q@mail.gmail.com>
<CAOxie=En8EqfuEtaPxH_v-2SYfUunudb4Zu0MQ-ZfEiPMxa6AQ@mail.gmail.com>
From: shiva sitamraju <shiva@blockonomics.co>
Date: Mon, 30 Oct 2017 18:43:56 +0530
X-Gmail-Original-Message-ID: <CABuOfui=G_iSaKdeVZ=M_udg-DoqAVxCrHOZaHuSJze4+N7CLw@mail.gmail.com>
Message-ID: <CABuOfui=G_iSaKdeVZ=M_udg-DoqAVxCrHOZaHuSJze4+N7CLw@mail.gmail.com>
To: Ben Thompson <thompson.benedictjames@gmail.com>
Content-Type: multipart/alternative; boundary="089e08e512d9c043ff055cc36a83"
X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,RP_MATCHES_RCVD
autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 30 Oct 2017 14:19:17 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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 13:14:25 -0000
--089e08e512d9c043ff055cc36a83
Content-Type: text/plain; charset="UTF-8"
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
>>
>
--089e08e512d9c043ff055cc36a83
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>For example bc1qeklep85ntjz4605drds6aw=
w9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak in 461e8a4aa0a0e75c06602c505bd7aa06e71=
16ba5cd98fd6e046e8cbeb00379d6 is 62 bytes ! This is very very long. This wi=
ll create lot of usability problems in <br></div><div><br></div>- Blockexpl=
orers (atleast user should be visually able to compare in a transaction hav=
ing multiple outputs which one his address)<br></div>- Mobiles<br></div>- P=
ayment terminals <br><br></div>From my limited understanding, the purpose o=
f inventing a bitcoin address format is for usability and ease of identific=
ation (versus a ECDSA public key), While I get the error/checksum capabilit=
ies Bech32 brings, any user would prefer a 20 byte address 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"gmail_extra"><br><div class=3D"gm=
ail_quote">On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <span dir=3D"ltr">=
<<a href=3D"mailto:thompson.benedictjames@gmail.com" target=3D"_blank">t=
hompson.benedictjames@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Checking the first few bytes of a Bitcoin Ad=
dress should not be considered sufficient for ensuring that it is correct a=
s it takes less than a second to generate a 3 character vanity address that=
matches the first 3 characters of an address.</div><span>
</span><br><div class=3D"gmail_quote"><div><div class=3D"h5"><div dir=3D"lt=
r">On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin-dev, <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br></div></div></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div><d=
iv><div>Hi,<br><br></div>When I copy and paste bitcoin address, I double ch=
eck 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.<br><br><br></div>With Bech32 address, its seems =
like in this department we are taking as step in the backward direction. Wi=
th 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 (s=
ince addresses themselves are very long and will overflow in a mobile text =
box).<br><br></div>Is there anyway to make the Bech32 addresses format more=
visually distinct (atleast the first few bytes) ? <br></div></div></div><s=
pan class=3D"">
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</span></blockquote></div>
</blockquote></div><br></div>
--089e08e512d9c043ff055cc36a83--
|
