BIP: 21 Title: URI Scheme Author: Nils Schneider <email@example.com> Matt Corallo <firstname.lastname@example.org> Status: Draft Type: Standards Track Created: 29-01-2012
This BIP is a modification of an earlier BIP 0020 by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed.
- 1 Abstract
- 2 Motivation
- 3 Specification
- 4 Rationale
- 5 Forward compatibility
- 6 Appendix
- 7 Reference Implementations
This BIP proposes a URI scheme for making Bitcoin payments.
The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes.
General rules for handling (important!)
Bitcoin clients MUST NOT act on URIs without getting the user's authorization. They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this decision.
Operating system integration
Graphical bitcoin clients SHOULD register themselves as the handler for the "bitcoin:" URI scheme by default, if no other handler is already registered. If there is already a registered handler, they MAY prompt the user to change it once when they first run the client.
(See also a simpler representation of syntax)
bitcoinurn = "bitcoin:" bitcoinaddress [ ";version=" bitcoinversion ] [ "?" bitcoinparams ] bitcoinaddress = base58 *base58 bitcoinversion = "1.0" bitcoinparams = *bitcoinparam bitcoinparam = amountparam | labelparam | messageparam | otherparam amountparam = "amount=" *digit [ "." *digit ] labelparam = "label=" *pchar messageparam = "message=" *pchar otherparam = pchar *pchar "=" *pchar
- label: Label for that address (e.g. name of receiver)
- address: bitcoin address
- message: message that shown to the user after scanning the QR code
- size: amount of base bitcoin units (see below)
- (others): optional, for future extensions
If an amount is provided, it must be specified in decimal BTC. I.e. amount=50.00 is treated as 50 BTC.
Bitcoin clients MAY display the amount in any format that is not intended to deceive the user. They SHOULD choose a format that is foremost least confusing, and only after that most reasonable given the amount requested. For example, so long as the majority of users work in BTC units, values should always be displayed in BTC by default, even if mBTC or TBC would otherwise be a more logical interpretation of the amount.
Payment identifiers, not person identifiers
Current best practices are that a unique address should be used for every transaction. Therefore, a URI scheme should not represent an exchange of personal information, but a one-time payment.
Accessibility (URI scheme name)
Should someone from the outside happen to see such a URI, the URI scheme name already gives a description. A quick search should then do the rest to help them find the resources needed to make their payment. Other proposed names sound much more cryptic; the chance that someone googles that out of curiosity are much slimmer. Also, very likely, what he will find are mostly technical specifications - not the best introduction to bitcoin.
We want URIs generated in 2011 to still work in 2036: think about extensibility. Of course we can make only educated guesses about the future, but don't act as if there is none. This should be the best we can do, but it should not be seen as set in stone. Make it possible for later generations to improve our work, to mend our errors, without breaking the URIs created now.
This section is non-normative and does not cover all possible syntax. Please see the BNF grammar above for the normative syntax.
[foo] means optional, <bar> are placeholders
Just the address:
Address with name:
Request 20.30 BTC to "Luke-Jr":
Request 50 BTC with message:
Characters must be URI encoded properly.
- Bitcoin-Qt supports all valid Bitcoin URIs, with Windows and KDE integration as of commit 70f55355e29c8e45b607e782c5d76609d23cc858.