* [bitcoin-dev] A BIP proposal for segwit addresses @ 2017-03-20 21:35 Pieter Wuille 2017-03-21 16:16 ` Andreas Schildbach 2017-05-07 21:39 ` Pieter Wuille 0 siblings, 2 replies; 10+ messages in thread From: Pieter Wuille @ 2017-03-20 21:35 UTC (permalink / raw) To: 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. You can find the text here: https://github.com/sipa/bech32/blob/master/bip-witaddr.mediawiki Cheers, -- Pieter ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for segwit addresses 2017-03-20 21:35 [bitcoin-dev] A BIP proposal for segwit addresses Pieter Wuille @ 2017-03-21 16:16 ` Andreas Schildbach 2017-03-21 19:14 ` Peter Todd 2017-05-07 21:39 ` Pieter Wuille 1 sibling, 1 reply; 10+ messages in thread From: Andreas Schildbach @ 2017-03-21 16:16 UTC (permalink / raw) To: bitcoin-dev 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. On 03/20/2017 10:35 PM, Pieter Wuille via bitcoin-dev wrote: > 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, > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for segwit addresses 2017-03-21 16:16 ` Andreas Schildbach @ 2017-03-21 19:14 ` Peter Todd 2017-03-29 10:07 ` Andreas Schildbach 0 siblings, 1 reply; 10+ messages in thread From: Peter Todd @ 2017-03-21 19:14 UTC (permalink / raw) To: Andreas Schildbach, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 946 bytes --] On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via bitcoin-dev wrote: > 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. 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for segwit addresses 2017-03-21 19:14 ` Peter Todd @ 2017-03-29 10:07 ` Andreas Schildbach 2017-03-30 4:50 ` Lucas Ontivero 0 siblings, 1 reply; 10+ messages in thread From: Andreas Schildbach @ 2017-03-29 10:07 UTC (permalink / raw) To: bitcoin-dev On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote: > On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via bitcoin-dev wrote: >> 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. > > 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). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for segwit addresses 2017-03-29 10:07 ` Andreas Schildbach @ 2017-03-30 4:50 ` Lucas Ontivero 0 siblings, 0 replies; 10+ messages in thread From: Lucas Ontivero @ 2017-03-30 4:50 UTC (permalink / raw) To: Andreas Schildbach, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2616 bytes --] 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 < bitcoin-dev@lists•linuxfoundation.org>: > On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote: > > On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via > bitcoin-dev wrote: > >> 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. > > > > 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 > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3644 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for segwit addresses 2017-03-20 21:35 [bitcoin-dev] A BIP proposal for segwit addresses Pieter Wuille 2017-03-21 16:16 ` Andreas Schildbach @ 2017-05-07 21:39 ` Pieter Wuille 2017-05-07 22:34 ` Peter Todd 2017-05-20 20:13 ` Pieter Wuille 1 sibling, 2 replies; 10+ messages in thread From: Pieter Wuille @ 2017-05-07 21:39 UTC (permalink / raw) To: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for segwit addresses 2017-05-07 21:39 ` Pieter Wuille @ 2017-05-07 22:34 ` Peter Todd 2017-05-20 20:13 ` Pieter Wuille 1 sibling, 0 replies; 10+ messages in thread From: Peter Todd @ 2017-05-07 22:34 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1535 bytes --] On Sun, May 07, 2017 at 02:39:14PM -0700, Pieter Wuille via bitcoin-dev wrote: > > 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. Exactly - knowledge of the English language isn't a binary. Equally, I don't remember ever learning names of special characters in French class back in elementary school, but I do recall us drilling the alphabet and especially numbers repeatedly. If I were trying to tell a French speaker a BTC address, I'd probably be able to succesfully do it with bech32, but not with any encoding using special characters. > 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). FWIW, I also did a partial rust implementation of just the Bech32 encoding for a prototype non-BTC use-case. Other than the version number being it's own "chunk" I found it very straight-forward to implement and I think it'll make for a nice replacement for what otherwise would have been hex digests. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for segwit addresses 2017-05-07 21:39 ` Pieter Wuille 2017-05-07 22:34 ` Peter Todd @ 2017-05-20 20:13 ` Pieter Wuille 2018-07-26 13:43 ` Russell O'Connor 1 sibling, 1 reply; 10+ messages in thread From: Pieter Wuille @ 2017-05-20 20:13 UTC (permalink / raw) To: Bitcoin Dev On Sun, May 7, 2017 at 2:39 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote: > I'd like to move forward and request a BIP number assignment for this > proposal. The proposal has been submitted as BIP173: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki Cheers, -- Pieter ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for segwit addresses 2017-05-20 20:13 ` Pieter Wuille @ 2018-07-26 13:43 ` Russell O'Connor 2018-07-26 14:31 ` Russell O'Connor 0 siblings, 1 reply; 10+ messages in thread From: Russell O'Connor @ 2018-07-26 13:43 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 603 bytes --] Hi Pieter, > The *human-readable part*, which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific applications. You should also add to this section that the HRP should be lowercase. Since Bech32 forbids mixed-case and otherwise converts everything to lowercase, it is good to warn upfront against using uppercase in the HRP. I know the BIP is marked as final, but this wouldn't be a normative change. [-- Attachment #2: Type: text/html, Size: 760 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] A BIP proposal for segwit addresses 2018-07-26 13:43 ` Russell O'Connor @ 2018-07-26 14:31 ` Russell O'Connor 0 siblings, 0 replies; 10+ messages in thread From: Russell O'Connor @ 2018-07-26 14:31 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 969 bytes --] I think I phrased this badly. What I mean is that there should be a note that HRP should be specified in lowercase, or at least mention that uppercase and lowercase HRPs are considered equivalent and will be canonicalized to lowercase during validation. On Thu, Jul 26, 2018 at 9:43 AM, Russell O'Connor <roconnor@blockstream•io> wrote: > Hi Pieter, > > > The *human-readable part*, which is intended to convey the type of > data, or anything else that is relevant to the reader. This part MUST > contain 1 to 83 US-ASCII characters, with each character having a value in > the range [33-126]. HRP validity may be further restricted by specific > applications. > > You should also add to this section that the HRP should be lowercase. > > Since Bech32 forbids mixed-case and otherwise converts everything to > lowercase, it is good to warn upfront against using uppercase in the HRP. > > I know the BIP is marked as final, but this wouldn't be a normative change. > [-- Attachment #2: Type: text/html, Size: 1441 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-07-26 14:31 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-20 21:35 [bitcoin-dev] A BIP proposal for segwit addresses 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox