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 47E87BD7 for ; 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 ; 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 ; Mon, 30 Oct 2017 13:14:24 +0000 (UTC) Received: by mail-ua0-f171.google.com with SMTP id n38so9410736uai.11 for ; 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: References: From: shiva sitamraju Date: Mon, 30 Oct 2017 18:43:56 +0530 X-Gmail-Original-Message-ID: Message-ID: To: Ben Thompson 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 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 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
For example bc1qeklep85ntjz4605drds6aw= w9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak in 461e8a4aa0a0e75c06602c505bd7aa06e71= 16ba5cd98fd6e046e8cbeb00379d6 is 62 bytes ! This is very very long. This wi= ll create lot of usability problems in

- Blockexpl= orers (atleast user should be visually able to compare in a transaction hav= ing multiple outputs which one his address)
- Mobiles
- P= ayment terminals

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

On Mon, Oct 30, 2017 at 6:19 PM, Ben Thompson = <t= hompson.benedictjames@gmail.com> wrote:
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.

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


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

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