Does Bitcoin need an account? The developer thought it was necessary, and it took 1 year to design the system

Bitcoin does not have an "account" in the traditional sense. Instead, funds are sent to a unique "transaction output" every time a payment is made. In such output, the Bitcoin address may be reused, in which case the address acts a bit like a Bitcoin account. However, reusing addresses in this way makes it easy for different coins and transactions to correspond to the same user, which is bad for privacy. Therefore, after each payment, Bitcoin users are advised to generate a new address.

Although this is to protect privacy, Spanish developer José Femenías Cañuelo believes this is not user friendly.

bitcoin

Cañuelo says:

"In a way, we have become accustomed to the way Bitcoin is paid, but it is really too rough, like using the Internet without a domain name and relying only on the IP address-and worse, because the password address is longer and more Difficult to identify and constantly changing. "

To solve this problem, in the past year, the developer figured out how to install an account system on Bitcoin. Cañuelo elaborated on this idea in a white paper and proposed his layer 2 protocol: Easypaysy.

Although retaining the most valuable attributes of Bitcoin-such as privacy and autonomy (no need to rely on escrow)-Cañuelo believes that his proposal will significantly improve the user experience of Bitcoin: it will make payments undeniable, and Higher frequency.

Easypaysy Bitcoin Account

As the main feature of this solution, Easypaysy does not need to rely on any external resources. Whether it is to establish an account or use an account, it is performed on the Bitcoin blockchain.

The Bitcoin account described in the proposal was created through a specific transaction. This type of transaction has one input (the "send" part of the transaction), which includes two multisig addresses. This means that two public keys will be displayed and the transaction will be signed. The transaction also has an output (the "receive" part), which is the OP_RETURN output. In this case, the output does not actually receive any funds; it only contains a little bit of data.

The two public keys used in the input belong to the account owner who created the transaction, both of which have their own functions. The first public key is called the "identity key" and it is essentially the digital identity of the account owner. Anyone who wants to communicate with him privately must use this public key to encrypt the message. The second public key is called the "value key" and is used to receive payments.

Two different public keys are used because value keys are more valuable than identity keys: the latter is used for messages and the former is used for funds. Cañuelo explained:

"Identity keys must be 'online', which is vulnerable to vulnerabilities, just as online wallets are easier to expose than offline wallets. It may be wise to keep value keys in cold storage, while identity keys can be more Active for communication. "

The OP_RETURN text in the output also has its effect. It is a small JSON document (a machine-readable data format) named "Rendezvous descriptor". This document contains account information. Specifically, it details the types and methods of payment that account owners are willing to accept. (In fact, Cañuelo's proposal supports various payment methods; more on this below.)

These two public keys and the Rendezvous descriptor are all the information the account needs to contain. When designing this particular transaction to create an account, you need to add a fee (so the multi-signature address must have been minimally funded), and then broadcast it to the Bitcoin network and include it in In a block.

Easypaysy Bitcoin Account ID

At this point, people need to find accounts.

This is where Cañuelo's proposal is clever. Once the transaction is contained in a block, the account will automatically be assigned an account ID based on its position in the blockchain. Specifically, the account ID contains the exact block in which the exchange is located and the position of the transaction in the block-a combination of a blockchain identifier and a checksum.

It looks like this: blockchain@block.transaction/checksum

Let us study this problem step by step with a random example.

Suppose we are using Bitcoin. Then, the blockchain identifier is "btc".

Suppose this transaction is contained in block 543847. (This is a real bitcoin block with an output date of October 2018-but it doesn't matter; we are just an example now.)

Assume that this transaction is the 636th transaction in the block.

Finally, checksums are an encryption technique used for extra security.

Cañuelo says:

"It contains three hashes: the hash of the account block, the Merkle root of that block, and the hash of the account transaction itself. So if someone tries to send you the wrong account data, you can easily detect . "

In this example, the checksum is 577.

Therefore, the 636th transaction contained in the Bitcoin block 543847 will generate an account ID: btc@543847.636/577. More specifically, this will be the "canonical ID" because blocks, transactions, and checksums are all represented numerically.

Considering practicality, this canonical ID-btc@543847.636/577 can also be expressed as a "mnemonic ID". Using BIP39's bitcoin wallet seed format, the number of this account ID can be converted into several words (or a combination of words). This should be easier to remember.

The number in the account ID in this example can be divided into three data blocks.

543847 = cancel-mind

636 = exhibit

577 = motion Therefore, the mnemonic ID in this case is: btc@cancel-mind.exhibit/motion.

Finally, the Easypaysy white paper also proposes "Domain Name ID", which will depend on the Domain Name System (DNS). In short, such an ID would include an actual domain name, a blockchain identifier, and a checksum, and link it to an account ID through the DNS system. Here is an example of a domain name ID: btc@bitcoinmagazine.com/561.

Such IDs will depend on external resources (ie DNS) and will cost money and some maintenance work. Cañuelo expects that there may only be some business groups interested in them.

Pay

We have an account and an account ID. Now, someone-we call him the "payer"-wants to pay the owner of the account, and we call him the "payee." The payer has the payee's mnemonic ID. (The account ID, in whatever form, can simply be shared with anyone, just like an email address or phone number.)

To make a payment, the payer's first step is to convert the mnemonic ID back to the canonical ID. With the BIP 39 format, the payer simply converts the words in the mnemonic ID back to numbers and gets the canonical ID: btc@543847.636/577.

Using canonical IDs, payers can use checksums to ensure that block heights and transaction numbers match. This is not required, but can be used as an additional check to ensure that there are no typos or to prevent someone from maliciously submitting a similar account.

The payer now knows where to find the account: this is the 636th transaction in block 543847. So he checked it.

The transaction contains a JSON document in the Rendezvous descriptor: OP_RETURN output. The Rendezvous descriptor specifies what type of payment the account is willing to receive and how to receive it. It can be all the types supported by the agreement, or it can be chosen at will.

Among the types of payments accepted by the payee, the payer chooses his preferred payment method and makes the payment. The transaction is complete.

Payment Types

So what payment methods are included in this proposal?

Type 0

The first type of payment-type 0-is the simplest type, but also the worst type in terms of privacy. Type 0 payments are basically just payments for value keys, and therefore involve the reuse of corresponding addresses, as many donor addresses do today. Cañuelo actually discourages the use of this type of payment, but he still respects user choices.

Type 1

The second type of payment-type 1-requires interaction. For this type, the payer contacts the payee to request a new Bitcoin address. The Easypaysy protocol is flexible in how to establish contacts; it can be done via email, webpage, chat application, or other methods.

When providing the address (assuming by mail), the payee also uses his identity key to sign the address. This means confirming to the payer that the address is actually the address of the payee and not an illegal address belonging to a hacker.

Type 2

The third type of payment-type 2-requires no interaction. Similar to the technique previously used for stealth addresses, type 2 payments allow the payer to generate a new Bitcoin address for the payee, and the payee (and only the payee) can spend at this address.

To do this, the payer needs to generate a single-use public key pair. Using the private key of the key pair, combined with the payee's value key, the payer generates a new public key and the corresponding Bitcoin address. The payer sends funds to this new address, and—importantly—adds the single-use public key to the same transaction as the 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 corresponding to the new public key, thereby generating the corresponding Bitcoin address. In other words, if the payee knows the single-use public key, he (and only he) can use the funds of this new Bitcoin address.

To understand the single-use public key, either the payer will notify the payee of the transaction, or the payee will use the OP_RETURN output to check all new Bitcoin transactions. For each OP_RETURN output, he needs to check if it is a public key in order to use the funds contained in the transaction in combination with his private value key. But this is often not the case. But if that's the case, he knows he has got the money.

Type 3

The fourth payment method-type 3-is similar to the second. However, this time, the OP_RETURN output must be prefixed with the identifier "EP". This makes them more discoverable by payees, but they do need to pay a little more for payers.

Advantages of a Bitcoin Account

As a layer 2 proposal, Cañuelo's account system does not need to make any changes to the Bitcoin protocol, nor does it need to obtain consensus across the industry. Personal wallets can adopt this recommendation tomorrow, and users can use it immediately.

Cañuelo believes that this will greatly increase the usability of Bitcoin and open up a whole new potential for the protocol.

"Among them, non-repudiation is an important factor. Suppose you go to buy Lamborghini, the dealer will give you a QR code and tell you to send money to that address. You agree. But the next day, the dealer's accountant told You are still waiting for payment. How do you prove that you paid? Because the Bitcoin address is semi-anonymous, you cannot prove that you transferred the money to a Lamborghini dealer. "

With Cañuelo's account system, this kind of risk will no longer exist: the payer can always provide proof of payment to a specific account. This is obvious for type 0 payments; the money is sent to the account's publicly visible value key. Type 1 payments are also easy to prove, as the provided Bitcoin address is signed with the payee's identity key. But even for type 2 and 3 payments, the payer can prove that the payment has been completed: the one-time private key can prove all the information required by the recipient through cryptography, determine that the transaction is his, calculate the private key, and let him spend funds.

Another benefit is that Cañuelo's account system will make regular payments more feasible: take into account rents, subscriptions or other regular transactions with the same entity. Wallet software can be used to accept payment requests from a specific account, and at most a certain amount can be accepted within a specific time period. (For example, the landlord's account can charge up to 0.1 bitcoin per month if this is a monthly rent.)

In addition, it will be easier for merchants to return funds. For example, when someone makes a payment, the merchant finds that the product ordered is out of stock. With the account system, money can be easily returned to customers without asking for a specific return address.

Finally, Cañuelo's account system will provide blockchain identities to Bitcoin users for the first time.

"For example, this could mean that when you log in to a website, you are using Easypaysy ID without entering a password. The website requires you to sign a message with your private key. Even if the website is hacked, you are always safe Yes, because they don't store any passwords. "

Disadvantages of Bitcoin accounts

However, one of the most powerful features of Cañuelo's account system may also be its biggest disadvantage: it relies entirely on the Bitcoin blockchain to embed account data in it. However, block space is very scarce and scalability is a challenge.

To address this, Cañuelo suggested in his white paper that accounts can be opened in large numbers: a transaction may include hundreds or even thousands of accounts for the same number of users. In this case, the OP_RETURN data will point to all external sources of account data, possibly a website. OP_RETURN will also contain the Merkle roots of all these account data, so the payer can check the account data against the Merkle roots. Although this solution relies on external resources, at least the user can ensure that the data is not tampered with.

Another solution is to use other blockchains, such as Litecoin, to open accounts. Add the index number to an account that references Litecoin or another blockchain. Although this solution can be said to be sufficiently secure, of course, it also has obvious shortcomings, that is, Bitcoin users will rely on another cryptocurrency to a certain extent.