BIP 20 Bitcoin URI scheme explained as the closed predecessor to BIP 21, including payment links, amount encoding, compatibility and migration.
This guide explains BIP 20 Bitcoin URI scheme in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
BIP 20 Bitcoin URI scheme: The proposal uses the bitcoin scheme followed by a destination and query parameters. URI parsing rules, percent encoding and parameter separators determine the exact values.
A node operator is checking BIP 20 Bitcoin URI scheme. BIP 20 proposed a bitcoin URI that browsers, QR scanners and desktop applications could hand to a registered wallet.
Copying a Bitcoin address manually is error-prone and carries no standard way to communicate an amount, recipient label or payment note. BIP 20 proposed a bitcoin URI that browsers, QR scanners and desktop applications could hand to a registered wallet. The wallet remained responsible for showing the proposed payment and obtaining user approval before signing or broadcasting.
The proposal uses the bitcoin scheme followed by a destination and query parameters. URI parsing rules, percent encoding and parameter separators determine the exact values. A parser must not treat a string as trustworthy merely because it begins with bitcoin. It should validate the network address, reject malformed encoding and display the decoded destination independently.
Payment amounts are represented as decimal bitcoin values rather than floating-point approximations. Implementations should parse into integer satoshis with strict precision and range checks. Locale-specific commas, exponent notation, negative values and excessive decimal places are unsafe. The wallet should show both the requested amount and the resulting fee before the user confirms.
A label can help the payer recognise the recipient, while a message can describe the purpose of the request. Neither is authenticated by the URI itself. An attacker who substitutes the complete link can substitute these fields too. Wallet interfaces should escape displayed text, constrain lengths and avoid recording sensitive free-form messages in logs or analytics.
BIP 21 refined the URI grammar, parameter handling and compatibility rules and became the deployed reference. The two proposals share the broad payment-link intent but are not interchangeable specifications. New integrations should cite BIP 21 explicitly. Legacy importers can identify BIP 20 assumptions and convert only after presenting the final decoded payment for review.
A QR code is only another carrier for the same untrusted text. Camera software, browser protocol handlers and wallet registration introduce separate substitution risks. The receiving wallet should own final validation and confirmation. A website should not claim payment merely because it generated a code, and a wallet should not broadcast automatically on link activation.
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.
BIP 20 Bitcoin URI scheme: The proposal uses the bitcoin scheme followed by a destination and query parameters.
Copying a Bitcoin address manually is error-prone and carries no standard way to communicate an amount, recipient label or payment note.
The proposal uses the bitcoin scheme followed by a destination and query parameters.
Payment amounts are represented as decimal bitcoin values rather than floating-point approximations.
BIP 20 established the core idea of launchable Bitcoin payment links, but BIP 21 is the deployed standard to implement. Legacy support should be a guarded parsing and migration feature, never a reason to bypass independent address, amount and fee confirmation.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 128 guide to Draft timelock-recovery plan storage, presigned transaction pairs, relative delay, checksums, monitoring, cancellation and reorg safety.
BIP 433 guide to Draft keyless Pay to Anchor outputs, CPFP fee bumping, standardness, ephemeral dust, TRUC anti-pinning and wallet safety.
What is BIP-110? Learn what Bitcoin’s reduced-data soft-fork proposal restricted, why it was controversial and why it later closed.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.