Bitcoin Wiki - User contributions [en]

BIP 0073

2013-08-29T12:30:38Z

Steve: /* Compatibility */

{{bip}}

<pre>
BIP: 73
Title: Use "Accept" header for response type negotiation with Payment Request URLs
Author: Stephen Pair <stephen@bitpay.com>
Status: Draft
Type: Standards Track
Created: 27-08-2013
</pre>

==Abstract==

This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
that addresses the need for short URLs when scanning from QR codes. It
generalizes the specification for the behavior of a payment request URL in a
way that allows the client and server to negotiate the content of the
response using the HTTP Accept: header field. Specifically, the client
can indicate to the server whether it prefers to receive a bitcoin URI or
a payment request.

Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support.

==Motivation==

The payment protocol augments the bitcoin: uri scheme with an additional
"payment" parameter that specifies a URL where a payment request can be
downloaded. This creates long URIs that, when rendered as a QR code, have
a high information density. Dense QR codes can be difficult to scan resulting
in a more frustrating user experience. The goal is to create a standard that
would allow QR scanning wallets to use less dense QR codes. It also makes
general purpose QR code scanners more usable with bitcoin accepting
websites.

==Specification==

QR scanning wallets will consider a non bitcoin URI scanned from a QR code to
be an end point where either a bitcoin URI or a payment request can be obtained.

A wallet client uses the Accept: HTTP header to specify whether it can accept
a payment request, a URI, or both. A media type of text/uri-list specifies that
the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest
specifies that the client can process a payment request. In the absence of an
Accept: header, the server is expected to respond with text/html suitable for
rendering in a browser. An HTML response will ensure that QR codes scanned
by non Bitcoin wallet QR scanners are useful (they could render an HTML page
with a payment link that when clicked would open a wallet on the device).

It is not required that the client and server support the full semantics of an
HTTP Accept header. If application/bitcoin-paymentrequest is specified in the
header, the server should send a payment request regardless of anything else
specified in the Accept header. If text/uri-list is specified (but not
application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If
neither is specified, the server can return an HTML page. When a uri-list is returned
only the first item in the list is used (and expected to be a bitcoin URI), any additional
URIs should be ignored.

==Compatibility==

Only QR scanning wallets that implement this BIP will be able to process QR
codes containing payment request URLs. There are two possible workarounds for QR
scanning wallets that do not implement this BIP: 1) the server gives the user an
option to change the QR code to a bitcoin: URI or 2) the user scans the code with
a generic QR code scanner.

In the second scenario, if the server responds with a webpage containing a link
to a bitcoin URI, the user can complete the payment by clicking that link provided
the user has a wallet installed on their device and it supports bitcoin URIs. If the
wallet/device does not have support for bitcoin URIs, the user can fall back on
address copy/paste.

This BIP should be fully compatible with BIP 70 assuming it is required that wallets
implementing BIP 70 make use of the Accept: HTTP header when retrieving a
payment request.

==Examples==
The first image below is of a bitcoin URI with an amount and payment request
specified (note, this is a fairly minimal URI as it does not contain a
label and the request URL is of moderate size). The second image is a QR
code with only the payment request url specified.

[[File:BIP_0073a.png]]     [[File:BIP_0073b.png]]
[[Category:BIP]]

BIP 0073

2013-08-29T12:29:02Z

Steve: /* Specification */

{{bip}}

<pre>
BIP: 73
Title: Use "Accept" header for response type negotiation with Payment Request URLs
Author: Stephen Pair <stephen@bitpay.com>
Status: Draft
Type: Standards Track
Created: 27-08-2013
</pre>

==Abstract==

This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
that addresses the need for short URLs when scanning from QR codes. It
generalizes the specification for the behavior of a payment request URL in a
way that allows the client and server to negotiate the content of the
response using the HTTP Accept: header field. Specifically, the client
can indicate to the server whether it prefers to receive a bitcoin URI or
a payment request.

Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support.

==Motivation==

The payment protocol augments the bitcoin: uri scheme with an additional
"payment" parameter that specifies a URL where a payment request can be
downloaded. This creates long URIs that, when rendered as a QR code, have
a high information density. Dense QR codes can be difficult to scan resulting
in a more frustrating user experience. The goal is to create a standard that
would allow QR scanning wallets to use less dense QR codes. It also makes
general purpose QR code scanners more usable with bitcoin accepting
websites.

==Specification==

QR scanning wallets will consider a non bitcoin URI scanned from a QR code to
be an end point where either a bitcoin URI or a payment request can be obtained.

A wallet client uses the Accept: HTTP header to specify whether it can accept
a payment request, a URI, or both. A media type of text/uri-list specifies that
the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest
specifies that the client can process a payment request. In the absence of an
Accept: header, the server is expected to respond with text/html suitable for
rendering in a browser. An HTML response will ensure that QR codes scanned
by non Bitcoin wallet QR scanners are useful (they could render an HTML page
with a payment link that when clicked would open a wallet on the device).

It is not required that the client and server support the full semantics of an
HTTP Accept header. If application/bitcoin-paymentrequest is specified in the
header, the server should send a payment request regardless of anything else
specified in the Accept header. If text/uri-list is specified (but not
application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If
neither is specified, the server can return an HTML page. When a uri-list is returned
only the first item in the list is used (and expected to be a bitcoin URI), any additional
URIs should be ignored.

==Compatibility==

Only QR scanning wallets that implement this BIP will be able to process QR
codes containing payment request URLs. There are two possible workarounds QR
scanning wallets that do not implement this BIP: 1) the server gives the user an
option to change the QR code to a bitcoin: URI or 2) the user scans the code with
a generic QR code scanner.

In the second scenario, if the server responds with a webpage containing a link
to a bitcoin URI, the user can complete the payment by clicking that link provided
the user has a wallet installed on their device and it supports bitcoin URIs. If the
wallet/device does not have support for bitcoin URIs, the user can fall back on
address copy/paste.

This BIP should be fully compatible with BIP 70 assuming it is required that wallets
implementing BIP 70 make use of the Accept: HTTP header when retrieving a
payment request.

==Examples==
The first image below is of a bitcoin URI with an amount and payment request
specified (note, this is a fairly minimal URI as it does not contain a
label and the request URL is of moderate size). The second image is a QR
code with only the payment request url specified.

[[File:BIP_0073a.png]]     [[File:BIP_0073b.png]]
[[Category:BIP]]

BIP 0073

2013-08-28T13:20:08Z

Steve: /* Compatibility */

{{bip}}

<pre>
BIP: 73
Title: Use "Accept" header for response type negotiation with Payment Request URLs
Author: Stephen Pair <stephen@bitpay.com>
Status: Draft
Type: Standards Track
Created: 27-08-2013
</pre>

==Abstract==

This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
that addresses the need for short URLs when scanning from QR codes. It
generalizes the specification for the behavior of a payment request URL in a
way that allows the client and server to negotiate the content of the
response using the HTTP Accept: header field. Specifically, the client
can indicate to the server whether it prefers to receive a bitcoin URI or
a payment request.

Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support.

==Motivation==

The payment protocol augments the bitcoin: uri scheme with an additional
"payment" parameter that specifies a URL where a payment request can be
downloaded. This creates long URIs that, when rendered as a QR code, have
a high information density. Dense QR codes can be difficult to scan resulting
in a more frustrating user experience. The goal is to create a standard that
would allow QR scanning wallets to use less dense QR codes. It also makes
general purpose QR code scanners more usable with bitcoin accepting
websites.

==Specification==

QR scanning wallets will consider a non bitcoin URI scanned from a QR code to
be an end point where either a bitcoin URI or a payment request can be obtained.

A wallet client uses the Accept: HTTP header to specify whether it can accept
a payment request, a URI, or both. A media type of text/uri-list specifies that
the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest
specifies that the client can process a payment request. In the absence of an
Accept: header, the server is expect to respond with text/html suitable for
rendering in a browser. An HTML response will ensure that QR codes scanned
by non Bitcoin wallet QR scanners are useful (they could render an HTML page
with a payment link that when clicked would open a wallet on the device).

It is not required that the client and server support the full semantics of an
HTTP Accept header. If application/bitcoin-paymentrequest is specified in the
header, the server should send a payment request regardless of anything else
specified in the Accept header. If text/uri-list is specified (but not
application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If
neither is specified, the server can return an HTML page. When a uri-list is returned
only the first item in the list is used (and expected to be a bitcoin URI), any additional
URIs should be ignored.

==Compatibility==

Only QR scanning wallets that implement this BIP will be able to process QR
codes containing payment request URLs. There are two possible workarounds QR
scanning wallets that do not implement this BIP: 1) the server gives the user an
option to change the QR code to a bitcoin: URI or 2) the user scans the code with
a generic QR code scanner.

In the second scenario, if the server responds with a webpage containing a link
to a bitcoin URI, the user can complete the payment by clicking that link provided
the user has a wallet installed on their device and it supports bitcoin URIs. If the
wallet/device does not have support for bitcoin URIs, the user can fall back on
address copy/paste.

This BIP should be fully compatible with BIP 70 assuming it is required that wallets
implementing BIP 70 make use of the Accept: HTTP header when retrieving a
payment request.

==Examples==
The first image below is of a bitcoin URI with an amount and payment request
specified (note, this is a fairly minimal URI as it does not contain a
label and the request URL is of moderate size). The second image is a QR
code with only the payment request url specified.

[[File:BIP_0073a.png]]     [[File:BIP_0073b.png]]
[[Category:BIP]]

BIP 0073

2013-08-28T13:14:05Z

Steve: /* Specification */

{{bip}}

<pre>
BIP: 73
Title: Use "Accept" header for response type negotiation with Payment Request URLs
Author: Stephen Pair <stephen@bitpay.com>
Status: Draft
Type: Standards Track
Created: 27-08-2013
</pre>

==Abstract==

This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
that addresses the need for short URLs when scanning from QR codes. It
generalizes the specification for the behavior of a payment request URL in a
way that allows the client and server to negotiate the content of the
response using the HTTP Accept: header field. Specifically, the client
can indicate to the server whether it prefers to receive a bitcoin URI or
a payment request.

Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support.

==Motivation==

The payment protocol augments the bitcoin: uri scheme with an additional
"payment" parameter that specifies a URL where a payment request can be
downloaded. This creates long URIs that, when rendered as a QR code, have
a high information density. Dense QR codes can be difficult to scan resulting
in a more frustrating user experience. The goal is to create a standard that
would allow QR scanning wallets to use less dense QR codes. It also makes
general purpose QR code scanners more usable with bitcoin accepting
websites.

==Specification==

QR scanning wallets will consider a non bitcoin URI scanned from a QR code to
be an end point where either a bitcoin URI or a payment request can be obtained.

A wallet client uses the Accept: HTTP header to specify whether it can accept
a payment request, a URI, or both. A media type of text/uri-list specifies that
the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest
specifies that the client can process a payment request. In the absence of an
Accept: header, the server is expect to respond with text/html suitable for
rendering in a browser. An HTML response will ensure that QR codes scanned
by non Bitcoin wallet QR scanners are useful (they could render an HTML page
with a payment link that when clicked would open a wallet on the device).

It is not required that the client and server support the full semantics of an
HTTP Accept header. If application/bitcoin-paymentrequest is specified in the
header, the server should send a payment request regardless of anything else
specified in the Accept header. If text/uri-list is specified (but not
application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If
neither is specified, the server can return an HTML page. When a uri-list is returned
only the first item in the list is used (and expected to be a bitcoin URI), any additional
URIs should be ignored.

==Compatibility==

QR scanning wallets that do not support this BIP will not be able to process QR
codes containing non bitcoin URIs. There are two possible workarounds: 1) the
server gives the user an option to change the QR code to a bitcoin: URI or 2) the
user scans the code with a generic QR code scanner.

This BIP should be fully compatible with BIP 70 assuming it is required that wallets
implementing BIP 70 make use of the Accept: HTTP header when retrieving a
payment request.

==Examples==
The first image below is of a bitcoin URI with an amount and payment request
specified (note, this is a fairly minimal URI as it does not contain a
label and the request URL is of moderate size). The second image is a QR
code with only the payment request url specified.

[[File:BIP_0073a.png]]     [[File:BIP_0073b.png]]
[[Category:BIP]]

BIP 0073

2013-08-28T13:13:51Z

Steve: /* Specification */

{{bip}}

<pre>
BIP: 73
Title: Use "Accept" header for response type negotiation with Payment Request URLs
Author: Stephen Pair <stephen@bitpay.com>
Status: Draft
Type: Standards Track
Created: 27-08-2013
</pre>

==Abstract==

This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
that addresses the need for short URLs when scanning from QR codes. It
generalizes the specification for the behavior of a payment request URL in a
way that allows the client and server to negotiate the content of the
response using the HTTP Accept: header field. Specifically, the client
can indicate to the server whether it prefers to receive a bitcoin URI or
a payment request.

Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support.

==Motivation==

The payment protocol augments the bitcoin: uri scheme with an additional
"payment" parameter that specifies a URL where a payment request can be
downloaded. This creates long URIs that, when rendered as a QR code, have
a high information density. Dense QR codes can be difficult to scan resulting
in a more frustrating user experience. The goal is to create a standard that
would allow QR scanning wallets to use less dense QR codes. It also makes
general purpose QR code scanners more usable with bitcoin accepting
websites.

==Specification==

QR scanning wallets will consider a non bitcoin URI scanned from a QR code to
be an end point where either a bitcoin URI or a payment request can be obtained.

A wallet client uses the Accept: HTTP header to specify whether it can accept
a payment request, a URI, or both. A media type of text/uri-list specifies that
the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest
specifies that the client can process a payment request. In the absence of an
Accept: header, the server is expect to respond with text/html suitable for
rendering in a browser. An HTML response will ensure that QR codes scanned
by non Bitcoin wallet QR scanners are useful (they could render an HTML page
with a payment link that when clicked would open a wallet on the device).

It is not request that the client and server support the full semantics of an
HTTP Accept header. If application/bitcoin-paymentrequest is specified in the
header, the server should send a payment request regardless of anything else
specified in the Accept header. If text/uri-list is specified (but not
application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned. If
neither is specified, the server can return an HTML page. When a uri-list is returned
only the first item in the list is used (and expected to be a bitcoin URI), any additional
URIs should be ignored.

==Compatibility==

QR scanning wallets that do not support this BIP will not be able to process QR
codes containing non bitcoin URIs. There are two possible workarounds: 1) the
server gives the user an option to change the QR code to a bitcoin: URI or 2) the
user scans the code with a generic QR code scanner.

This BIP should be fully compatible with BIP 70 assuming it is required that wallets
implementing BIP 70 make use of the Accept: HTTP header when retrieving a
payment request.

==Examples==
The first image below is of a bitcoin URI with an amount and payment request
specified (note, this is a fairly minimal URI as it does not contain a
label and the request URL is of moderate size). The second image is a QR
code with only the payment request url specified.

[[File:BIP_0073a.png]]     [[File:BIP_0073b.png]]
[[Category:BIP]]

BIP 0073

2013-08-28T13:10:13Z

Steve: /* Abstract */

{{bip}}

<pre>
BIP: 73
Title: Use "Accept" header for response type negotiation with Payment Request URLs
Author: Stephen Pair <stephen@bitpay.com>
Status: Draft
Type: Standards Track
Created: 27-08-2013
</pre>

==Abstract==

This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
that addresses the need for short URLs when scanning from QR codes. It
generalizes the specification for the behavior of a payment request URL in a
way that allows the client and server to negotiate the content of the
response using the HTTP Accept: header field. Specifically, the client
can indicate to the server whether it prefers to receive a bitcoin URI or
a payment request.

Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support.

==Motivation==

The payment protocol augments the bitcoin: uri scheme with an additional
"payment" parameter that specifies a URL where a payment request can be
downloaded. This creates long URIs that, when rendered as a QR code, have
a high information density. Dense QR codes can be difficult to scan resulting
in a more frustrating user experience. The goal is to create a standard that
would allow QR scanning wallets to use less dense QR codes. It also makes
general purpose QR code scanners more usable with bitcoin accepting
websites.

==Specification==

QR scanning wallets will consider a non bitcoin URI scanned from a QR code to
be an end point where either a bitcoin URI or a payment request can be obtained.

A wallet client uses the Accept: HTTP header to specify whether it can accept
a payment request, a URI, or both. A media type of text/uri-list specifies that
the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest
specifies that the client can process a payment request. In the absence of an
Accept: header, the server is expect to respond with text/html suitable for
rendering in a browser. An HTML response will ensure that QR codes scanned
by non Bitcoin wallet QR scanners are useful (they could render an HTML page
with a payment link that when clicked would open a wallet on the device).

==Compatibility==

QR scanning wallets that do not support this BIP will not be able to process QR
codes containing non bitcoin URIs. There are two possible workarounds: 1) the
server gives the user an option to change the QR code to a bitcoin: URI or 2) the
user scans the code with a generic QR code scanner.

This BIP should be fully compatible with BIP 70 assuming it is required that wallets
implementing BIP 70 make use of the Accept: HTTP header when retrieving a
payment request.

==Examples==
The first image below is of a bitcoin URI with an amount and payment request
specified (note, this is a fairly minimal URI as it does not contain a
label and the request URL is of moderate size). The second image is a QR
code with only the payment request url specified.

[[File:BIP_0073a.png]]     [[File:BIP_0073b.png]]
[[Category:BIP]]

BIP 0073

2013-08-28T13:09:52Z

Steve: /* Abstract */

{{bip}}

<pre>
BIP: 73
Title: Use "Accept" header for response type negotiation with Payment Request URLs
Author: Stephen Pair <stephen@bitpay.com>
Status: Draft
Type: Standards Track
Created: 27-08-2013
</pre>

==Abstract==

This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
that addresses the need for short URLs when scanning from QR codes. It
generalizes the specification for the behavior of a payment request URL in a
way that allows the client and server to negotiate the content of the
response using the HTTP Accept: header field. Specifically, the client
can indicate to the server whether it prefers to receive a bitcoin URI or
a payment request.

Implementation of this BIP does not require full payment request [[BIP 0070|BIP 70]] support.

==Motivation==

The payment protocol augments the bitcoin: uri scheme with an additional
"payment" parameter that specifies a URL where a payment request can be
downloaded. This creates long URIs that, when rendered as a QR code, have
a high information density. Dense QR codes can be difficult to scan resulting
in a more frustrating user experience. The goal is to create a standard that
would allow QR scanning wallets to use less dense QR codes. It also makes
general purpose QR code scanners more usable with bitcoin accepting
websites.

==Specification==

QR scanning wallets will consider a non bitcoin URI scanned from a QR code to
be an end point where either a bitcoin URI or a payment request can be obtained.

A wallet client uses the Accept: HTTP header to specify whether it can accept
a payment request, a URI, or both. A media type of text/uri-list specifies that
the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest
specifies that the client can process a payment request. In the absence of an
Accept: header, the server is expect to respond with text/html suitable for
rendering in a browser. An HTML response will ensure that QR codes scanned
by non Bitcoin wallet QR scanners are useful (they could render an HTML page
with a payment link that when clicked would open a wallet on the device).

==Compatibility==

QR scanning wallets that do not support this BIP will not be able to process QR
codes containing non bitcoin URIs. There are two possible workarounds: 1) the
server gives the user an option to change the QR code to a bitcoin: URI or 2) the
user scans the code with a generic QR code scanner.

This BIP should be fully compatible with BIP 70 assuming it is required that wallets
implementing BIP 70 make use of the Accept: HTTP header when retrieving a
payment request.

==Examples==
The first image below is of a bitcoin URI with an amount and payment request
specified (note, this is a fairly minimal URI as it does not contain a
label and the request URL is of moderate size). The second image is a QR
code with only the payment request url specified.

[[File:BIP_0073a.png]]     [[File:BIP_0073b.png]]
[[Category:BIP]]

Bitcoin Improvement Proposals

2013-08-28T04:37:42Z

Steve:

People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.

We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.

Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.

Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [[economic majority]]).

{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
!Number
!Title
!Owner
!Status
|- style="background-color: #cfffcf"
| [[BIP 0001|1]]
| BIP Purpose and Guidelines
| Amir Taaki
| Active
|-
| [[BIP 0010|10]]
| Multi-Sig Transaction Distribution
| Alan Reiner
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0011|11]]
| M-of-N Standard Transactions
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0012|12]]
| OP_EVAL
| Gavin Andresen
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0013|13]]
| Address Format for pay-to-script-hash
| Gavin Andresen
| Final
|- style="background-color: #cfffcf"
| [[BIP 0014|14]]
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0015|15]]
| Aliases
| Amir Taaki
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0016|16]]
| Pay To Script Hash
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0017|17]]
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
| Withdrawn
|-
| [[BIP 0018|18]]
| hashScriptCheck
| Luke Dashjr
| Draft
|-
| [[BIP 0019|19]]
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
| Draft
|- style="background-color: #ffcfcf"
| [[BIP 0020|20]]
| URI Scheme
| Luke Dashjr
| Replaced
|- style="background-color: #cfffcf"
| [[BIP 0021|21]]
| URI Scheme
| Nils Schneider, Matt Corallo
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0022|22]]
| getblocktemplate - Fundamentals
| Luke Dashjr
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0023|23]]
| getblocktemplate - Pooled Mining
| Luke Dashjr
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0030|30]]
| Duplicate transactions
| Pieter Wuille
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0031|31]]
| Pong message
| Mike Hearn
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0032|32]]
| Hierarchical Deterministic Wallets
| Pieter Wuille
| Accepted
|-
| [[BIP 0033|33]]
| Stratized Nodes
| Amir Taaki
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0034|34]]
| Block v2, Height in coinbase
| Gavin Andresen
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0035|35]]
| mempool message
| Jeff Garzik
| Accepted
|-
| [[BIP 0036|36]]
| Custom Services
| Stefan Thomas
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0037|37]]
| Bloom filtering
| Mike Hearn and Matt Corallo
| Accepted
|-
| [[BIP 0039|39]]
| Deterministic key mnemonics
| Slush
| BIP number allocated
|-
| [[BIP 0040|40]]
| Stratum wire protocol
| Slush
| BIP number allocated
|-
| [[BIP 0041|41]]
| Stratum mining protocol
| Slush
| BIP number allocated

|-
| [[BIP 0050|50]]
| March 2013 Chain Fork Post-Mortem
| Gavin Andresen
| Draft

|-
| [[BIP 0060|60]]
| Fixed Length "version" Message (Relay-Transactions Field)
| Amir Taaki
| Draft
|-
| [[BIP 0070|70]]
| Payment protocol
| Gavin Andresen
| Draft
|-
| [[BIP 0071|71]]
| Payment protocol MIME types
| Gavin Andresen
| Draft
|-
| [[BIP 0072|72]]
| Payment protocol URIs
| Gavin Andresen
| Draft
|-
| [[BIP 0073|73]]
| Use "Accept" header with Payment Request URLs
| Stephen Pair
| Draft
|}

[[Hardfork Wishlist]]

[[Category:BIP|Z]]

[[es:Propuestas de mejora de Bitcoin]]

BIP 0073

2013-08-28T04:34:25Z

Steve: Created page with "{{bip}} <pre> BIP: 73 Title: Use "Accept" header for response type negotiation with Payment Request URLs Author: Stephen Pair <stephen@bitpay.com> Status: Draft Ty..."

{{bip}}

<pre>
BIP: 73
Title: Use "Accept" header for response type negotiation with Payment Request URLs
Author: Stephen Pair <stephen@bitpay.com>
Status: Draft
Type: Standards Track
Created: 27-08-2013
</pre>

==Abstract==

This BIP describes an enhancement to the payment protocol (BIP 70)
that addresses the need for short URLs when scanning from QR codes. It
generalizes the specification for the behavior of a payment request URL in a
way that allows the client and server to negotiate the content of the
response using the HTTP Accept: header field. Specifically, the client
can indicate to the server whether it prefers to receive a bitcoin URI or
a payment request.

==Motivation==

The payment protocol augments the bitcoin: uri scheme with an additional
"payment" parameter that specifies a URL where a payment request can be
downloaded. This creates long URIs that, when rendered as a QR code, have
a high information density. Dense QR codes can be difficult to scan resulting
in a more frustrating user experience. The goal is to create a standard that
would allow QR scanning wallets to use less dense QR codes. It also makes
general purpose QR code scanners more usable with bitcoin accepting
websites.

==Specification==

QR scanning wallets will consider a non bitcoin URI scanned from a QR code to
be an end point where either a bitcoin URI or a payment request can be obtained.

A wallet client uses the Accept: HTTP header to specify whether it can accept
a payment request, a URI, or both. A media type of text/uri-list specifies that
the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest
specifies that the client can process a payment request. In the absence of an
Accept: header, the server is expect to respond with text/html suitable for
rendering in a browser. An HTML response will ensure that QR codes scanned
by non Bitcoin wallet QR scanners are useful (they could render an HTML page
with a payment link that when clicked would open a wallet on the device).

==Compatibility==

QR scanning wallets that do not support this BIP will not be able to process QR
codes containing non bitcoin URIs. There are two possible workarounds: 1) the
server gives the user an option to change the QR code to a bitcoin: URI or 2) the
user scans the code with a generic QR code scanner.

This BIP should be fully compatible with BIP 70 assuming it is required that wallets
implementing BIP 70 make use of the Accept: HTTP header when retrieving a
payment request.

==Examples==
The first image below is of a bitcoin URI with an amount and payment request
specified (note, this is a fairly minimal URI as it does not contain a
label and the request URL is of moderate size). The second image is a QR
code with only the payment request url specified.

[[File:BIP_0073a.png]]     [[File:BIP_0073b.png]]
[[Category:BIP]]

File:BIP 0073b.png

2013-08-28T04:18:13Z

Steve:

File:BIP 0073a.png

2013-08-28T04:17:19Z

Steve: