Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use "bitcoin:?req-bip272" instead of the backwards compatible uncertainty #15

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 24 additions & 31 deletions bip-0272.mediawiki
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<pre>
BIP: 272
Title: Simplified Payment Protocol URIs
Author: Wallet Workshop
Author: Wallet Workshop, Aleksandar Dinkov
Created: 2019-02-22
</pre>

Expand All @@ -16,50 +16,43 @@ Allow users to click on a link in a web page or email or scan a QR codes to
initiate the payment protocol, while being backwards-compatible with existing
bitcoin wallets.

The backwards compatibility comes in the sense that existing wallets will recognize that they cannot handle this URI, thanks to the required parameter ("req-bip272").

==Specification==

The bitcoin: URI scheme is extended with an additional, optional
"r" parameter, whose value is a URL from which a PaymentRequest
message should be fetched (characters not allowed within the scope
of a query parameter must be percent-encoded as described in RFC 3986
and bip-0003).
The bitcoin: URI scheme from BIP-21 is extended with additional parameters.

If the "r" parameter is provided and backwards compatibility
is not required, then the bitcoin address portion of the URI may be
omitted (the URI will be of the form: bitcoin:?r=... ).
{|
! Parameter
! Required
! Description
|-
| req-bip272
| Yes
| An empty parameter, signaling wallets that this is a BIP-272 URI. Incompatible wallets will know that they cannot handle it.
|-
| r
| Yes
| a URL from which a BIP-270 PaymentRequest message should be fetched.
|}

When Bitcoin wallet software that supports this BIP receives a
bitcoin: URI with a request parameter, it should ignore the bitcoin
address/amount/label/message in the URI and instead fetch a
PaymentRequest message and then follow the payment protocol, as
described in BIP 70.
When Bitcoin wallet software that supports this BIP receives a bitcoin: URI with a "req-bip272" parameter, it MUST ignore all of the parameters (and path) described in BIP-21 (bitcoin address/amount/label/message) and instead fetch a PaymentRequest message and then follow the payment protocol, as described in BIP 270.

Bitcoin wallets must support fetching PaymentRequests via the
HTTPS protocol; they may support other protocols. Wallets must
include an "Accept" HTTP header in HTTPS requests (as defined
in RFC 2616):
Bitcoin wallets must support fetching PaymentRequests via the HTTPS protocol; they may support other protocols. Wallets must include an "Accept" HTTP header in HTTPS requests (as defined in RFC 2616):

<pre>Accept: application/bitcoinsv-paymentrequest</pre>

If a PaymentRequest cannot be obtained (perhaps the server is
unavailable), then the customer should be informed that the merchant's
payment processing system is unavailable. In the case of an HTTP
request, status codes which are neither success nor error (such as
redirect) should be handled as outlined in RFC 2616.
If a PaymentRequest cannot be obtained (perhaps the server is unavailable), then the customer should be informed that the merchant's payment processing system is unavailable. In the case of an HTTP request, status codes which are neither success nor error (such as redirect) should be handled as outlined in RFC 2616.

==Compatibility==

Wallet software that does not support this BIP will simply ignore the
r parameter and will initiate a payment to bitcoin address.
Wallet software that does not support this BIP will simply see the required parameter "req-bip272" and know that it cannot handle this URI. It will notify the user of the incompatability.

==Examples==
A backwards-compatible request:
<pre>
bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?sv&amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
</pre>
Non-backwards-compatible equivalent:

All BIP-272 URIs will look pretty similar:
<pre>
bitcoin:?sv&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
bitcoin:?req-bip272&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
</pre>

==References==
Expand Down