Published on: 2018-10-18T23:58:54+00:00
The Bitcoin Improvement Proposal (BIP) being discussed involves the use of a concise encoding method, such as a single letter "a", to reduce the size of QR codes. However, there is recognition that using "address" would be more self-explanatory. To determine feasibility, sample QR code sizes for typical use cases will be included. The proposal aims to address the issue of multiple keys with the same name in many wallets by suggesting the use of a delimiter. The author plans to update the BIP proposal and submit it again.In a discussion on the bitcoin-dev mailing list, Clark Moody agrees with spelling out the `address` field. In response to vv01f's suggestion of using the `&` separator and returning either an address or an array of addresses, Clark points out that there is no standard for specifying an array in a URI. He suggests using a delimiter-separated list under one parameter to maintain compatibility. This approach leverages the fact that most languages have library functions for splitting strings on commas. The conversation also touches on future-proofing the syntax by passing a list of addresses to `addr`. The focus of the discussion revolves around finding the best way to structure URIs for Bitcoin transactions.Another discussion regarding the separator for Bitcoin addresses concluded that the & symbol could be used without needing a delimiter. The return value would either be an address or an array of addresses. It was suggested to name the parameter "address" instead of using a shortcut. On October 18, 2018, Clark Moody proposed a syntax that would make the system future-proof by passing a list of addresses to "addr" using the bitcoin:[?addr=[address1,address2]] format.The main objective of this BIP is to enable all users to easily make payments from any wallet while ensuring backward compatibility does not impede segwit adoption. The proposed URI scheme allows for compatibility with both native segwit (bech32) wallets and legacy wallets (base58). Merchants can receive payments to a bech32 address, while older clients can still make base58 encoded payments. To future-proof address changes, a list of addresses can be passed to `addr`. The syntax is bitcoin:[?addr=[address1,address2]]. The addresses in the comma-separated list are ranked in order of preference, with the highest ranked first. A consumer of this URI should attempt to understand each address in the list before falling back to the next one, finally resorting to the base address after `bitcoin:`. An example of this syntax would be bitcoin:3xBase58compatibleAddress?addr=fancyFutureEncoding0x01,bech32address1qx01.This proposal suggests a URI scheme that ensures backward compatibility with both native segwit (bech32) wallets and legacy wallets (base58). It is based on an adaptation of BIP 0021 by Nils Schneider and Matt Corallo. The purpose of this URI scheme is to facilitate easy payments from any wallet without hindering backward compatibility as a barrier to segwit adoption. The specification includes Query Keys such as 'addr', which specifies an alternative bitcoin destination preferred over the "bitcoinaddress" field of the URL. The simpler syntax for this scheme is bitcoin:[?amount=][?label=][?message=][?addr=]. An example provided in the proposal demonstrates how the address can be used along with the preferred bitcoin destination. Currently, there are no reference implementations available for Bitcoin clients.
Updated on: 2023-08-01T23:56:30.566271+00:00