Discussion:
A BIP proposal for segwit addresses
(too old to reply)
Pieter Wuille via bitcoin-dev
2017-03-20 21:35:08 UTC
Permalink
Raw Message
Hello everyone,

I'd like to propose a new BIP for native segwit addresses to replace
BIP 142. These addresses are not required for segwit, but are more
efficient, flexible, and nicer to use.

The format is base 32 and uses a simple checksum algorithm with strong
error detection properties. Reference code in several languages as
well as a website demonstrating it are included.

You can find the text here:
https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki

Cheers,
--
Pieter
Andreas Schildbach via bitcoin-dev
2017-03-21 16:16:30 UTC
Permalink
Raw Message
Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
In Bitcoin Wallet, I use Base 43 (alphabet:
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
code encoding. I only leave out the space character because it gets
replaced by "+" in URLs.
Post by Pieter Wuille via bitcoin-dev
Hello everyone,
I'd like to propose a new BIP for native segwit addresses to replace
BIP 142. These addresses are not required for segwit, but are more
efficient, flexible, and nicer to use.
The format is base 32 and uses a simple checksum algorithm with strong
error detection properties. Reference code in several languages as
well as a website demonstrating it are included.
https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki
Cheers,
Peter Todd via bitcoin-dev
2017-03-21 19:14:54 UTC
Permalink
Raw Message
Post by Andreas Schildbach via bitcoin-dev
Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
code encoding. I only leave out the space character because it gets
replaced by "+" in URLs.
Doing that only makes addresses a few % shorter, at the cost of significant
downsides. For example, not everyone knows what those additional characters
are called, particularly for non-English-speaking users. Non-alphanumeric
characters also complicate using the addresses in a variety of contexts ('/'
in particularly isn't valid in filenames).

I'd suggest you review the "Rational" section of the BIP for more details:

https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki#rationale
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Andreas Schildbach via bitcoin-dev
2017-03-29 10:07:40 UTC
Permalink
Raw Message
Post by Peter Todd via bitcoin-dev
Post by Andreas Schildbach via bitcoin-dev
Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
code encoding. I only leave out the space character because it gets
replaced by "+" in URLs.
Doing that only makes addresses a few % shorter, at the cost of significant
downsides. For example, not everyone knows what those additional characters
are called, particularly for non-English-speaking users. Non-alphanumeric
characters also complicate using the addresses in a variety of contexts ('/'
in particularly isn't valid in filenames).
I'm not convinced that transmitting addresses via voice should be a
usecase to target at. 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.

Addresses in QR codes, addresses in URLs and addresses in NFC NDEF
messages are the three most used forms.

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. To make them shorter, we'd
need to use something like "Base 64url" (or ideally Base 94 -- all
printable ASCII characters).
Lucas Ontivero via bitcoin-dev
2017-03-30 04:50:54 UTC
Permalink
Raw Message
I don't know if i should response to this mail list or make a comment in
commit file (
https://github.com/sipa/bech32/commit/52b5a0fa6d3174c4150393fb7d6b58d34b4f5e0b#diff-d23a42e5c904045098e8f8b1189f481e
)

* Motivation:

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.

* Why not make an address format that is generic for all scriptPubKeys?:

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?

thx


2017-03-29 7:07 GMT-03:00 Andreas Schildbach via bitcoin-dev <
Post by Peter Todd via bitcoin-dev
On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via
Post by Andreas Schildbach via bitcoin-dev
Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
code encoding. I only leave out the space character because it gets
replaced by "+" in URLs.
Doing that only makes addresses a few % shorter, at the cost of
significant
downsides. For example, not everyone knows what those additional
characters
are called, particularly for non-English-speaking users. Non-alphanumeric
characters also complicate using the addresses in a variety of contexts
('/'
in particularly isn't valid in filenames).
I'm not convinced that transmitting addresses via voice should be a
usecase to target at. 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.
Addresses in QR codes, addresses in URLs and addresses in NFC NDEF
messages are the three most used forms.
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. To make them shorter, we'd
need to use something like "Base 64url" (or ideally Base 94 -- all
printable ASCII characters).
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...