* [bitcoin-dev] BIP for segwit compatibility URIs
@ 2018-10-14 19:52 Srintuar
2018-10-18 14:20 ` Clark Moody
0 siblings, 1 reply; 5+ messages in thread
From: Srintuar @ 2018-10-14 19:52 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] BIP for segwit compatibility URIs
2018-10-14 19:52 [bitcoin-dev] BIP for segwit compatibility URIs Srintuar
@ 2018-10-18 14:20 ` Clark Moody
2018-10-18 16:52 ` vv01f
0 siblings, 1 reply; 5+ messages in thread
From: Clark Moody @ 2018-10-18 14:20 UTC (permalink / raw)
To: srintuar, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] BIP for segwit compatibility URIs
2018-10-18 14:20 ` Clark Moody
@ 2018-10-18 16:52 ` vv01f
2018-10-18 22:27 ` Clark Moody
0 siblings, 1 reply; 5+ messages in thread
From: vv01f @ 2018-10-18 16:52 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoin-dev] BIP for segwit compatibility URIs
2018-10-18 16:52 ` vv01f
@ 2018-10-18 22:27 ` Clark Moody
2018-10-18 23:58 ` Srintuar
0 siblings, 1 reply; 5+ messages in thread
From: Clark Moody @ 2018-10-18 22:27 UTC (permalink / raw)
To: vv01f, Bitcoin Protocol Discussion
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-10-18 23:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-14 19:52 [bitcoin-dev] BIP for segwit compatibility URIs Srintuar
2018-10-18 14:20 ` Clark Moody
2018-10-18 16:52 ` vv01f
2018-10-18 22:27 ` Clark Moody
2018-10-18 23:58 ` Srintuar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox