📅 Original date posted:2018-10-18
📝 Original message:I have included the comma delimited list in the proposal this time.
It occurs to me that it is simpler to just include the desired destination
script, so I included that as well as an alternative.
Perhaps that should be included as an option in the spec, at the risk of
additional complexity. Alternatively, it could replace the entire
proposal....
---------------------------------------------------
A simple BIP writeup for a backward compatible URI scheme to help with
segwit adoption by online stores and metchants.
====
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 legacy 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.
A comma separated, ordered list of preferred addresses is supplied as
alternatives to the address field from BIP21. The list is ordered from most
preferred to least, with the BIP21 address implicitly last. Senders should
send to the first address which they know how to send to.
==Specification==
=== Query Keys ===
*address: an ordered list bitcoin destination which is preferred over the
"address" of the url, in order from most preferred to less, with the url
address value as least preferred
=== ABNF Grammar ===
bitcoinaddress = base58 / bech32 / <future address format>
bitcoinaddresslist = bitcoinaddress [ "," bitcoinaddresslist ]
== Appendix ==
=== Simpler syntax ===
<nowiki>bitcoin:<address>[?amount=<amount>][?label=<label>][?message=<message>][?address=<bitcoinaddresslist>]</nowiki>
=== Examples ===
Just the address:
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?address=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy
QR size: ~370 bytes
The address and other fields:
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?addr=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy&amount=50&label=Luke-Jr&message=Donation%20for%20project%20xyz
QR size: ~470 bytes
Multiple addresses:
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?address=bc1qq82ajthl5mlm50h6x70esvxs7atp3vfnjwp8z5kjdepsjqqw3zcs9u4nnp,bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy
QR size: ~540 bytes
== Reference Implementations ==
=== Bitcoin clients ===
* none yet
== Alternative Proposal ==
Just include the desired script itself, encoded as hex:
bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?script=0014a70aa2014fbc2151e0a5da78a8dead358d3af384
=== Pros ===
* Infinite forward compatibility with any future script design
* Raw hex encoded scripts are short, and thus would make easy to scan images
* no need for list processing, or multiple alternatives
=== Cons ==
* address encoding features including checksum and network identification
would be absent
* errors in script formation not detectable by the sender; risk of funds
loss if the script is spendable but incorrect
* all error detection depends on the QR code or other transmission medium
* A separate top level uri scheme, such as bitcoinscript:<hex> might be
more appropriate, but would cost backwards compatibility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181018/f660b4d0/attachment.html>;
Srintuar [ARCHIVE] /
npub1jz…nnx6h
2023-06-07 18:15:02
in reply to nevent1q…t93m
Author Public Key
npub1jz6f2rs79h3rsefj90hpj5a3hgeh3ewgpccpzyhwlg5vve2dwnlq6nnx6hPublished at
2023-06-07 18:15:02Event JSON
{
"id": "475336006f542a1ff8060142e05162a682b7e91c3701fe188099f77cb2e89766",
"pubkey": "90b4950e1e2de23865322bee1953b1ba3378e5c80e301112eefa28c6654d74fe",
"created_at": 1686161702,
"kind": 1,
"tags": [
[
"e",
"f2b05ecfa129cf378bf8b3013f671d2da02d4ec0f4eef18868e31c0950a64a13",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2018-10-18\n📝 Original message:I have included the comma delimited list in the proposal this time.\nIt occurs to me that it is simpler to just include the desired destination\nscript, so I included that as well as an alternative.\n\nPerhaps that should be included as an option in the spec, at the risk of\nadditional complexity. Alternatively, it could replace the entire\nproposal....\n\n\n\n\n---------------------------------------------------\n\nA simple BIP writeup for a backward compatible URI scheme to help with\nsegwit adoption by online stores and metchants.\n\n\n====\n\n\nThis BIP is a modification of an earlier [[bip-0021.mediawiki|BIP 0021]] by\nNils Schneider and Matt Corallo\n\n==Abstract==\nThis BIP proposes a URI scheme which allows for backward compatibility with\nnative segwit (bech32) wallets and legacy wallets (base58)\n\n==Motivation==\nThe purpose of this URI scheme is to enable all users to easily make\npayments from any wallet, without allowing backward compatibility to be a\nbarrier to segwit adoption. This BIP allows a merchant to preferentially\nreceive payments to a bech32 address, while gracefully allowing older\nclients to make base58 encoded payments.\n\nA comma separated, ordered list of preferred addresses is supplied as\nalternatives to the address field from BIP21. The list is ordered from most\npreferred to least, with the BIP21 address implicitly last. Senders should\nsend to the first address which they know how to send to.\n\n==Specification==\n\n=== Query Keys ===\n\n*address: an ordered list bitcoin destination which is preferred over the\n\"address\" of the url, in order from most preferred to less, with the url\naddress value as least preferred\n\n=== ABNF Grammar ===\n\n bitcoinaddress = base58 / bech32 / \u003cfuture address format\u003e\n bitcoinaddresslist = bitcoinaddress [ \",\" bitcoinaddresslist ]\n\n== Appendix ==\n\n=== Simpler syntax ===\n\n \u003cnowiki\u003ebitcoin:\u003caddress\u003e[?amount=\u003camount\u003e][?label=\u003clabel\u003e][?message=\u003cmessage\u003e][?address=\u003cbitcoinaddresslist\u003e]\u003c/nowiki\u003e\n\n=== Examples ===\n\nJust the address:\n bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?address=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy\n QR size: ~370 bytes\n\nThe address and other fields:\n bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?addr=bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy\u0026amount=50\u0026label=Luke-Jr\u0026message=Donation%20for%20project%20xyz\n QR size: ~470 bytes\n\n\nMultiple addresses:\n bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?address=bc1qq82ajthl5mlm50h6x70esvxs7atp3vfnjwp8z5kjdepsjqqw3zcs9u4nnp,bc1q5u92yq20hss4rc99mfu23h4dxkxn4uuyqd5dzy\n\n QR size: ~540 bytes\n\n\n== Reference Implementations ==\n\n=== Bitcoin clients ===\n\n* none yet\n\n== Alternative Proposal ==\n\nJust include the desired script itself, encoded as hex:\n\n bitcoin:3BnsWZiTdYVrqiPh2RP3q9Y3ZqvhbCN2it?script=0014a70aa2014fbc2151e0a5da78a8dead358d3af384\n\n=== Pros ===\n\n* Infinite forward compatibility with any future script design\n* Raw hex encoded scripts are short, and thus would make easy to scan images\n* no need for list processing, or multiple alternatives\n\n=== Cons ==\n\n* address encoding features including checksum and network identification\nwould be absent\n* errors in script formation not detectable by the sender; risk of funds\nloss if the script is spendable but incorrect\n* all error detection depends on the QR code or other transmission medium\n* A separate top level uri scheme, such as bitcoinscript:\u003chex\u003e might be\nmore appropriate, but would cost backwards compatibility\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181018/f660b4d0/attachment.html\u003e",
"sig": "46be078bf47b10bc62d26c765f493e925dd1b47b8da050769ac8a8512217a0fdc5132223bf0fc0d41450bd3d1f5a8cb4bf4ccc0a8506cd71f769a587dd16ce78"
}