[bitcoin-dev] BIP for segwit compatibility URIs

[bitcoin-dev] BIP for segwit compatibility URIs

[Srintuar]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1691 bytes --]

Re: [bitcoin-dev] BIP for segwit compatibility URIs

[Clark Moody]

[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4890 bytes --]

Re: [bitcoin-dev] BIP for segwit compatibility URIs

[vv01f]

[-- Attachment #1.1: Type: text/plain, Size: 624 bytes --]

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>]]]


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [bitcoin-dev] BIP for segwit compatibility URIs

[Clark Moody]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2723 bytes --]

Re: [bitcoin-dev] BIP for segwit compatibility URIs

[Srintuar]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 616 bytes --]