{"id":18918,"date":"2019-12-02T14:08:39","date_gmt":"2019-12-02T14:08:39","guid":{"rendered":"http:\/\/ci027cfe81300226c3"},"modified":"2019-12-02T14:08:39","modified_gmt":"2019-12-02T14:08:39","slug":"bitcoin-need-accounts-one-developer-thinks-figured","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-need-accounts-one-developer-thinks-figured","title":{"rendered":"Does Bitcoin Need Accounts? One Developer Thinks So, and He Figured Out How"},"content":{"rendered":"
<\/div>
<\/figure>\n

Bitcoin doesn\u2019t use typical \u201caccounts.\u201d Instead, with each payment, the funds are sent to a unique \u201ctransaction output.\u201d 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.<\/p>\n

While a best practice for privacy, Spanish developer Jos\u00e9 Femen\u00edas Ca\u00f1uelo believes this isn\u2019t exactly user friendly.<\/p>\n

\u201cWe are somewhat used to Bitcoin payments the way they are, but it\u2019s really an atrocity,\u201d Ca\u00f1uelo told Bitcoin Magazine<\/em>. \u201cIt\u2019s like using the internet without domain names, relying only on IP addresses \u2014 only worse, because crypto addresses are way longer, uglier and constantly changing.\u201d<\/p>\n

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<\/a>, Femen\u00edas is now proposing his Layer 2 protocol: Easypaysy<\/em>.<\/p>\n

While preserving Bitcoin\u2019s most valuable attributes \u2014 such as privacy and self-sovereignty (no need to rely on custodians) \u2014 the Spaniard believes his proposal would improve the Bitcoin user experience significantly: It would enable non-repudiation, recurring payments, and more.<\/p>\n

Easypaysy Bitcoin Accounts<\/h2>\n

As a key property of Femen\u00edas\u2019 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.<\/p>\n

This is possible because an account is created with a special transaction. This transaction has one input (the \u201csending\u201d 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 \u201creceiving\u201d half), which is an OP_RETURN output. In this case, the output doesn\u2019t actually receive any funds; it just includes a little bit of data.<\/p>\n

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 \u201cIdentity key,\u201d and it is essentially the account holder\u2019s 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 \u201cValue key,\u201d and it is used to receive payments.<\/p>\n

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. \u201cThe Identity key must be ‘online,’\u201d Femen\u00edas explained. \u201cThat 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.\u201d<\/p>\n

The OP_RETURN text in the output, then, also serves a function. It is a small JSON<\/a> document (a machine-readable data format) called the \u201cRendezvous descriptor.\u201d 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\u00edas\u2019 proposal supports various types of payment; more on this later.)<\/p>\n

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.<\/p>\n

Easypaysy Bitcoin Account IDs<\/h2>\n

Now people need to be able to find the account.<\/p>\n

This is where Femen\u00edas 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.<\/p>\n

Like so: blockchain@block.transaction\/checksum.<\/p>\n

Let\u2019s look at this step by step, with a random example.<\/p>\n

Say we\u2019re using Bitcoin. The blockchain identifier, then, is \u201cbtc.\u201d<\/p>\n

And let\u2019s say the transaction is included in block 543,847. (This is a real Bitcoin block, mined in October 2018 \u2014 but that\u2019s not important; we\u2019re just making something up for now.)<\/p>\n

Let\u2019s also say that the transaction is the 636th transaction in that block. (Again, this transaction actually exists, but we\u2019re just making something up here; there\u2019s no need to look up the actual transaction.)<\/p>\n

The checksum, lastly, is a cryptographic trick for extra security.<\/p>\n

\u201cIt is extracted by hashing three items,\u201d Femen\u00edas said, \u201cthe 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.\u201d<\/p>\n

In our example, the checksum would be 577.<\/p>\n

So, the 636th transaction included in Bitcoin block number 543,847 would result in account ID: btc@543847.636\/577. More specifically, this would be the \u201ccanonical ID,\u201d as the block, transaction and checksum are shown in numbers.<\/p>\n

To make it even more practical, this canonical ID \u2014 btc@543847.636\/577 \u2014 can also be expressed as a \u201cmnemonic ID.\u201d Leveraging the BIP 39 word format<\/a>, 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.<\/p>\n

The numbers in the account ID of this example can be cut into three chunks.<\/p>\n

543847 = cancel-mind<\/p>\n

636 = exhibit<\/p>\n

577 = motion<\/p>\n

As such, the mnemonic ID from this example would be: btc@cancel-mind.exhibit\/motion.<\/p>\n

Lastly, the Easypaysy white paper also proposes \u201cDomain IDs,\u201d 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: btc@bitcoinmagazine.com\/561.<\/p>\n

These types of IDs would rely on an external source (DNS) and would cost money and some effort to maintain. Femen\u00edas expects they\u2019d probably only be interesting to commercial parties.<\/p>\n

Payments<\/h2>\n

So we have an account and an account ID. Now, someone \u2014 let\u2019s just call him \u201cthe payer\u201d \u2014 wants to pay the owner of our account, who we\u2019ll call \u201cthe payee.\u201d The payer has the payee\u2019s 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.)<\/p>\n

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: btc@543847.636\/577.<\/p>\n

With the canonical ID, the payer can use the checksum to make sure that the block height and the transaction number match. This isn\u2019t 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.<\/p>\n

Either way, the payer now knows where to find the account: It\u2019s the 636th transaction in block 543,847. So he looks it up.<\/p>\n

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.<\/p>\n

Of the payment types that the payee accepts, the payer picks his favorite and makes the payment. Done.<\/p>\n

Payment Types<\/h2>\n

So which payment types are possible? Femen\u00edas\u2019 protocol includes four payment types.<\/p>\n

Type 0<\/h3>\n

The first payment type \u2014 type 0 \u2014 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\u00edas 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.<\/p>\n

Type 1<\/h3>\n

The second payment type \u2014 type 1 \u2014 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.<\/p>\n

When the address is provided (let\u2019s 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\u2019s \u2014 and not an address belonging to a hacker that gained access to the payee\u2019s email account, for example.<\/p>\n

Type 2<\/h3>\n

The third payment type \u2014 type 2 \u2014 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.<\/p>\n

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\u2019s Value key, the payer generates a new public key and corresponding Bitcoin address. The payer sends the funds to this new address, and \u2014 importantly \u2014 adds the single-use public key to the same transaction as an OP_RETURN output.<\/p>\n

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.<\/p>\n

To learn of the single-use public key, the payee is either notified of the transaction by the payer, or <\/em>the payee simply checks all new Bitcoin transactions with an OP_RETURN output. For each OP_RETURN output, he checks if it\u2019s 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<\/em> the case, he knows he\u2019s been paid.<\/p>\n

(To read how this works in a little more detail, see this article<\/a> on stealth addresses and reusable payment codes.)<\/p>\n

Type 3<\/h3>\n

The fourth payment type \u2014 type 3 \u2014 is similar to the second type. This time, however, OP_RETURN outputs must be prefaced with the identifier \u201cEP.\u201d This makes them easier to spot for the payee, but they do cost a little bit extra in fees for the payer.<\/p>\n

Benefits of Bitcoin Accounts<\/h2>\n

As a Layer 2 proposal, Femen\u00edas\u2019 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.<\/p>\n

Femen\u00edas, of course, believes this would greatly benefit Bitcoin\u2019s usability, opening up a whole new potential for the protocol.<\/p>\n

\u201cOf these, non-repudiability is a big one,\u201d Femen\u00edas said. \u201cLet\u2019s 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\u2019s accountant tells you they are still waiting for the payment. How do you prove you paid? Because Bitcoin addresses are pseudonymous, you can\u2019t prove you sent the money to the Lamborghini dealer.\u201d<\/p>\n

With Femen\u00edas\u2019 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\u2019s publicly visible Value key. Type 1 payments are also easy to prove, as the provided Bitcoin address was signed with the payee\u2019s 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.<\/p>\n

Another benefit is that Femen\u00edas\u2019 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\u2019s account would be allowed to charge up to 0.1 bitcoin per month, if that\u2019s the monthly rent.)<\/p>\n

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.<\/p>\n

Lastly, Femen\u00edas\u2019 account system would, for the first time, offer Bitcoin users a blockchain identity.<\/p>\n

\u201cThis 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,\u201d Femen\u00edas suggested. \u201cEven if the website is hacked, you are always safe because they don’t store any passwords.\u201d<\/p>\n

Downsides <\/h2>\n

All that said, one of Femen\u00edas\u2019 account system\u2019s 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.<\/p>\n

To minimize this problem, Femen\u00edas 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\u2019t tampered with.<\/p>\n

An alternative solution could be to use a different blockchain \u2014 such as Litecoin\u2019s \u2014 to open accounts. In this case, an index number<\/a> 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.<\/p>\n

For more information and details, see the <\/em>Easypaysy white paper<\/em><\/a>.<\/em><\/p>\n