From: Pieter Wuille <pieter.wuille@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A BIP proposal for segwit addresses
Date: Sun, 7 May 2017 14:39:14 -0700 [thread overview]
Message-ID: <CAPg+sBiPiLHZFoYY=gs6LT+Q2Kb5NmbVU05u7c+0WRPjveBJhQ@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBh0sFA7b6a+48Oojwy655GB9W6Th8JiCpd+2ruQjPev8Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3795 bytes --]
On Mon, Mar 20, 2017 at 2:35 PM, Pieter Wuille <pieter.wuille@gmail•com>
wrote:
> Hello everyone,
>
> You can find the text here:
> https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki
>
Responding to a few comments:
By Andreas Schildbach:
> I'm not convinced that transmitting addresses via voice should be a
usecase to target at
I think it should be. It's certainly not the most important way through
which addresses are communicated or verified, but I am trying to address
all places where humans interact with addresses. I have certainly tried to
verify addresses a few times through voice, when dealing with significant
amounts.
Regarding your QR code comments: it is certainly possible to find a more
compact QR code representation. That is not the goal of the BIP though -
it's trying to introduce one commonly recognizable format that has good
properties for all use cases, even if that means being suboptimal in
certain aspects for some.
> I don't understand your comment about non-english speaking users.
Obviously they cannot voice-communicate at all with only-english-speaking
users, so there is no need to communicate voice-communicate addresses
between them.
I assume that Peter Todd is talking about cases where English speakers are
interacting with non-native English speakers, who may know how to pronounce
numbers or alphabetical characters, but not all special characters.
> Speaking of URLs, actually Base 32 (as well as Base 43) makes QR codes
*bigger* because due to the characters used for URL parameters (?&=) those
QR codes are locked to binary mode.
I believe that is incorrect. Data in QR codes can switch from one mode to
another on a per-character basis (with an overhead of a few bits). I don't
know to what extent common QR encoders make intelligent decisions about
this, but it does not seem very hard.
By Lucas Ontivero:
> Here I think it could worth to mention that 58 requires mathematical
operations over big numbers. This is not very fast and most of the
programming languages don't provide support for big numbers OOB.
It's not that hard to emulate the bignum logic in languages that don't
support it. See for example this code in Bitcoin Core:
https://github.com/bitcoin/bitcoin/blob/v0.14.1/src/base58.cpp#L37L53. So I
think it's not necessary to go into all the possible ways Base58 can be
implemented in the document, and the existing language ("Base58 decoding is
complicated and relatively slow.") is sufficient.
> I understand that if a new generic encoding format is introduced that
could lead to some confusions but what if in the future there is a new type
of address that can also be encoded with bech32? Don't we need a address
type anyway?
I believe that it's likely that new types of outputs that may be introduced
in the future will most likely not be a simple constant byte sequence that
can be computed directly from addresses, but need some processing by the
sender. This is the case for example for Reusable/Stealth addresses and
Confidential Transactions addresses. Such outputs, if ever introduced on a
wide scale, should ideally not be representable as existing address types,
as that could not only lead to confusion, but also to lost privacy and
funds.
And, If there ever is a need for introducing a "constant scriptPubKey" type
address again, the encoding proposed in this document can be reused.
Currently, the header value can be at most 17. In the future new proposals
could give a meaning to values 18 through 31.
In general:
In the past weeks people have contributed two new reference implementations
(Haskell and Rust), and a C++ and Go one are underway (see
https://github.com/sipa/bech32).
I'd like to move forward and request a BIP number assignment for this
proposal.
Cheers,
--
Pieter
[-- Attachment #2: Type: text/html, Size: 4784 bytes --]
next prev parent reply other threads:[~2017-05-07 21:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-20 21:35 Pieter Wuille
2017-03-21 16:16 ` Andreas Schildbach
2017-03-21 19:14 ` Peter Todd
2017-03-29 10:07 ` Andreas Schildbach
2017-03-30 4:50 ` Lucas Ontivero
2017-05-07 21:39 ` Pieter Wuille [this message]
2017-05-07 22:34 ` Peter Todd
2017-05-20 20:13 ` Pieter Wuille
2018-07-26 13:43 ` Russell O'Connor
2018-07-26 14:31 ` Russell O'Connor
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='CAPg+sBiPiLHZFoYY=gs6LT+Q2Kb5NmbVU05u7c+0WRPjveBJhQ@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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