Published on: 2018-07-26T14:31:30+00:00
In an email exchange, Russell O'Connor suggested adding a note to the BIP (Bitcoin Improvement Proposal) stating that the Human Readable Part (HRP) should be specified in lowercase or at least mentioning that uppercase and lowercase HRPs are considered equivalent and will be converted to lowercase during validation. The HRP is required to contain 1 to 83 US-ASCII characters, with each character having a value in the range of 33-126, and its validity may be further restricted by specific applications. Bech32, which is used for encoding BTC addresses, forbids mixed-case and converts everything to lowercase, so it is advisable to warn against using uppercase in the HRP. This change would not be normative.Pieter Wuille has requested a BIP number assignment for his proposal, which is available on GitHub under the name BIP173. The proposal aims to introduce a commonly recognizable format for BTC addresses that has good properties for all use cases. It emphasizes the importance of addressing all places where humans interact with addresses, including voice transmission and QR codes. However, compactness is not the primary goal of the BIP.The discussion on the Bitcoin-dev mailing list centered around the ability of non-native English speakers to communicate BTC addresses with English speakers. Peter Todd explained that it is not a binary issue as some non-native speakers may know how to pronounce numbers or alphabetical characters but not special characters. Two new reference implementations (Haskell and Rust) have been contributed recently, and C++ and Go implementations are in progress. Peter Todd also shared his experience of implementing Bech32 encoding for a non-BTC use-case and found it straightforward.The writer is considering whether to respond to a mail list or make a comment in a commit file. They discuss the motivation behind this, which is the lack of support for big numbers in most programming languages when performing mathematical operations required by BIP58. The writer also questions the need for a new encoding format and raises concerns about potential confusion. They note that if a new type of address can be encoded with Bech32 in the future, a new address type may be needed regardless. They argue against using non-alphanumeric characters in addresses for certain contexts, such as filenames, and suggest using something like "Base 64url" or ideally Base 94 for shorter QR codes.In a recent discussion on the Bitcoin-dev mailing list, Andreas Schildbach suggested using Base 43 for QR code encoding in Bitcoin Wallet to make addresses shorter. However, Peter Todd responded with concerns about the downsides of using non-alphanumeric characters in addresses, such as making them difficult to use in various contexts and not being familiar to non-English speaking users. He also questioned the need for transmitting addresses via voice communication. Todd further explained that when used for URLs, Base 32 (as well as Base 43) actually makes QR codes bigger due to the characters used for URL parameters. To make them shorter, he suggested using something like "Base 64url" or preferably Base 94 which includes all printable ASCII characters.Andreas Schildbach's suggestion of using Base 43 for QR code encoding in Bitcoin Wallet to shorten addresses may not be efficient due to the downsides associated with non-alphanumeric characters. These characters can complicate usage in different contexts and may not be familiar to non-English-speaking users. The suggestion was made as an alternative to using Base 32, which is seen as less efficient than the QR code alphanumeric mode that accommodates 44 characters. Peter Todd advises reviewing the "Rational" section of the BIP for more details.Pieter Wuille proposed a new BIP for native SegWit addresses to replace BIP 142 on March 20, 2017. These addresses are optional but offer better efficiency, flexibility, and user-friendliness. The format uses a simple checksum algorithm with strong error detection properties and is based on Base 32 encoding. Reference code in several languages, as well as a website demonstrating it, are included. The text of the proposal can be found on GitHub.Pieter's proposal for native SegWit addresses aims to replace the current BIP 142. These addresses, while not required for SegWit, provide improved efficiency, flexibility, and user-friendliness. They utilize a base 32 encoding format with a simple checksum algorithm that ensures strong error detection. The proposal includes reference code in multiple programming languages and a website for demonstration purposes. The full text of the proposal can be accessed on GitHub.
Updated on: 2023-08-01T19:50:37.233258+00:00