BIP for segwit compatibility URIs

An extremely simple BIP write-up for a backward compatible URI scheme to help with segwit adoption by online stores and merchants.

====

This BIP is a modification of an earlier [[bip-0021.mediawiki|BIP 0021]] by Nils Schneider and Matt Corallo

==Abstract== This BIP proposes a URI scheme which allows for backward compatibility with native segwit (bech32) wallets and legcy wallets (base58)

==Motivation== The purpose of this URI scheme is to enable all users to easily make payments from any wallet, without allowing backward compatibility to be a barrier to segwit adoption. This BIP allows a merchant to preferentially receive payments to a bech32 address, while gracefully allowing older clients to make base58 encoded payments.

==Specification==

=== Query Keys ===

*addr: an alternative bitcoin destination which is preferred over the "bitcoinaddress" field of the url

== Appendix ==

=== Simpler syntax ===

<nowiki>bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>][?addr=<bech32address>]</nowiki>

=== Examples ===

Just the address: bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?addr=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy&amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz

== Reference Implementations == === Bitcoin clients ===

* none yet

Since we don't know what sort of address changes will happen later on, you could make this future-proof by passing a list of addresses to `addr`.

The syntax is

bitcoin:<address>[?addr=<address>[,<address>[,<address>]]]

The addresses passed as a comma-separated list to the `addr` parameter are in descending order of preference, with highest first. A consumer of this URI should attempt to understand each address in the list before falling back to the next address and finally to the base address after `bitcoin:`.

Example:

bitcoin:3xBase58compatibleAddress?addr=fancyFutureEncoding0x01,bech32address1qx01

The spending wallet would attempt to spend to "fancyFutureEncoding0x01" then to "bech32address1qx01" and finally to "3xBase58compatibleAddress".

Thanks,

-Clark

On Sun, Oct 14, 2018 at 3:14 PM Srintuar via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

>
> An extremely simple BIP write-up for a backward compatible URI scheme to
> help with segwit adoption by online stores and merchants.
>
>
>
> ====
>
> This BIP is a modification of an earlier [[bip-0021.mediawiki|BIP 0021]]
> by Nils Schneider and Matt Corallo
>
> ==Abstract==
> This BIP proposes a URI scheme which allows for backward compatibility
> with native segwit (bech32) wallets and legcy wallets (base58)
>
> ==Motivation==
> The purpose of this URI scheme is to enable all users to easily make
> payments from any wallet, without allowing backward compatibility to be a
> barrier to segwit adoption. This BIP allows a merchant to preferentially
> receive payments to a bech32 address, while gracefully allowing older
> clients to make base58 encoded payments.
>
> ==Specification==
>
> === Query Keys ===
>
> *addr: an alternative bitcoin destination which is preferred over the
> "bitcoinaddress" field of the url
>
> == Appendix ==
>
> === Simpler syntax ===
>
>
>  <nowiki>bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>][?addr=<bech32address>]</nowiki>
>
> === Examples ===
>
> Just the address:
>
>  bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?addr=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy&amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz
>
>
> == Reference Implementations ==
> === Bitcoin clients ===
>
> * none yet
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

I already pointed out a while ago that the separator could be the & and the returning value is either an address or an array of addresses. So no comma or other delimiter needed. also I would suggest to call the parameter `address` and not a shortcut for it as we are used to `message` and `amount` spelled out as well.

On 18.10.2018 16:20, Clark Moody via bitcoin-dev wrote:

> Since we don't know what sort of address changes will happen later on, you
> could make this future-proof by passing a list of addresses to `addr`.
>
> The syntax is
>
> bitcoin:<address>[?addr=<address>[,<address>[,<address>]]]

I agree with spelling out the `address` field.

As for "value is either an address or an array of addresses", there is no standard for specifying an array in a URI, and processing different querystring schemes is application-specific. (see https://stackoverflow.com/a/9547490)

Since those app-specific methods don't necessarily preserve order, which is important here, the most compatible fallback is a delimiter-separated list under one parameter. Most languages have library functions for splitting strings on commas.

-Clark

On Thu, Oct 18, 2018 at 5:13 PM vv01f via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> I already pointed out a while ago that the separator could be the & and
> the returning value is either an address or an array of addresses.
> So no comma or other delimiter needed.
> also I would suggest to call the parameter `address` and not a shortcut
> for it as we are used to `message` and `amount` spelled out as well.
>
> On 18.10.2018 16:20, Clark Moody via bitcoin-dev wrote:
> > Since we don't know what sort of address changes will happen later on,
> you
> > could make this future-proof by passing a list of addresses to `addr`.
> >
> > The syntax is
> >
> > bitcoin:<address>[?addr=<address>[,<address>[,<address>]]]
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

I was inclined towards the shortest possible encoding, even just a single letter "a", mainly to reduce the amount of bytes required to form a QR code.That said, "address" is more self-explanatory. Perhaps I will include some sample QR code sizes for typical use cases, and see if it stays reasonable.

As multiple keys of the same name would not be supported easily in many wallets, a delimited is probably preferable.

I will update the BIP proposal and send it again.