Does Bitcoin Need Accounts? One Developer Thinks So, and He Figured Out How
Bitcoin doesnâ€™t use typical â€œaccounts.â€� Instead, with each payment, the funds are sent to a unique â€œtransaction output.â€� In such an output, the Bitcoin address can potentially be reused, in which case the address would act a bit like a Bitcoin account. Reusing addresses in this way, however, makes it trivial to link different coins and transactions to the same user, which is horrible for privacy. Bitcoin users are instead encouraged to generate a new address for each receiving payment.
While a best practice for privacy, Spanish developer JosÃ© FemenÃas CaÃ±uelo believes this isnâ€™t exactly user friendly.
â€œWe are somewhat used to Bitcoin payments the way they are, but itâ€™s really an atrocity,â€� CaÃ±uelo told Bitcoin Magazine. â€œItâ€™s like using the internet without domain names, relying only on IP addresses â€” only worse, because crypto addresses are way longer, uglier and constantly changing.â€�
To solve this issue, over the past year, the developer figured out how to bolt an account system on top of Bitcoin. Having extensively detailed the idea in a new white paper, FemenÃas is now proposing his Layer 2 protocol: Easypaysy.
While preserving Bitcoinâ€™s most valuable attributes â€” such as privacy and self-sovereignty (no need to rely on custodians) â€” the Spaniard believes his proposal would improve the Bitcoin user experience significantly: It would enable non-repudiation, recurring payments, and more.
Easypaysy Bitcoin Accounts
As a key property of FemenÃasâ€™ proposal, Easypaysy would not depend on any outside source. Both setting up the account as well as using it all happens on the Bitcoin blockchain itself.
This is possible because an account is created with a special transaction. This transaction has one input (the â€œsendingâ€� half of the transaction), which includes a two-of-two multisignature (multisig) address. This means that two public keys are revealed, signing the transaction. The transaction also has one output (the â€œreceivingâ€� half), which is an OP_RETURN output. In this case, the output doesnâ€™t actually receive any funds; it just includes a little bit of data.
The two public keys used in the input belong to the account owner who also created the transaction, and both keys serve a function. The first public key is called the â€œIdentity key,â€� and it is essentially the account holderâ€™s digital identity. Anyone who wants to communicate with him privately must use this public key to encrypt the messages. The second public key is called the â€œValue key,â€� and it is used to receive payments.
There are two different public keys instead of one because the Value key is even more valuable than the Identity key: The latter is used for messages, the former for money. â€œThe Identity key must be â€˜online,â€™â€� FemenÃas explained. â€œThat opens it up to vulnerabilities, in the same way that online wallets are more exposed than offline wallets. It may be wise to keep the Value key in cold storage, while the Identity key is more actively used to communicate.â€�
The OP_RETURN text in the output, then, also serves a function. It is a small JSON document (a machine-readable data format) called the â€œRendezvous descriptor.â€� This document contains information about the account. Specifically, it details which types of payments the account owner is willing to accept and how. (Indeed, FemenÃasâ€™ proposal supports various types of payment; more on this later.)
The two public keys and the Rendezvous descriptor are all the information the account needs to contain. When this special account-creation transaction is drafted, a fee is added (as such, the multisig address must have been minimally funded), and it is broadcasted to the Bitcoin network to be included in a block.
Easypaysy Bitcoin Account IDs
Now people need to be able to find the account.
This is where FemenÃas slipped in one of the nifty tricks of his proposal. Once the transaction is included in a block, the account is automatically assigned an account ID, based on its place in the blockchain. Specifically, the account ID consists of the exact block that the transaction is included in, and the location of the transaction in that block. This is combined with a blockchain identifier and a checksum.
Like so: email@example.com/checksum.
Letâ€™s look at this step by step, with a random example.
Say weâ€™re using Bitcoin. The blockchain identifier, then, is â€œbtc.â€�
And letâ€™s say the transaction is included in block 543,847. (This is a real Bitcoin block, mined in October 2018 â€” but thatâ€™s not important; weâ€™re just making something up for now.)
Letâ€™s also say that the transaction is the 636th transaction in that block. (Again, this transaction actually exists, but weâ€™re just making something up here; thereâ€™s no need to look up the actual transaction.)
The checksum, lastly, is a cryptographic trick for extra security.
â€œIt is extracted by hashing three items,â€� FemenÃas said, â€œthe hash of the block that includes the account, the Merkle root of that block, and the hash of the account transaction itself. Thus, if anyone tries to send you bad account data, you can easily detect it.â€�
In our example, the checksum would be 577.
So, the 636th transaction included in Bitcoin block number 543,847 would result in account ID: firstname.lastname@example.org/577. More specifically, this would be the â€œcanonical ID,â€� as the block, transaction and checksum are shown in numbers.
To make it even more practical, this canonical ID â€” email@example.com/577 â€” can also be expressed as a â€œmnemonic ID.â€� Leveraging the BIP 39 word format, used for Bitcoin wallet seeds, the numbers in the account ID can be converted into a couple of words (or combinations of words). This should be easier for humans to memorize.
The numbers in the account ID of this example can be cut into three chunks.
543847 = cancel-mind
636 = exhibit
577 = motion
As such, the mnemonic ID from this example would be: firstname.lastname@example.org/motion.
Lastly, the Easypaysy white paper also proposes â€œDomain IDs,â€� which would depend on the Domain Name System (DNS). In short, such IDs would include an actual domain name, as well as a blockchain identifier and a checksum, and link it to an account ID through the DNS system. For example, a domain ID would look like this: email@example.com/561.
These types of IDs would rely on an external source (DNS) and would cost money and some effort to maintain. FemenÃas expects theyâ€™d probably only be interesting to commercial parties.
So we have an account and an account ID. Now, someone â€” letâ€™s just call him â€œthe payerâ€� â€” wants to pay the owner of our account, who weâ€™ll call â€œthe payee.â€� The payer has the payeeâ€™s mnemonic ID, because the payee gave it to him. (The account ID, in whatever form, can simply be shared with anyone, like an email address or a phone number.)
To make the payment, the first step for the payer is to convert the mnemonic ID back into the canonical ID. This step is trivial. Using the BIP 39 format, the payer simply converts the words in the mnemonic ID back into numbers, and ends up with the canonical ID: firstname.lastname@example.org/577.
With the canonical ID, the payer can use the checksum to make sure that the block height and the transaction number match. This isnâ€™t strictly necessary, but it serves as an extra check to make sure there were no typos in the account, or maybe to prevent someone from nefariously handing over a similar-looking account.
Either way, the payer now knows where to find the account: Itâ€™s the 636th transaction in block 543,847. So he looks it up.
This transaction then includes the Rendezvous descriptor: the JSON document in the OP_RETURN output. This Rendezvous descriptor specifies which types of payments the account is willing to receive and how. This can be all types supported by the protocol or any selection of them.
Of the payment types that the payee accepts, the payer picks his favorite and makes the payment. Done.
So which payment types are possible? FemenÃasâ€™ protocol includes four payment types.
The first payment type â€” type 0 â€” is the simplest type but also the worst one for privacy. Type 0 payments are basically just payments to the Value key and, therefore, involve reusing the corresponding address, like many donation addresses do today. FemenÃas actually discourages this type, but he still wanted to include it in the protocol as an option for those who really want to use it.
The second payment type â€” type 1 â€” requires interaction. For this type, the payer contacts the payee to ask for a new Bitcoin address. The Easypaysy protocol is flexible in how this contact is made; it can be by email, through a web page, in a chat app or by some other means.
When the address is provided (letâ€™s say through email), the payee also signs the address with his Identity key. This offers confirmation to the payer that the address is really the payeeâ€™s â€” and not an address belonging to a hacker that gained access to the payeeâ€™s email account, for example.
The third payment type â€” type 2 â€” requires no interaction. Resembling tricks previously used for stealth addresses, type 2 payments let the payer generate a new Bitcoin address for the payee, from which the payee (and only the payee) can spend.
To do this, the payer needs to generate a single-use public key pair. Using the private key of this key pair, in combination with the payeeâ€™s Value key, the payer generates a new public key and corresponding Bitcoin address. The payer sends the funds to this new address, and â€” importantly â€” adds the single-use public key to the same transaction as an OP_RETURN output.
Interestingly, the payee can use this single-use public key in combination with his Value key to generate a new private key that corresponds with the new public key, and thus the corresponding Bitcoin address. In other words, if the payee learns of the single-use public key, he (and only he) can spend the funds from the new Bitcoin address.
To learn of the single-use public key, the payee is either notified of the transaction by the payer, or the payee simply checks all new Bitcoin transactions with an OP_RETURN output. For each OP_RETURN output, he checks if itâ€™s a public key that he can combine with his private Value key to spend the funds included in that transaction. This will often not be the case. But when it is the case, he knows heâ€™s been paid.
(To read how this works in a little more detail, see this article on stealth addresses and reusable payment codes.)
The fourth payment type â€” type 3 â€” is similar to the second type. This time, however, OP_RETURN outputs must be prefaced with the identifier â€œEP.â€� This makes them easier to spot for the payee, but they do cost a little bit extra in fees for the payer.
Benefits of Bitcoin Accounts
As a Layer 2 proposal, FemenÃasâ€™ account system would not require any changes to the Bitcoin protocol, nor would it need industry-wide consensus. Individual wallets can adopt the proposal tomorrow, and after that users could use it immediately.
FemenÃas, of course, believes this would greatly benefit Bitcoinâ€™s usability, opening up a whole new potential for the protocol.
â€œOf these, non-repudiability is a big one,â€� FemenÃas said. â€œLetâ€™s say you go to the Lamborghini dealer to buy your new ride. Once you agree on the price, the dealer shows you a QR code and tells you to send the payment to that address. So you do. But the day after, the dealerâ€™s accountant tells you they are still waiting for the payment. How do you prove you paid? Because Bitcoin addresses are pseudonymous, you canâ€™t prove you sent the money to the Lamborghini dealer.â€�
With FemenÃasâ€™ account system, this would no longer be a risk: The payer could always provide proof of payment to a specific account. For type 0 payments, this is obvious; the money was sent to the accountâ€™s publicly visible Value key. Type 1 payments are also easy to prove, as the provided Bitcoin address was signed with the payeeâ€™s Identity key. But even for Type 2 and 3 payments, the payer could prove that the payee was really paid: The single-use private key can cryptographically prove that the payee has all the information needed to identify the transaction as his and to compute the private key that lets him spend the funds.
Another benefit is that FemenÃasâ€™ account system would make recurring payments much more feasible: think of rent, subscriptions, or other periodic transactions to the same entity. Wallet software could be programmed to accept payment requests from a specific account, up to some maximum amount per period. (For example, the landlordâ€™s account would be allowed to charge up to 0.1 bitcoin per month, if thatâ€™s the monthly rent.)
Further, it would be much easier for merchants to return funds. This could be useful, for example, when someone makes a purchase, but the merchant later finds that the ordered product is out of stock. With an account system, the money can be returned to the customer easily, without needing to ask for a specific return address.
Lastly, FemenÃasâ€™ account system would, for the first time, offer Bitcoin users a blockchain identity.
â€œThis could, for example, mean that when you login to a website, you use your Easypaysy ID, and instead of asking for a password, the website challenges you to sign a message with your private key,â€� FemenÃas suggested. â€œEven if the website is hacked, you are always safe because they donâ€™t store any passwords.â€�
All that said, one of FemenÃasâ€™ account systemâ€™s most powerful features, may also be its biggest drawback: It relies fully on the Bitcoin blockchain by embedding account data in it. Block space is scarce, however, and scalability is a challenge.
To minimize this problem, FemenÃas in his white paper suggests that accounts could also be opened in bulk: One transaction could include hundreds or even thousands of accounts, for as many users. In this case, the OP_RETURN data would point to an outside source for all the account data, perhaps a website. The OP_RETURN would also include a Merkle root for all this account data, so the payer can check the account data against the Merkle root. While this solution would depend on an outside source (like a website), at least users could make sure the data isnâ€™t tampered with.
An alternative solution could be to use a different blockchain â€” such as Litecoinâ€™s â€” to open accounts. In this case, an index number is added to the account referring to Litecoin, or whichever blockchain is used. While this solution would arguably be secure enough in the case of Litecoin, it does, of course, come with the obvious downside that Bitcoin users would come to rely on a different cryptocurrency, to a certain extent.
For more information and details, see the Easypaysy white paper.
The post Does Bitcoin Need Accounts? One Developer Thinks So, and He Figured Out How appeared first on Bitcoin Magazine.