cypherpunk dot org -

The tax elephant in the room

There is a huge elephant in the room when considering crypto payments, and it seems like most people don’t see it. Whether you see it or not, it will have a massive influence on crypto payment systems.

Form 1040 for individual tax returns in the US

As cryptocurrencies become more widespread, and find their ways into more and more systems we use every day (such as Twitter’s recent addition of Bitcoin to its tip system), the implication of that elephant will become more widely understood. The elephant is that every time you spend cryptocurrency, whether by directly paying someone with it, or indirectly paying someone by using something like a crypto debit card, you are generating a taxable event. To be clearer, when you buy a cup of coffee at the neighborhood bodega with cash or a regular credit/debit card, you are not taxed for spending the money on the coffee. When you buy that same cup of coffee using cryptocurrency, you will be taxed on the money you spent (this assumes the value of your cryptocurrency has gone up since you got it, but even if it has not, you still need to report your coffee purchase in your tax filings).

Towards a common crypto transport layer

There are many ways the crypto community can work together to bring common standards to the ecosystem and improve adoption of the technology. One of those ways is coming up with a common payment protocol (see Towards a singular payment protocol), although that proposal only covers a small part of how different cryptocurrencies and even fiat currencies can work together. Even for payments, the simple system described in that article only works for currencies that have addresses where the payment can be sent. There are cryptocurrencies, such as those based on mimblewimble, that have no addresses that can be handed out. Currencies such as those require a two-way communications channel to be established in order to complete a transaction. As mentioned in the same article, there are also compelling reasons to have two-way communications even when you have an address to send a payment to, as you can do things like confirm transaction fees, decide who will pay those fees, send receipts, etc.

Developing a way to communicate between two ends of a transaction requires tradeoffs between security, privacy and convenience. Users of such a communication system could choose what is the most important to them, and use it in whatever way they choose.

For example, the simplest and fastest way for two people (or machines) to communicate is directly. This is more or less the idea behind BIP-70 which allowed direct communication over https using X.509 certificates for authentication. BIP-70 took advantage of this two-way communication system to provide proof-of-payment to the buyer and a refund address to the seller, among other useful features. However, detractors of the protocol opposed it because it lowered the privacy of the buyer. The seller’s server would always know the IP address of the buyer’s wallet, for example, since it was connecting via https.

On the other hand, if you trust your recipient, then a direct connection to them prevents eavesdropping on the hops in between (except by your network provider of course), even if the only data that can be gleaned is meta data (IP addresses, size of message, destination, etc.).

Using a pure distributed hash table (DHT) approach would put your message on many machines that don’t need to see it. Optimizing the shortest route might reduce that risk, but that assumes each hop along the way is trusted. A bad actor could install many nodes to ‘help’ maintain such a network, and track everything going through its nodes.

Let’s say you visit a merchant, and want to buy something from them. This could be a physical store or someplace online. If you’re not shipping something physical to yourself, there’s no need for the merchant to know who you are, where you live, or what the IP address is of the device your wallet is running on. You can always choose to give the merchant identifying information, but that should really be up to you. You don’t get carded buying a coffee at a corner bodega, and you shouldn’t get virtually carded when you want to donate money to a charity or buy an ebook to read on your computer or iPad.

A cryptocurrency address name service

Here’s how a cryptocurrency name service could work. Instead of using a cryptocurrency address in a payment request, you would use a name. That name would resolve in standard DNS to a web page. That web page would also offer an API for a wallet to retrieve a real address.

Let’s take a look at how this would work. The resolver site registers a standard domain such as cyphername.com. The web site allows users to register an account whose username becomes a web page.

Of course, a top-level domain could be acquired for this purpose, with enough support, but that requires more centralization. With independent sites, anyone anywhere could set up a name service. No need to centralize this.

Companies could also operate their own services on their own domain (pay.companyname.com could be their address). So when a company wants to be paid in Bitcoin, for example, they would provide pay.companyname.com as the address, and the wallet receiving the payment request would go to that address and get back a Bitcoin address to use in the payment.

The web page

Stepping back to a simple service hosted on a web site. Let’s say the username chosen is dave. The web page dave.cyphername.com goes live. As a person if you visit that page you can request an address. If the person has more than one cryptocurrency it could ask you to first request the currency and then generate the address. It could present the address in a few different ways. It could simply present the address, or it could present a QR Code with the address, or you could provide additional information such as how much you plan to send to the address, what the payment is for, and it could generate a payment URI (and accompanying QR Code).

Wallet API

Now let’s say you’re using a wallet. You want to send Dave BTC. Instead of entering a BTC address, you enter dave.cyphername.com (probably prefaced by a character to indicate to the wallet to connect to that site without having to do much analysis – maybe an @ or a #). The wallet interprets this as a name resolver, and through an API requests an address for BTC from dave.cyphername.com, which returns the address to the wallet, which will now use the returned address to send the BTC. The wallet could ask the user to enter a description of what is being paid for which would be sent to the resolver (and on to the owner of the name). The transaction on the Bitcoin blockchain would use the address provided by the API, so even though the user sending the payment knows the address is associated with the username, no one else does.

The technicalities

There would need to be some standardization so wallets would know how to access the API, but the simplest way to do this is probably a REST API at a defined port number. The wallet could authenticate for the person who owns the name, or just allow access to addresses for everyone else.

When accessing the API, the client (the wallet) could ask for more than one address, perhaps to help obfuscate a payment. The results could be returned in JSON, either with a single address or a series of them if requested. The API could also allow requesting addresses for different currencies, but it could default to a specific one.

The web interface wouldn’t really need any standardization. Developers who build on this concept could offer whatever features they want. QR Codes and payment URIs don’t need to be supported, but could be if they wanted to. The web interface could also allow the owner to access the back-end and see what addresses have been given out, and if there were memos associated with them. From a security point of view, however, it might be better to erase mention of any addresses given out in the past. The name owner would have a way to receive information about those given out (through their wallet, or even to an e-mail address), and then the information would be removed from the server.

Where do the addresses come from?

There are existing sites that allow a person to hand out a web page URL to enable the user to give out a human-readable address, and then have the web site give out your address(es). Those sites can offer multiple coins, but always offer the same address for each coin, which is a problem. Best practice is to never re-use an address (for those coins that support multiple addresses).

Here’s where things get interesting. The person setting up the name could provide a public key and chain code from an HD wallet, which would allow the resolver to generate new public keys, and thus addresses, at will. If you’re sure the resolver is going to be secure, this is a great solution. If you’re not sure, it can be a risk, since someone who has both public keys and the chain code can determine the private key, compromising all the addresses generated by the site. Not ideal.

A prefered solution to this is to allow the user to upload keys to use. If using a wallet that can connect via API, then the resolver receiving a request from the user who created the page could respond that it’s running out of addresses, and request more. The wallet could then generate a 100 more addresses, and send them to the resolver to use. The name owner’s wallet could regularly connect to the resolver to check if more names are required, and to retrieve any memos added when the addresses were given out.

Let’s say you don’t have a wallet that can connect via API. Instead you could create a bulk wallet, generating 10,000 addresses, and just upload the CSV to the resolver site to use. If you wanted to you could manually get addresses from your wallet app and add them to the resolver. This could allow complete anonymity (assuming you connect to the resolver site through a VPN) as there is never a need to connect to the site to update it. You set it and forget it. Just don’t lose your private keys.

Towards a singular payment protocol

As described in A look at cryptocurrency URIs there have been many efforts in the last decade of cryptocurrency development to create easier ways to facilitate payments using coin-specific URIs and payment protocols. The first widely used design was BIP-21 for Bitcoin, which formed the basis for other efforts for Ethereum, Bitcoin Cash, etc. The fundamental problem with all of these efforts is that they are coin-specific. Of course each cryptocurrency has its own aspects that require different options in a URI or protocol. Ethereum added support for gas, chain ID, and inserting code in hex format. Bitcoin Cash added support for multiple payment outputs, multiscan contracts, and compressed labels. Some of the Ethereum additions are specific to Ethereum, but for the most part all of these additions can be generalized and used by all cryptocurrencies.

A short note to maximalists. Don’t dismiss this just because another coin is mentioned here. There are advantages to this idea even for those who never want to interact with other coins, tokens, or blockchains.

At the end of the day, who is actually doing the development on these payment protocols? It’s the wallet developers, and many wallets support multiple cryptocurrencies. Nothing in the various proposals for payment system effects the underlying blockchains they operate on. These are on a higher layer. Of course there are reference implementations like Bitcoin Core, and those developers could resist support for something NIH, but with enough support from wallet developers and payment processors, and a fundamentally better protocol, even core developers should see the benefit of a shared way to manage payments.

This doesn’t prevent individual cryptocurrencies from developing their own systems separate from this, but by supporting a common system as well, it insures that wallet developers can support their cryptocurrencies for payments, and then, like now, they can then decide if a coin-specific protocol is also necessary. On the flip side, as new cryptocurrencies are introduced, they will no longer need to come up with their own payment protocol.

The suggestion here is to coin a new URI that is blockchain-agnostic. Something simple like coin: or pay: (odd that pay: is not registered at the IANA yet). Set up a common forum with developers from different blockchains to work together to figure out what each one needs, and how to generalize the protocol to support all of them.

A look at cryptocurrency URIs

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.

The ticker symbol problem

Cryptocurrencies (and indeed all currencies) are referred to by their names, by letter-based ticker symbols, as well as by graphic symbols. Common ticker symbols for cryptocurrencies include BTC for Bitcoin and ETH for Ether. You may have also seen XBT used for Bitcoin, and therein lies the seed of a major problem for those looking to mainstream the use of cryptocurrencies, and integrate with the fiat currency world. The cryptocurrency long-game may be to replace fiat currencies, but in the short-term there will be a need to interact with them, trade with them, and convert one type of currency to another.

Putting aside the issue of whether cryptocurrencies are currencies, commodities, or assets, the crypto community has for the most part built them as if they are currencies. This includes assigning letter-codes to each cryptocurrency, in a similar (but unregulated) fashion as the codes that are assigned to fiat currencies. Fiat currency codes are regulated by the International Organization for Standardization (ISO), whose ISO 4217 defines the codes for each currency. The currently used codes are:

Cryptocurrency units

Taking a look at the units used by various cryptocurrencies gives some insight into their history and how they’re being used.

Most cryptocurrencies use some form of metric (now officially the International System of Units, or the abbreviation SI from the original French Système International d’Unités) prefixes to denominate their currencies, so it’s worth first taking a look at those prefixes. The International System of Units has defined the prefixes such as centi for 1/100, milli for 1/1000, kilo for 1,000, and giga for 1,000,000. We use these all the time such as for centimeters or kilograms. These are not used as much in the United States, although for those who use computers they know kilo-, mega-, giga-, and terabytes (even though these are not strictly speaking metric as they are multiples of 1024 bytes, not 1000). Here are the SI prefixes and the numbers they are associated with:

SI Units

Prefix	Symbol	Number	Scientific Notation	Short Scale Name
yocto	y	0.000000000000000000000001	1E-24	septillionth
zepto	z	0.000000000000000000001	1E-21	sextillionth
atto	a	0.000000000000000001	1E-18	quintillionth
femto	f	0.000000000000001	1E-15	quadrillionth
pico	p	0.000000000001	1E-12	trillionth
nano	n	0.000000001	1E-09	billionth
micro	μ	0.000001	1E-06	millionth
milli	m	0.001	1E-03	thousandth
centi	c	0.01	1E-02	hundredth
deci	d	0.1	1E-01	tenth
		1	1E+00	one
deca	da	10	1E+01	ten
hecto	h	100	1E+02	hundred
kilo	k	1,000	1E+03	thousand
mega	M	1,000,000	1E+06	million
giga	G	1,000,000,000	1E+09	billion
tera	T	1,000,000,000,000	1E+12	trillion
peta	P	1,000,000,000,000,000	1E+15	quadrillion
exa	E	1,000,000,000,000,000,000	1E+18	quintillion
zetta	Z	1,000,000,000,000,000,000,000	1E+21	sextillion
yotta	Y	1,000,000,000,000,000,000,000,000	1E+24	septillion

Cryptocurrencies for the most part try to use these prefixes, although different coins have different idiosyncrasies as to how they are used.