I (along with other developers) started a protocol in an effort to overcome the user experience difficulties that are associated with non-human readable addresses used in cryptocurrencies. We call the protocol OpenCAP. After the first version spec was released, I was approached by Josh Ellithorpe to give some input on a protocol him and some others were building called CashAccounts which aimed to do the same thing.
The purpose of this article is to explain the differences between the two protocols, and trade-offs that are made in as unbiased a manner as is possible. I want to state at the beginning that I have major respect for Josh, Jonathan, and anyone working on this problem. Even though we sometimes disagree slightly on implementation, I enjoy our collaboration.
- One alias can represent many different cryptos (BTC, BCH, NANO, etc.)
- Protocol specifies only communication
- Alias format is fully customizable “lane$ogdolo.com”
- Aliases can update the addresses and payment codes they represent
- Only on BCH (For now, more details below)
- Protocol specifies communication and storage
- Decentralized and distributed
- Alias format is partially customizable “lane#726238”
- Aliases immutably represent an address (or payment code) and can’t be changed.
Many Coins vs BCH
OpenCAP allows users to use the same alias for any kind of cryptocurrency. If you want to pay me in BCH, you can pay me using “lane$ogdolo.com”. Likewise, to pay me in NANO you can pay me at “lane$ogdolo.com”
CashAccounts are tied to the BCH blockchain only. In theory you could code other coin’s addresses into the BCH blockchain, but that seems unlikely. You could also port the protocol to BTC for instance, but now each user would have a BTC alias and a separate BCH address.
Communication vs Communication and Storage
OpenCAP is only a communication protocol that allows wallets to resolve an alias (lane$ogdolo.com) to an address (bitcoincash:qz5bg64353…). It doesn’t specify a storage layer. This unopinionated approach gives each server the flexibility to choose how it wants to store data.
CashAccounts specify both storage and communication in the same protocol. The trade-off is that CashAccounts have less flexibility for features, but ensure that all servers have a reliable and trusted data store (the blockchain itself)
Decentralized vs Distributed
OpenCAP is a decentralized system, and works in a way similar to email. What this means is that aliases are hosted on webservers, but there is no central designated webserver. Anyone can run their own server in order to have full control of their aliases.
CashAccounts take it a step further by writing the alias information onto the BCH blockchain. This makes CashAccount distributed as well, in other words, the whole blockchain needs to agree on what address your alias represents, instead of just your own server.
The trade-off is that CashAccounts are more reliable due to blockchain consensus, but give up certain features in order to make that happen.
OpenCAP uses the following format: “username$domain.tld”
OpenCAP solves the “squatting” problem (someone early on in adoption taking all the good names) by building on top of DNS. DNS is already fairly distributed amongst the population, and usernames can be changed on a per-domain basis.
CashAccounts use the following format: “username#accountnumber.accounthash”
for example “lane#2345.8392838”
The account number and account hash are used to solve the squatting problem. They are not customizable, and are obviously not very readable or memorable. The good news is that the hash section is only needed in rare cases, and the account number can be as short as 3 numbers (in the best case) For example: “lane#123”
CashAccounts gives up more readable and customizable format, in exchange for a (sometimes) shorter format, and in order to stay on-chain.
OpenCAP allows for full mutability if desired. An alias can be updated to represent a new address associated with the same wallet, or a new address corresponding to an entirely different wallet.
CashAccounts use payment codes. A payment code ensures that a different address is used for each payment, but that alias will always be associated with that same wallet (set of private keys).
The trade-off is that CashAccounts are reliable in the sense that your address will never change. No one can maliciously change the underlying address. However, if the private keys to a wallet are ever compromised, or the account needs to be re-keyed due to a falling-out among members of a group (accountant leaves a company, a couple gets divorced, etc) a CashAccount address is dead and can’t be used again.
One of the big benefits of OpenCAP is that I can go around online and post “lane$ogdolo.com” with full confidence that I will always be able to receive money at that alias.
Again, thanks to everyone working on CashAccounts and OpenCAP. I love crypto and want to see it adopted as world money. If there is anything incorrect in this article I would be happy to correct it, just let me know.
I’m glad there are two potential solutions to this problem, and I’m glad to let the market and users decide what they like.
OpenCAP: Making Crypto Convenient. Contribute to opencap/protocol development by creating an account on GitHub.
Open-Source OpenCAP server:
OpenCAP server (reference implementation). Contribute to opencap/go-server development by creating an account on…
Free OpenCAP custodial server:
SPECIFICATION.md · master · Cash Accounts / Cash Account Specification
Cash Accounts is a naming system that can be used alongside regular bitcoin addresses to simplify the process of…