path: root/f4/616b8b9c0a0cce2efc51accfc308aa43e00cbc

Return-Path: <ethan.scruples@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C9250BAF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 30 Oct 2017 16:48:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com
	[209.85.218.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D9CE456E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 30 Oct 2017 16:48:10 +0000 (UTC)
Received: by mail-oi0-f54.google.com with SMTP id c202so23121096oih.9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 30 Oct 2017 09:48:10 -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=TSYBEpLvarVExp8G6fbxWYVcDCPmRamT84M8x2RYmPc=;
	b=II4tyQ69W8UzObBCzvvSi0gCf1FS2CIGi+37ErohYgyNHf4HJZB4adwj86VNPXxpPk
	f2/x0jKlvBBl1QhFAS68DT8D5iYfToDiVQIFQSoYxWKiGQ5y8gdCsT5r9eTj2vsi7e6Y
	cFadl9VEax1F77agbfaO8+u3yqLYoUrV8mtZnJGJYDX5nd6KtKC2FdLYQOfZ5M4fExhn
	C2vMkDj4b8t92tbFK+w+0tViON0irdNk2tsLH6v+cjYNOcIdiXROeLsQFs1WOSrx9V/7
	P0Xw1vRz9Tj4CkRUwUa3Z3BQDD1jdgFf4vAfMuROFO97U4ts01UZS1vVXIqaJOVf3wUW
	rJLw==
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=TSYBEpLvarVExp8G6fbxWYVcDCPmRamT84M8x2RYmPc=;
	b=L9NkHDjAl3RoRV3OMaQAihuyfiaTTcSXE7Esm9RGyApdzr8qDboi3nAxv3lz1fqav2
	t8VTYurkqM7Nb0OUYFW3sjdAJeBaw/nWXVLXjMfgVt9YEb41N/BJHYWQbD+KNJhp6vwH
	W4wC49Iq0Fr7exVKHvSsu10RlTBDAoGV9kZLVQo+61BRRWshI/RO8MSpT56fZAoKr3ir
	UNR5R/ILcLQgJnuuvCW34XMk/qfERHqMDbVh7aWpXVWAO02/wa8Y/Rl7YIDUuFhXZf/C
	/+rTv8P3OPJZL7ZWDtD6LBRYsRezieyBNtzb2fTK1iotoF//qDFMOzI6jPUm03s3cs0r
	SeZw==
X-Gm-Message-State: AMCzsaWQeepr11+5482byQmdWiSdkJUWlCJ6ognO3J6EN7W8sq7VtxVi
	NwqzdE5JKpSmgWXS8lpPnHre+LKSUy7Op6d3sQLthdw7
X-Google-Smtp-Source: ABhQp+SU+8RHM9/jImONDAu+HiR0kYSgqGgVo269deNty7pmDQeehAj+bx6fBm0bSAX6I8BHx+RVfnk/RQcFFXB6amU=
X-Received: by 10.202.82.213 with SMTP id g204mr4581637oib.129.1509382090001; 
	Mon, 30 Oct 2017 09:48:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.68.169 with HTTP; Mon, 30 Oct 2017 09:48:09 -0700 (PDT)
In-Reply-To: <CAJN5wHW=ySsCxR237TAzXyqXf1VixsA2T7qCA8FCS12PPabU+Q@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>
	<CAJN5wHW=ySsCxR237TAzXyqXf1VixsA2T7qCA8FCS12PPabU+Q@mail.gmail.com>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Mon, 30 Oct 2017 12:48:09 -0400
Message-ID: <CACiOHGz+Knj9LNHfNs4KKgMzb-KyRrDV-6ZWAskiz4Ab2sdTyg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113dea0a4e13e4055cc66731"
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
X-Mailman-Approved-At: Mon, 30 Oct 2017 16:49:44 +0000
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:48:11 -0000

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

Or like keyart:
https://pthree.org/2014/04/18/the-drunken-bishop-for-openpgp-keys/

Images would definitely be quicker to verify by a human, but I don't think
humans can RELIABLY verify anything close to 25 bytes through an image.

Our visual processing system is designed wrong for this purpose, since it
subconsciously "corrects" visual input to whatever we expect to see.

It isn't enough to say that any small change produces a "significantly"
different image. What you need is for it to be (practically) impossible to
construct an image that looks similar but is wrong, which is a far higher
standard. For example, any change to a private key renders a significantly
different address -- but it is possible for an attacker to grind their way
to a similar-looking address.

I would recommend displaying 16 words in a 4 x 4 grid, but otherwise with
no visual distractions.

For example, don't provide an image next to the words as a help. Don't use
colors to differentiate two different sets of 16 words. What will happen is
people will see a pattern that triggers a sensation of familiarity, and
they will not carefully verify all of the words -- which is what security
requires.

For higher security keys, you could grind an address with enough zeros at
the beginning to be expressed by fewer words. For example, you could grind
to an address that could be fully expressed with a 12 word (4 x 3) grid
that would be easier for a human to verify reliably.

On Mon, Oct 30, 2017 at 12:15 PM, Danny Thorpe <danny.thorpe@gmail.com>
wrote:

> 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
>>
>>

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

<div dir=3D"ltr">Or like keyart: <a href=3D"https://pthree.org/2014/04/18/t=
he-drunken-bishop-for-openpgp-keys/">https://pthree.org/2014/04/18/the-drun=
ken-bishop-for-openpgp-keys/</a><div><br></div><div>Images would definitely=
 be quicker to verify by a human, but I don&#39;t think humans can RELIABLY=
 verify anything close to 25 bytes through an image.</div><div><br></div><d=
iv>Our visual processing system is designed wrong for this purpose, since i=
t subconsciously &quot;corrects&quot; visual input to whatever we expect to=
 see.</div><div><br></div><div>It isn&#39;t enough to say that any small ch=
ange produces a &quot;significantly&quot; different image. What you need is=
 for it to be (practically) impossible to construct an image that looks sim=
ilar but is wrong, which is a far higher standard. For example, any change =
to a private key renders a significantly different address -- but it is pos=
sible for an attacker to grind their way to a similar-looking address.</div=
><div><br></div><div>I would recommend displaying 16 words in a 4 x 4 grid,=
 but otherwise with no visual distractions.</div><div><br></div><div>For ex=
ample, don&#39;t provide an image next to the words as a help. Don&#39;t us=
e colors to differentiate two different sets of 16 words. What will happen =
is people will see a pattern that triggers a sensation of familiarity, and =
they will not carefully verify all of the words -- which is what security r=
equires.</div><div><br></div><div>For higher security keys, you could grind=
 an address with enough zeros at the beginning to be expressed by fewer wor=
ds. For example, you could grind to an address that could be fully expresse=
d with a 12 word (4 x 3) grid that would be easier for a human to verify re=
liably.</div><div><br></div><div><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">On Mon, Oct 30, 2017 at 12:15 PM, Danny Thorpe <span dir=3D"ltr=
">&lt;<a href=3D"mailto:danny.thorpe@gmail.com" target=3D"_blank">danny.tho=
rpe@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"auto">Humans are very visually oriented, recogniz=
ing differences in images more easily than differences in text.<div dir=3D"=
auto"><br></div><div dir=3D"auto">What about generating an image based on t=
he bytes of an address, using something like identicon, used by gravatar? A=
ny small change to the text input produces a significantly different image.=
<span class=3D"gmail-m_-8494545171858514266HOEnZb"><font color=3D"#888888">=
<div dir=3D"auto"><br></div><div dir=3D"auto">-Danny</div></font></span></d=
iv></div><div class=3D"gmail-m_-8494545171858514266HOEnZb"><div class=3D"gm=
ail-m_-8494545171858514266h5"><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Oct 30, 2017 7:43 AM, &quot;Moral Agent via bitcoin-dev&quo=
t; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br type=3D=
"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr">If you are going to rely on human verification of addresses, the best=
 way might be map 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=A0surround =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 verify than this:</div><div><br></div><div>13gQFTYHuAcfnZjXo2NFs=
y1E8JGSLw<wbr>XHCZ<br></div><div><br></div><div>or</div><div><br></div><div=
>bc1qrp33g0q5c5txsp9arysrx4k6zd<wbr>kfs4nce4xj0gdcccefvpysxf3qccfm<wbr>v3<b=
r></div><div><br></div><div>Although I really do love Bech32.</div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Oct 30, 201=
7 at 9:13 AM, shiva sitamraju via bitcoin-dev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><div><div>Fo=
r example bc1qeklep85ntjz4605drds6aww9u0<wbr>qr46qzrv5xswd35uhjuj8ahfcqgf6h=
<wbr>ak in 461e8a4aa0a0e75c06602c505bd7aa<wbr>06e7116ba5cd98fd6e046e8cbeb00=
3<wbr>79d6 is 62 bytes ! This is very very long. This will create lot of us=
ability problems in <br></div><div><br></div>- Blockexplorers (atleast user=
 should be visually able to compare in a transaction having multiple output=
s which one his address)<br></div>- Mobiles<br></div>- Payment terminals <b=
r><br></div>From my limited understanding, the purpose of inventing a bitco=
in address format is for usability and ease of identification (versus a ECD=
SA public key), While I get the error/checksum capabilities Bech32 brings, =
any user would prefer a 20 byte address with a checksum=C2=A0 over an addre=
ss that would wrap several lines !! <br><div><div><div><br></div></div></di=
v></div><div class=3D"gmail-m_-8494545171858514266m_-5242580271745374777m_2=
858999446994048619HOEnZb"><div class=3D"gmail-m_-8494545171858514266m_-5242=
580271745374777m_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@gmail.com" target=
=3D"_blank">thompson.benedictjames@gmail.<wbr>com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Checking=
 the first few bytes of a Bitcoin Address should not be considered sufficie=
nt for ensuring that it is correct as it takes less than a second to genera=
te a 3 character vanity address that matches the first 3 characters of an a=
ddress.</div><span>
</span><br><div class=3D"gmail_quote"><div><div class=3D"gmail-m_-849454517=
1858514266m_-5242580271745374777m_2858999446994048619m_-3543602302739662677=
h5"><div dir=3D"ltr">On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bitcoin=
-dev, &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br></=
div></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div=
 class=3D"gmail-m_-8494545171858514266m_-5242580271745374777m_2858999446994=
048619m_-3543602302739662677h5"><div dir=3D"ltr"><div><div><div>Hi,<br><br>=
</div>When I copy and paste bitcoin address, I double check the first few b=
ytes, to make sure I copied the correct one. This is to make sure some rogu=
e software is not changing the address, or I incorrectly pasted the wrong a=
ddress.<br><br><br></div>With Bech32 address, its seems like in this depart=
ment 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 them=
selves 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><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" 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></div>
</div></div></blockquote></div><br></div></div></div>

--001a113dea0a4e13e4055cc66731--