From: shiva sitamraju <shiva@blockonomics.co>
To: Ben Thompson <thompson.benedictjames@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses
Date: Mon, 30 Oct 2017 18:43:56 +0530 [thread overview]
Message-ID: <CABuOfui=G_iSaKdeVZ=M_udg-DoqAVxCrHOZaHuSJze4+N7CLw@mail.gmail.com> (raw)
In-Reply-To: <CAOxie=En8EqfuEtaPxH_v-2SYfUunudb4Zu0MQ-ZfEiPMxa6AQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]
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
>>
>
[-- Attachment #2: Type: text/html, Size: 3190 bytes --]
next prev parent reply other threads:[~2017-10-30 13:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-30 8:56 [bitcoin-dev] Visually Differentiable - Bitcoin Addresses shiva sitamraju
2017-10-30 12:14 ` Ricardo Filipe
2017-10-30 14:23 ` Ben Thompson
2017-10-30 12:49 ` Ben Thompson
2017-10-30 13:13 ` shiva sitamraju [this message]
2017-10-30 14:26 ` Pieter Wuille
2017-10-30 14:39 ` Moral Agent
2017-10-30 16:15 ` Danny Thorpe
2017-10-30 16:48 ` Moral Agent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABuOfui=G_iSaKdeVZ=M_udg-DoqAVxCrHOZaHuSJze4+N7CLw@mail.gmail.com' \
--to=shiva@blockonomics.co \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=thompson.benedictjames@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox