What cryptocurrency URIs exist, which are actually being used, and what is proposed for the future? URIs such as bitcoin: are being used in QR codes and NFC tags to enable simpler payments between users, and particularly at retail locations. If bitcoin and other cryptocurrencies want widespread acceptance, then they need to be usable for payments in as many places as possible. Imagine it’s 1958 and you’re using the first credit card called the BankAmericard (later renamed Visa) and you go into a store that’s never heard of a credit card. That’s basically where cryptocurrencies are today.
Let’s start from the beginning. What’s a URI? URI stands for Uniform Resource Identifier, and don’t confuse it with URL (a Uniform Resource Locator, or more colloquially, an Internet address). A URL is a URI, but a URI is not a URL. Internet addresses are formatted as a URI scheme generally with the http: or https: prefix (although ftp, sftp, gopher, mailto, news, telnet and others are also URL prefixes) which identify it as a URL, and dictate that what follows is the Internet address that can be parsed. Other URI schemes that are not URLs include tel: (for making telephone calls), fax (for sending faxes – although this is considered historical), and most relevant for this discussion, bitcoin: (for requesting a payment using Bitcoin). Bitcoin’s URI, unlike the others above, is provisional. More on that below.
URI schemes (identified by the text before the colon) are generally registered by the International Assigned Numbers Authority (IANA), the same organization that manages the DNS root and IP addresses. Registered URIs can be permanent (such as https:), historical (such as fax: and videotex:), or as most of them are listed, provisional (like bitcoin:). Provisional URIs are proposed and accepted on a first-come first-serve basis, and have no official reviewed and accepted RFC. That means they’re reserved, but not fully official.
In addition to these official and semi-official URI schemes, there are an endless number of application-specific URIs. Some of these URIs are also listed as provisional URIs on the IANA list, but probably shouldn’t be since they are only accepted by a single application. These include skype:, spotify:, and lastfm:, which are on the IANA list, and many other non-registered ones that trigger all kinds of apps, particularly on mobile devices, but not exclusively.
Due to security issues that come from the unregulated nature of these types of links, Apple and Google have tried to move away from using these on their platforms (Apple more than Google), preferring their own solutions – iOS Universal Links and Android App Links. These provide a link that can both deep link into an app, and also open a web page if the app isn’t available. More importantly, these solutions are linked to a web site, which insures that the app supporting the links is connected to the site it claims to be. This is useful for security, insures no one is spoofing the correct app, removes the need for lots of URIs for different apps (they simply use https: links), but of course require a central server to manage things, and requires a much more complex system in place to handle those links.
When a protocol needs to work with multiple apps, URIs are still needed, so let’s take a look at what URIs exist in the cryptocurrency world.
The following table is an attempt to organize efforts to introduce cryptocurrency URIs, or at least cryptocurrency-inclusive URIs:
Cryptocurrency URI Proposals and Standards
The table is in rough chronological order. The efforts started with Bitcoin in a discussion which Satoshi Nakamoto took part in during 2010. The first proposal BIP-20 was introduced in 2011, and replaced following year by BIP-21, which is what is currently used in most cases where you would see a Bitcoin QR Code or NFC tag. This introduced the first cryptocurrency URI scheme, bitcoin:.
The following year, 2013, BIP-70 introduced the more sophisticated Payment Protocol, which allowed a merchant to direct a customer to a payment file on their web site, instead of listing all the information in the URI itself, as well as other improvements that help mitigate man-in-the-middle attacks. BIP-70 was complemented by several other improvements, outlined in BIP-71, BIP-72, BIP-73, and BIP-75 (BIP-74 was rejected). BIP-72 in particular added a variable r= to support BIP-70 that directs the wallet to the payment request on a web site. A proposal about a year after BIP-72 from Andy Schroder, which he called TBIP-75, adds an additional variable h= which is intended to include a hash of the payment request to insure that the payment request on the web site is the same one the seller was intending to show (and not something redirected in a man-in-the-middle attack). This doesn’t seem to have been added to an official BIP, but some wallets appear to use this to add security.
Unfortunately, while over a dozen Bitcoin wallets currently support BIP-70, the Bitcoin Core development team recently depreciated BIP-70 support in their wallet, with an eye towards eliminating support completely in the next version. This may have to do with the fact that BIP-70 traded security for privacy, exposing the IP address of the wallet during the payment process. There may be other reasons the Bitcoin Core developers did this, but other people can speculate. While the removal of BIP-70 support from Bitcoin Core doesn’t mean other wallets cannot continue to use it, the depreciation of BIP-70 by the core wallet team sends a signal that can effect its continued adoption and support of BIP-70.
In 2016, less than a year after Ethereum itself launched, the first proposal for a URI was introduced, ERP-67. This was subsequently updated by EIP-681 and EIP-831. These proposals use the URI scheme ethereum:.
Around the same time, Internet standards bodies started to implement their own payment protocols, usually including cryptocurrency support in some (incomplete) fashion. This includes the 2016 introduction of the W3C Payment Request API and the 2017 introduction of the IETF payto: URI scheme.
2017 saw the split between Bitcoin and Bitcoin Cash, and the need to introduce a new URI to handle the new cryptocurrency. This was discussed in 2017, and initially bitcoincash: was used with BIP-21 as the guide. Later, BUIP-86 was formally introduced, whereupon it was approved with the second version of the bitcoincash: URI scheme. This URI scheme is the only other cryptocurrency URI scheme listed on the IANI list.
Also in 2017 developers of the Lightning Network for Bitcoin added their own URI scheme, lightning:, in BOLT-11 to facilitate payments over the Lightning Network, particularly using QR Codes. A suggested addition to BOLT-11 in the Lightning-Dev mailing list suggests support for NFC payments as well.
Lastly, the introduction of EIP-1328 describes connecting wallets to Dapps, adding to the existing EIP-831-defined ethereum: URI, although its not clear this was adopted. It does bring up the issue of integrating more sophisticated blockchain-based apps into the URI, however.
Something else worth noticing is the interest in using IBAN as a way to connect to the fiat financial system. IBAN (International Bank Account Number) is a code currently used by 69 countries that includes the routing information to connect to a specific bank account (including country, bank, branch, and account number). Ethereum’s ICAP proposal is a way to add Ethereum to the IBAN system by adding XE as a country code in the IBAN system, and then using an Ethereum address as the account number. The IETF payto: URI scheme includes IBAN as a payment option, in addition to Bitcoin and Interledger. IBAN is a great system, but it’s not used everywhere, including in the US, where transfers are done in combination of an account number, and domestically ABA Routing numbers and internationally SWIFT/BIC numbers. Add to those whatever the other 100+ countries are using and you get a very complicated system to represent in a URI.
Bitcoin:
Let’s take a look at the first cryptocurrency URI, bitcoin:. A simple payment request from one user to another would look something like this (using a testnet address):
bitcoin:n4ijQMT8NtB58dZrgodiMMmjFZh4KyKEG3In the above example, you start with the bitcoin: scheme name, followed by a bitcoin address. If you were to click on this link, or scan a QR Code encoded with this URI, you would simply be asked to enter a number of BTC to send to the address given.
It’s easier to think of this in terms of a seller and a buyer. A seller requests payment from the buyer (let’s say for a cup of coffee), the seller generates a public address, encodes it in a payment request, and presents it to the buyer. If they are requesting a specific amount, for the cup of coffee, they can add that to the request:
bitcoin:n4ijQMT8NtB58dZrgodiMMmjFZh4KyKEG3?amount=0.00062In this case the seller is asking for 0.00062 BTC, which as of this writing is about five dollars. Note that the unit is decimal Bitcoin, the only unit that is accepted. The store might use a different unit to define what they’re requesting – such as 62,000 Satoshis or 620 Bits (see Cryptocurrency Units). In the URI payment request, however, it’s still written in decimal BTC. The buyer, who receives this request, will now be shown how much is being requested and asked to confirm payment (instead of adding their own amount as in the previous example). The wallet that opens the payment request might display the amount in decimal BTC as entered, or could use another more readable unit such as Bits. Many wallets will also convert the amount into fiat currency, which is useful as a sanity check on the amount you are sending. It’s likely the amount won’t come out to exactly five dollars, since the exchange rate may have changed in between when the request was sent and when it is viewed, and the wallet the buyer is using might get its conversion data from a different source than the seller, and it might therefore be slightly different.
The seller can also add additional information to the payment request, including their name, and a description of what is being sold (spread over multiple lines for clarity):
bitcoin:n4ijQMT8NtB58dZrgodiMMmjFZh4KyKEG3
?amount=0.00062
&label=Starbucks
&message=CappuccinoWhen receiving this request, the buyer’s wallet should display that the payment of 0.00062 BTC is being made to Starbucks, and that it’s for a Cappuccino. Note that the label and message are intended only for display to the buyer. They are not part of the transaction in the blockchain.
That’s the basic outline of the BIP-21 specified bitcoin: URI. The standard also allows for prefixing variable names with req- which would mean the wallet is required to use that variable. That allows for some future-proofing, where if new variables were added, the seller could require that a specific variable is used by the wallet, and if the wallet doesn’t understand the variable, then the whole request is considered invalid. Theoretically this could be used today to require the display of the label and message:
bitcoin:n4ijQMT8NtB58dZrgodiMMmjFZh4KyKEG3
?amount=0.00062
&req-label=Starbucks
&req-message=CappuccinoIf the wallet only understood the address and amount, but not the label and message, then it should reject the request. Considering this was a later addition to the standard, however, it’s questionable whether all wallets that understand bitcoin: URIs would know what to do with req- prefixed variables. Most likely many would just would just ignore them, and might actually have the opposite effect of what was intended (i.e. if the wallet does support label and message variables, it might not display them if it doesn’t support req- prefixes).
Ethereum:
Many cryptocurrencies that have added their own URIs, either officially or unofficially, have started by copying bitcoin’s BIP-21 format. Ethereum’s ERC-67, titled ‘Standard URI scheme with metadata, value and byte code’, starts out by stating it is inspired by BIP-21. The scheme name is obviously different, using ethereum: instead of bitcoin:. After the colon the address is added, same as BIP-21. After that, however, everything is different. Instead of amount, ERC-67 uses value. Value is the number of Wei, not a decimal of Ether (see Cryptocurrency Units for information on the difference between Wei and Ether). Well, actually, some implementations also support the amount variable to be kind of backwards compatible with BIP-21, meaning you could request Ether in Wei using value and Ether by using amount. Not sure what would happen if you used both and they were different amounts. Probably the wallet would ignore one of them.
Because it’s Ethereum it needs variables to deal with gas, so there’s the gas variable to express the gas limit. There’s also a data variable to allow the inclusion of code in hex format (this of course introduces security issues). A simple ERC-67 URI would look something like:
ethereum:0x40F15be3a8cDAf4d95FAa874E70F07Ca040006B7This would just request that Ether be sent to the included address. The wallet would show a payment request with that address, and the user receiving the request would need to fill in the amount. The generator of the URI could of course add the amount, such as:
ethereum:0x40F15be3a8cDAf4d95FAa874E70F07Ca040006B7
?value=10000This would instead specifically request 10,000 Wei be sent to the included address. It’s not worth going into the details of ERC-67 URIs, however, because even though some wallets support them, ERC-67 has been replaced by EIP-681 and EIP-831. These try to keep things backwards compatible, so the above links would still work, but let’s take a quick look at what is possible in EIP-681/831 URIs. Here’s a valid EIP-681/831 URI:
ethereum:pay-ethereum:0x40F15be3a8cDAf4d95FAa874E70F07Ca040006B7%401
?value=1e18Let’s break that down. The scheme name is the same, but after that there is a prefix (pre-) and a payload (ethereum) followed by the address to pay.
At the end of the address the @1 (encoded as %401) indicates ChainID 1, which is the Ethereum Mainnet. EIP 155 introduced ChainIDs to prevent replay attacks, where a signed transaction created on one Ethereum network is re-broadcast on another, such as taking a transaction from a testnet and broadcasting it on the mainnet.
Finally the value requested is 1e18, which is 10 to the 18th power Wei, or simply 1 Ether. You can also specify the value in Ether by adding the unit variable:
ethereum:pay-ethereum:0x40F15be3a8cDAf4d95FAa874E70F07Ca040006B7%401
?value=1
&unit=ETHThe above URI would be exactly same as the previous one.
The real problem here is that no wallets actually support everything in EIP-681 and EIP-831. This is a problem for all of the URIs in the table above, but perhaps more pronounced for Ethereum which has more complex URI support to connect to smart contracts and trade tokens. While delving into how those are accomplished would be useful, it’s perhaps premature since the support for those features is either missing completely or inconsistently implemented in Ethereum wallets today.
Bitcoincash:
Perhaps the most interesting URI format is the one proposed as the second generation URI for Bitcoin Cash – BUIP-86. Bitcoin Cash is a hard fork from the original Bitcoin blockchain, when a split between developers of Bitcoin on how to scale the blockchain occurred, one side going with SegWit (Bitcoin), and the other side going with larger block sizes (Bitcoin Cash). The reason, however, was a lot more than just a difference in opinion on scaling. It was really a philosophical difference on the purpose of Bitcoin, with both sides claiming to defend the initial goals of Bitcoin, even claiming to support the ideals of Bitcoin creator Satoshi Nakamoto.
Bitcoin Cash has had a lot of development since it was hard forked, adding lots of interesting features in its goal of becoming a method of payment, not just a store of value (perhaps the clearest explanation of the goals of BCH versus BTC developers). Obviously, a well developed payment protocol would be important to achieve that goal, which was proposed in BUIP-86. Interestingly enough BUIP-86 was created by Brenden Lee, who is now involved in BitcoinSV, a hard fork from Bitcoin Cash. What that means for the further development of BUIP-86 is anyone’s guess. It’s still worth taking a look at some of the ideas proposed in BUIP-86, in any case.
Some interesting features of BUIP-86 include:
- Multiple payment outputs (for example sending a payment to the a restaurant’s address for the amount of the food, sending a payment to another address to cover sales tax, and a third address to cover the tip for the server).
- Multiscan mode, where a user can scan multiple items and have them combined into a single transaction. This could be used, for example, in a store where you scan a QR code on each item to add them to your cart, and when you’re done you ‘check out’ and complete the transaction by sending the total amount of all items to a single designated address.
- Compressed labels, which are one or two character versions of the variable names which can be used to keep the length of the URI shorter.
Starting with a simple example, let’s say you want someone to pay you 10 BCH, you could create a URI like:
bitcoincash:qq00x4m9x6nx9et54tlqwv732df36wvlrcs4fvtr9z
?version=2.0
&amount=10Like the above URIs, the URI starts with the scheme name (bitcoincash) and after the colon is the address (in this case a Bitcoin Cash cashaddr address). There is a version number to indicate to the wallet app that this is using the BUIP-86 standard, and an amount.
Now let’s use the same coffee example as above. You buy a cappuccino at Starbucks and the server presents a you with a QR code, the URI encoded in the QR code of which might look like (spread out over multiple lines for clarity):
bitcoincash:qq00x4m9x6nx9et54tlqwv732df36wvlrcs4fvtr9z
?version=2.0
&label=Starbucks
&amount=0.02
&message=CappuccinoExcept with BUIP-86 we can go further and get something like:
bitcoincash:qq00x4m9x6nx9et54tlqwv732df36wvlrcs4fvtr9z
?version=2.0
&label=Starbucks
&amount=0.02
&message=Cappuccino
&address%5B1%5D=qq28kthz8qdq49hx3hejs67fp0g04k82dvsulz8wcg
&amount%5B1%5D=0.001
&message%5B1%5D=Sales%20Tax
&address%5B2%5D=qqsrrmkrr0sqd7a6fvn0cn4vzmw7n7tkjss0407muv
&label%5B2%5D=Shared%20Tip%20Jar
&message%5B2%5D=TipLet’s break that down. You start out the same, paying .02 BCH for a cappuccino. There is then a second address – address[1] – which is properly URL encoded. That address has a message indicating it is for sales tax, which is calculated at 5% of the total. There’s then a third address – address[2] – which has a message indicating it is a tip, and a label showing it’s going to the shared tip jar for all the servers. Since there is no amount, the wallet app should prompt you to ask how much if at all you’d like to tip. It’s not part of the spec, but if I was designing the wallet app, I would reserve the message Tip to trigger an easy tip paying experience where it would offer you simple 10%, 12%, 15%, etc. options and show you what that would cost.
Let’s take a look at an alternate version of the amount URI:
bitcoincash:qq00x4m9x6nx9et54tlqwv732df36wvlrcs4fvtr9z
?v=2.0
&l=Starbucks
&am=2x6
&m=Cappuccino
&ad%5B1%5D=qq28kthz8qdq49hx3hejs67fp0g04k82dvsulz8wcg
&am%5B1%5D=1x5
&m%5B1%5D=Sales%20Tax
&ad%5B2%5D=qqsrrmkrr0sqd7a6fvn0cn4vzmw7n7tkjss0407muv
&l%5B2%5D=Shared%20Tip%20Jar
&m%5B2%5D=TipThere are two differences in the above URI compared to the earlier one. First, the compressed labels are used instead of the full length ones (l= instead of label=, am= instead of amount=, etc.). Second, the amounts are specified in hexdigits, which can be confusing, but since the spec uses them it’s useful to show them and explain them better.
Using the compressed labels and hexdigits, the length of the complete string goes from 327 characters to 274 characters, a savings of 53 characters, or about a 16% reduction of the total. Interestingly enough, some older QR code scanner apps have trouble with strings above 300 characters, so this smaller version might mean the difference between being able to be read or not.
Just a moment to point out the hexdigits shown, which are 2×6 and 1×5. These correspond to the same numbers in the previous URI, which are .02 and .001. The way these are calculated is from Satoshis (is the smallest amount in BCH even called a Satoshi?) or the smallest (atomic) unit in Bitcoin Cash. As with Bitcoin, the smallest amount is 1/100000000, or 10e-8 in scientific notation. That means to get to 1 BCH you need to multiply the unit by 100,000,000 or 10e8. This is expressed as 1×8 in this system, so to go back two digits you multiply by 1,000,000 instead, or 1×6 or .01 BCH. So to get the .02 BCH above, you write it as 2×6 and to get .001 BCH you write it as 1×5. This is a bit counterintuitive, and it’s probably better to stick to decimals for clarity, but as most users won’t need to interpret the string directly it probably doesn’t matter.
It’s always better to keep the string as short as possible, as the larger the string, the more complex the QR Code is, and the harder it will be to be read by the app scanning it. This is particularly true when the QR Code is being shown on a cell phone screen that may or may not be high enough resolution to show it clearly. The smaller the string the larger the blocks in the QR Code, which makes them easier to read. Here’s the above URI encoded into a QR Code:
That QR Code shouldn’t be a problem for any scanner to read, but as this standard allows for even more complex URIs, this could become a problem.
One problem with URIs, any of the ones above, is using them with iPhones. Unlike Android which will ask you which app to use if multiple apps support the URI scheme you are attempting to us, the iPhone will randomly select at app that supports the scheme. That’s kind of stupid. This means that if you have several wallet apps that support the bitcoincash: scheme that you can’t pick which one will get triggered to handle the URI. The only real solution at this point is to scan the URI (either via QR Code or NFC) within the wallet app itself (assuming your wallet app of choice supports scanning QR Codes or NFC tags). That’s really the only work-around, since even if you could get the URI text by scanning it into an app that doesn’t trigger it (there are plenty of these) most apps wouldn’t let you enter that URI anywhere. That might be a useful feature-of-last-resort, but its unlikely that would be implemented before QR Code scanning, so kind of useless.
Another problem is what happens if the wallet app doesn’t fully support the standard. For example the above QR Code was scanned on an iPhone which triggered a specific wallet, and when that wallet opened up, it had built a payment to the first address and was asking the amount. That means it didn’t understand the version number, or any of the additional variables, and didn’t understand the shorter variable name that provided the amount. All of the other addresses and amounts were ignored. Generating a QR Code based on the original longer URI that used full variable names and decimal units showed the amount pre-filled in the wallet (but only for the first address). Interestingly, generating a QR Code with the same string but a hexdigit value did insert the hexdigit value into the wallet’s amount field, but it wouldn’t accept that as a valid input when moving to confirm it.
One of the cool features of BUIP-86 is multiscan contracts, where you can scan multiple QR Codes (or NFC Tags) and combine them into a single transaction. For example, you go into your local Piggly Wiggly supermarket, and let’s say they support multiscan. Each item has a QR Code or NFC Tag that has a URI such as:
bitcoincash:qq00x4m9x6nx9et54tlqwv732df36wvlrcs4fvtr9z
?v=2.0
&label=Piggly%20Wiggly
&amount=0.014
&message=Flamin%27%20Hot%20Cheetos%208.5oz
&ad%5B1%5D=qq28kthz8qdq49hx3hejs67fp0g04k82dvsulz8wcg
&am%5B1%5D=0.0007
&m%5B1%5D=Sales%20Tax
&multiscan=trueThis URI adds an 8.5oz bag of Flamin’ Hot Cheetos to your cart, at a cost of .014 BCH. The multiscan=true in the URI makes the wallet app wait for more scans before completing the transaction. Let’s say you scan another item:
bitcoincash:qq00x4m9x6nx9et54tlqwv732df36wvlrcs4fvtr9z
?v=2.0
&label=Piggly%20Wiggly
&amount=0.016
&message=12-pack%20Cherry%20Coca%20Cola%20Zero%20Sugar%2012oz
&ad%5B1%5D=qq28kthz8qdq49hx3hejs67fp0g04k82dvsulz8wcg
&am%5B1%5D=0.0008
&m%5B1%5D=Sales%20Tax
&multiscan=trueand another:
bitcoincash:qq00x4m9x6nx9et54tlqwv732df36wvlrcs4fvtr9z
?v=2.0
&label=Piggly%20Wiggly
&amount=0.0042
&message=Campbell%27s%20Soup%20Condensed%20Tomato%20Soup%2010.75oz
&ad%5B1%5D=qq28kthz8qdq49hx3hejs67fp0g04k82dvsulz8wcg
&am%5B1%5D=0.00021
&m%5B1%5D=Sales%20Tax
&multiscan=trueNow you have three items in your wallet waiting to be paid – the original cheetos, a 12-pack of Cherry Coke Zero, and a can of Campbell’s soup. Each food item is being paid to one address, while all the sales tax is being paid to a second address. Each time you scan an item, the wallet should show you the item specifics, update the running total, and ask the user if they have more to scan. If yes, scan another item. If no, then combine the items and create a single transaction. In this case, finishing the purchase would mean:
0.0342BCH to qq00x4m9x6nx9et54tlqwv732df36wvlrcs4fvtr9z
0.00171BCH to qq28kthz8qdq49hx3hejs67fp0g04k82dvsulz8wcg
Total amount being sent (minus fees): 0.03591BCHIn addition, the wallet could display a summary memo, something like:
Recipient: Piggly Wiggly
Flamin' Hot Cheetos 8.5oz, 0.014BCH ($3.79)
12-pack Cherry Coca Cola Zero Sugar 12oz, 0.016BCH ($4.33)
Campbell's Soup Condensed Tomato Soup 10.75oz, 0.00021BCH ($1.19)
Subtotal: 0.0342BCH ($9.31) to qq00x4m9x6nx9et54tlqwv732df36wvlrcs4fvtr9z
Sales Tax: 0.00171BCH ($0.46) to qq28kthz8qdq49hx3hejs67fp0g04k82dvsulz8wcg
Total: .03591BCH ($9.77)The wallet could save that memo along with the transaction information for later reference. The dollar values are there for reference, and the wallet could generate those by referencing the current exchange rate for BCH/USD and using that to create USD estimates of the price for reference. When dealing with small decimal amounts, it’s always nice to see a reference in a currency you have a better reference point to, to figure out if you’re paying a fair amount. There’s no reason this has to be USD obviously. Since the amounts are only given in BCH, it’s up to the wallet to display any fiat currency comparison, and to choose which currency to display.
Is maximalist the way to go?
Don’t take the length of the look at BUIP-86 as any endorsement of BCH over BTC or ETH. This isn’t about maximalism. It’s just a look at features of different URI schemes used, or at least proposed, in the cryptocurrency space (cryptoworld? cryptocosm? cryptoindustry?).
At the end of the day, one of the biggest problems all of these URI schemes have is that they ALL exist. All of them operate to some extent like the original BIP-21 specification, and then extend (embrace, extend…) it to offer more features. Innovation is great, but no wallet developer can keep up with every payment scheme of every cryptocurrency, especially as new ones emerge. Maximalists would argue that they only need to focus on one of them, since only the only important cryptocurrency is theirs. This is shortsighted, however. There’s a lot of great work being done in lots of different cryptocurrencies, and while much of that work is necessarily specific to a specific cryptocurrency, things like payment schemes and URIs don’t need to be coin-specific, and one could argue that they are hurt by having such a singular focus.
The solution to this conundrum in another article.
Leave a comment