Block chain digital contracts, how to delegate ownership?

Author | Giacomo Zucco

Translator | Him Zebian | Xu Veyron

Produced | block chain base camp (blockchain_camp)

In this article, we will be based on the use of digital puzzles as a way to reproduce the scarcity of thought, based on supply and control mechanism to impart a certain hardness of the importance of digital currency, to explore the concept of money. Proof of ownership by signing and scripts, and the technique known as CoinJoin.

Proof of ownership: Signature

We plan to make our second fund to focus on people and the topic of "who" question.

You determine the conditions for the issuance of new sat, but how do they transfer? Who has the right to change the data sharing balance sheet, the transfer of ownership of it?

If there is a re-allocation sat responsible central authority, the operation (for example, you can use the classic method of user name and password login system, just like e-gold experiment before you) in accordance with the instructions of the current owner, fragile single point of failure again: Why move from physical gold to the PoW-based "digital scarcity" mean?

On the other hand, if each user has equal rights reassigning ownership, then your system simply will not work: everyone will be encouraged to continue assigning other people sat to yourself. You need some kind of authority consistent with the definition of the agreement, everyone can be independently checked.

The solution is called a digital signature encryption technology. It works like this: First, Alice chooses a random number, called the private key, she will this number be kept strictly confidential. She then passed through a special mathematical function of the digital to the mathematical function, which is easy to apply in one direction but almost impossible to reverse. The result is another called digital public key, Alice no secret, on the contrary, she was sure that Bob knows it. Eventually, she passed through a second private key functions and messages, but also difficult to reverse the function, which leads to a very large number, called a signature. Bob may be the third and final mathematical function applied to the message, signature, and Alice's public key, thereby positively or negatively verification. If the result is positive, he can determine Alice authorize the message (authentication), she later could not refuse the authorization (non-repudiation) and the message has not been altered (integrity) during transmission.

In a way, it is similar to a handwritten signature (hence the name) , everyone can easily check some public sample, but if there is no "right hand" of the owner, it is difficult to copy. Or wax seal, everyone can easily be checked in accordance with the official seal, etc. Even, but without the right wax, it is difficult to copy.

So, you can change the protocol to prove that the work is part of a digital signature can be independently re-use. The first model you achieve is very simple: each user to independently generate a private key and create a public account, and marked with the corresponding public key. When the user wants to transfer ownership, they will create a message, including their accounts, receive account and the number they want to transfer sat. They then digitally sign and broadcast the message that everyone can be verified.

Interestingly, many of the famous (but probably pseudonym) developers can use a similar scheme to sign the different versions of the software, so that they are free to change, improve, repair, update, review and viewing software, and any end-user systems. Before you can run their preferred version, with a minimum of trust and fragmented network independently verify the signature, without a single centralized authority to distribute software. This process can achieve real code to the center.

Intelligent script and contracts

However, you do not want to share before accepting any changes to the balance sheet will limit each peer must check the condition as merely the validity of digital signatures.

You decide each message can also contain script : a description illustrates the receiving account (or multiple accounts) other conditions that must be met in order to once again spend again. For example, the sender may take several secret key combination (link or separation) or a specific wait time before consumption. Starting from these basic types are very simple (and easy to audit), you can build complex smart contract, even in the absence of a central participant in the case of funds can be effectively programmed.

Durability (and scalability) problem

And an encrypted messaging system (if Alice sends some messages to Bob, only Bob can read them) different, your program has not really optimized for durability (if Alice sends to Bob sat, it must be displayed outside the Bob her message, at least in terms of the future will get the same people who sat).

Money in circulation. The recipient can not trust any transfer, even if the signature is correct, we can not verify whether the transfer has really sat transferred to that particular payer, and so on, from the upstream back to the original issue of PoW based. Sat as long as there is enough liquidity, active peers can learn a lot from past transactions, and can number, time, and account for statistical metadata associated with the use of forensic analysis techniques, so that many users anonymous and can eliminate their denial sex.

This is problematic: As discussed in Part 2, durability for money is a basic quality, whether from an economic or sociological point of view is true.

Intelligent contract to make this problem even more serious, because certain overhead conditions may be used to identify a specific software or a particular organizational strategy.

This lack of durability is more serious than the effects of your previous e-gold experiment. At that time, you will most deals metadata stored on a central server, but at least it is only you, not anyone (including many Mallory agents), who can access! In addition, you can implement some of the special high-level encryption strategy, in order to make themselves invisible to the user what actually happened between the at least partially.

Associated with this design there is a small-scale problem: the digital signature is very large, in order to verify everything, the recipient needs to receive the transmission chain includes a number of signatures, which may increase the cost of verification. In addition, the parallel account changes difficult to verify.

A new paradigm: "CoinJoin"

To alleviate this problem, you decide to change the basic solid model from a similar bank account for transaction output (UTXO) unused.

Sat with the transfer from one account to another account of the different instructions, now Each message contains a list of old UTXOs, these old UTXOs from past transactions, is consumed as an ingredient, as well as a list of new UTXOs as product "generate" to prepare for future transactions.

Bob must be received each payment he wants to offer a new, one-time public key, rather than release a single, static public key references (such as a bank or e-mail address IBAN) as the general account. When Alice pay him, and she signed a message to unlock some of sat UTXO previously created and re-lock them in to a new UTXO.

Like cash as spending bill can not always match the payment request, and therefore often need to be changed. For example, if Alice wants to pay 1,000 seat satellite to Bob, but she only controls a few lock 700 satellites UTXO, she will sign two in one consumes 700 satellites UTXO (total of 1,400 seats unlock satellite) and generate the new UTXO two transactions: a Bob key associated with the lock payments (1,000 sat), another associated with Alice's key, lock change (400 sat).

To assume that people will not pay for repeated use different keys, then this design itself increases the darkness. However, when your users are beginning to realize a single transaction generated UTXOs consumption and not necessarily from both entities, the situation is even more so.

Alice can create a message using the old UTXOs her control and generate new UTXOs (associated with Bob), then she can pass the message to Carol, Carol can simply add the old UTXOs she wants and she wants to create a consumer new UTXOs (associated with Daniel). Finally, Alice and Carol are signed and broadcast the composite message (while the payment to Bob and Daniel).

This particular usage UTXO model called "CoinJoin". (Trigger warning: actual history Bitcoin, this usage is not in accordance with Nakamoto design UTXO model itself, but in the years after UTXO release, other developers discovered a potential problem in the design). It can break the link between statistical output, while preserving the so-called Atomic: A transaction either completely valid or invalid, so Alice and Carol do not have to trust each other. (If a signature part of attempts to change before adding their own signature message, the existing signature will be invalid.)

Your system may be changed, in fact, could further improve the situation: a different digital signature scheme, you can replace now use a digital signature scheme, which is linear signature. This means: acquiring two private key (in addition to the two figures nothing), the same signature message for each message, and the result is a signature (that is, two very large numbers) are added together, the result It happens to be the correct signature corresponding private key associated with the two initial sum of two public keys.

It sounds complicated, but the meaning is simple: When CoinJoining, Alice and Carol can add its own signature, then only the sum of broadcasting, everyone can control their public key to verify the total. As we said, because the signature is the heaviest part of the transaction, so only a radio broadcast rather than multiple possibilities will save a lot of resources. Outside observer would suspect that each transaction is ultimately CoinJoin, since many users may pursue efficiency. This assumption will break most forensic heuristic.

Even without further improvement, UTXO model has somehow improved scalability: Change different account model in a state that it can be validated and batch parallelization.

So far, you have learned:

You can use a digital signature decentralization of ownership;
You can use the scripting system to convert programmable intelligent transaction contract;
More complex paradigm called CoinJoin can further increase the darkness and scale.

However, since your users can fully decentralized way of issuing sat and transfer them, how they can ensure compliance with a single chronology, in order to avoid double expenditure attack or attempt to modify the timetable inflation?

It was left to everyone's thinking questions, I hope this article useful to you, and we welcome the comments section to discuss.

【End】