From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 83D9AC0C for ; Mon, 30 Oct 2017 14:39:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 02D11542 for ; Mon, 30 Oct 2017 14:39:08 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id v9so22306699oif.13 for ; Mon, 30 Oct 2017 07:39:08 -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=zx7smN7eXzJMUXnD9AnryzPSUNNpBt09a9ez58j07Uw=; b=TkrA80Rg33Hv+Zg6EgeJ+CJ1X2wPWiJ5/0en4LkUMiNUr49EKF5FfOqqYhEahKcBiW 3I0osQ20gDGw6xNYxFwIKwDAtctQGKiGtpal7kvtH1LQkgSraZsqo/q2eSLe9Bh5rXeK F7jqEco9hckFwhckn/J/jvMHJ0jku47EJhr+de7lDfgKFk+h6ycQ0rfVlxjpQAdvfH2f uMxna4e4UPve/dSIasi75+sJZg4M25EeUzuEUO3Gu+pHANRtfCAh7590Z1208a/jk83C lhl0zAoHmbnlqtwvMzkZBa3j8cco0r6SwsJ6Xanoh84/NF7bChrg4entXi9Acyr+OZ34 +e9A== 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=zx7smN7eXzJMUXnD9AnryzPSUNNpBt09a9ez58j07Uw=; b=YnjeObPnQ4cDu0pSZgBPiMGW+P9sPo6bzOJvmQ+7BIUWL0X4cunCwsXGLyBddfJJPM KYe/oNrzxd6aJZ99g0aRi24gO81hH5BAR5XYwjTdNSyOQj0Qx1eNuB7UIHkAyP+x6u4g 7lNBVRxMDPFP8xrRSsLG1/g5+7u2u0I7tDSKASFvQo4mMn44q9sd/DTtSx+qcVRZWcGp 8piWR899Wb+QTTFdgFh9KpVo9wDVq7wQ5Etuj6ZkoMsvLCcFh+cYiLbCnja5NMdxkrxY 4wIIo9mE3kBqiahRZ0aJXiJkRYBcbSfbjQSOvzYKZi2nB7Ig8O3k+hBnhCgMLYVXGN20 4plQ== X-Gm-Message-State: AMCzsaWr/eUk3Tfsn8f7lIhiM8EJ5mTC6Xx5sNoNjP1edKJUSEPaae5F MdKi6SHFXXRbbQZhiUnsYC92i/V5fjct1Bm5ATKV9sYl X-Google-Smtp-Source: ABhQp+RdB1SbEg2u+mbRKqrmbcM3w5AtU2ueyePm2hhetqpfVJa48D3OOoi5lQONpZSsFSQq/9uPxiU8K2/CtjLVSLo= X-Received: by 10.157.14.67 with SMTP id n3mr4991580otd.329.1509374348095; Mon, 30 Oct 2017 07:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.68.169 with HTTP; Mon, 30 Oct 2017 07:39:07 -0700 (PDT) In-Reply-To: References: From: Moral Agent Date: Mon, 30 Oct 2017 10:39:07 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a113ddd50d9f756055cc4999f" X-Spam-Status: No, score=3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, LONGWORDS, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,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 14:43:04 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:39:09 -0000 --001a113ddd50d9f756055cc4999f Content-Type: text/plain; charset="UTF-8" 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 > > --001a113ddd50d9f756055cc4999f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you are going to rely on human verification of addresse= s, the best way might be map it to words.

For example, w= ith a 6000 word list, a 25 byte address (with a checksum) could be mapped t= o 16 words like this:

vocally =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 acquire =C2=A0 =C2=A0 =C2=A0 =C2=A0removed =C2=A0 =C2=A0 unfo= unded
euphemism =C2=A0 =C2=A0sanctuary =C2=A0 =C2=A0sectional =C2= =A0 =C2=A0 driving
entree =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0freckles =C2=A0 =C2=A0aloof =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vertebrae
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

In my opinion, that = is much faster to verify than this:

13gQFTYHuAcfnZ= jXo2NFsy1E8JGSLwXHCZ

or

bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
=

Although I really do love Bech32.

On Mon, Oct 30, 2017 at 9:1= 3 AM, shiva sitamraju via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
For example bc1qeklep85ntjz4605drd= s6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak in 461e8a4aa0a0e75c06602= c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is 62 bytes ! This is= very very long. This will create lot of usability problems in

- Blockexplorers (atleast user should be visually able to comp= are in a transaction having multiple outputs which one his address)
- Mobiles
- Payment terminals

From my limited unde= rstanding, the purpose of inventing a bitcoin address format is for usabili= ty 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=C2=A0 over an address that would wrap several lines= !!


O= n Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson <thompson.ben= edictjames@gmail.com> wrote:
Checking the first few bytes of a Bitcoin Address s= hould not be considered sufficient for ensuring that it is correct as it ta= kes less than a second to generate a 3 character vanity address that matche= s the first 3 characters of an address.

On Mon, 30 Oct 2017, 11:44 shiva sitamraju via bit= coin-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 t= aking as step in the backward direction. With the traditional address, I co= uld 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 wi= ll only compare the first few bytes only (since addresses themselves are ve= ry long and will overflow in a mobile text box).

Is there anyw= ay 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


--001a113ddd50d9f756055cc4999f--