Skip to main content
£0.00 0

Basket

No products in the basket.

ASIC mining knowledge centre

BIP 73 Payment Request URL Negotiation Explained

BIP 73 Payment URL Negotiation made simple. See what the proposal changes, its current status and what it means for Bitcoin users and operators.

BIP 73 Use Accept header for response type negotiation with Payment Request URLs guide cover

BIP 73 Payment URL Negotiation: This guide explains BIP 73 Use "Accept" header for response type negotiation with Payment Request URLs in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

TL;DR

  • What it is: BIP 73 proposed using HTTP Accept headers when a wallet scans a payment-request URL. A server could return a BIP 70 payment request, a bitcoin URI or ordinary HTML according to client capability, allowing a shorter and less dense QR code.
  • Why it matters: BIP 73 reduced QR density through ordinary HTTP negotiation, but it moved trust and availability into a web endpoint. Safe compatibility requires strict media handling, visible fallback and a complete confirmation step after every scanned response.
  • Current position: Its status is Deployed historically, but it inherits BIP 70’s legacy and security constraints and must not turn an arbitrary scanned web URL into automatic payment authority.

BIP 73 Payment URL Negotiation in simple English

BIP 73 Payment URL Negotiation is the Bitcoin proposal covered here. A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.

You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.

Simple example

Think of the transaction as a form passed between several authorised signers. Each person or device checks the same payment details before adding approval. Passing the form around does not make the payment safe unless every signer checks what it contains.

Key terms in plain English

BIP:
Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
Node:
A computer running Bitcoin software that checks data and communicates with other peers.

Why shorter QR codes mattered

Embedding a destination, amount and long payment-request URL inside one bitcoin URI produced dense QR symbols that cameras struggled to scan. BIP 73 let the QR contain only an endpoint. The wallet then requested the representation it understood, trading visual density for an online lookup and its associated availability and substitution risks.

Accept header choices

A client advertised application/bitcoin-paymentrequest for BIP 70 or text/uri-list for a bitcoin URI. If both were offered, the payment request took precedence under the simplified rules. With neither or no Accept header, the server could return HTML useful to a general QR scanner or web browser.

URI-list handling

For text/uri-list, the wallet used only the first returned item and expected it to be a bitcoin URI. It still needed to parse the address, network, amount and parameters safely and require approval. Additional lines were ignored rather than treated as alternative destinations or fallback commands.

BIP 73 Use Accept header for response type negotiation with Payment Request URLs technical diagram
URI-list handling: the fields, validation boundary and operational evidence that implementations need to agree.

HTML fallback

A generic scanner could open the endpoint as a webpage containing a bitcoin link, letting the user continue into an installed wallet. HTML is active untrusted web content, not a payment protocol response. Wallet code should not render it in a privileged signing context or follow scripts and redirects without normal browser safeguards.

Transport and redirect risks

The endpoint controls the response and can observe request metadata. HTTPS authenticates the web endpoint under its certificate but does not independently verify the commercial intent. Redirects can cross origins, and content negotiation can be cached incorrectly unless responses vary by Accept. Clients need tight redirect, MIME and size rules.

Legacy compatibility

Only wallets implementing BIP 73 understood a bare payment endpoint from a QR code. Others required an alternate bitcoin URI or generic scanner flow. Current support for BIP 70 and its media type is limited, so merchants should publish an explicit modern fallback and never assume historical deployed status means broad present-day compatibility.

How specialists test it

Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.

Frequently asked questions

What is BIP 73 Payment Request URL Negotiation?

BIP 73 proposed using HTTP Accept headers when a wallet scans a payment-request URL. A server could return a BIP 70 payment request, a bitcoin URI or ordinary HTML according to client capability, allowing a shorter and less dense QR code.

Is BIP 73 Payment Request URL Negotiation active or supported today?

Its status is Deployed historically, but it inherits BIP 70’s legacy and security constraints and must not turn an arbitrary scanned web URL into automatic payment authority.

Why does BIP 73 Payment Request URL Negotiation matter?

BIP 73 reduced QR density through ordinary HTTP negotiation, but it moved trust and availability into a web endpoint. Safe compatibility requires strict media handling, visible fallback and a complete confirmation step after every scanned response.

Do beginners need to use the technical details?

No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.

Conclusion

BIP 73 reduced QR density through ordinary HTTP negotiation, but it moved trust and availability into a web endpoint. Safe compatibility requires strict media handling, visible fallback and a complete confirmation step after every scanned response.

Primary sources

Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.

On this page

Search More Guides

Continue Reading

Explore more practical guidance on ASIC hardware, profitability, setup, hosting and maintenance.

Need Advice for Your Mining Setup?

Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.
Contact our team
Browse ASIC miners