In this article, we will explore the concept of currency based on the idea of using digital puzzles as a way to reproduce scarcity, and based on the supply control mechanism to give the digital currency a certain degree of importance. Proof of ownership through signatures and scripts and a technology called CoinJoin.
1. Proof of ownership: signature
Our funding plan enables us to focus on the topic of people and the question of “who” for the second time.
You set the conditions for issuing new sats, but what about transferring them? Who has the right to change the data in the shared balance sheet and transfer ownership?
If there is a central agency responsible for redistributing sat, follow the instructions of the current owner (for example, you can use the classic username and password method to log in to the system, just like your previous electronic gold experiment), a fragile single point of failure Reappear: Why move from physical gold to PoW-based “digital scarcity”?
On the other hand, if every user has equal rights to redistribute ownership, then your system will not work at all: everyone will be encouraged to continue to assign other people’s sat to themselves. You need some kind of consistent authority to define the agreement, which everyone can check independently.
The solution is an encryption technology called a digital signature. It works like this: First, Alice chooses a random number, called the private key, and she keeps this number absolutely secret. Then, she passes the number to the mathematical function through a special mathematical function, which is easy to apply in one direction, but it is almost impossible to reverse it. The result is another number called the public key, which Alice does not keep secret at all, instead, she makes sure that Bob knows it. In the end, she passes the private key and message through the second function, which is difficult to reverse, which results in a very large number called a signature. Bob can apply the third and final mathematical function to the message, signature, and Alice’s public key to perform positive or negative verification. If the result is positive, he can be sure that Alice authorized the message (identity verification), she will not be able to deny the authorization in the future (non-repudiation) and the message has not been changed during transmission (integrity).
In a way, it is similar to a handwritten signature (hence the name) , everyone can easily check some public samples, but without the owner of the “right hand”, it is difficult to copy. Or wax seal, everyone can easily check according to the official seal, but if there is no correct wax model, it is difficult to copy.
Therefore, you can change the agreement so that part of the proof of work can be independently reused through digital signatures. The first model you implement is simple: each user independently generates a private key and creates a public account, marked with the corresponding public key. When a user wants to transfer ownership, they create a message that includes their account, the receiving account, and the amount of sat they want to transfer. Then, they digitally sign and broadcast the message, and everyone can verify it.
Interestingly, many famous (but possibly pseudonymous) developers can use similar schemes to sign different versions of the software so that they can freely change, improve, fix, update, review and view the software, and Any end user of the system. The signature can be independently verified using a minimized and fragmented network of trust before running the respective preferred version, without requiring a single authorization to centrally distribute the software. This process can achieve true code decentralization.
2. Scripts and smart contracts
However, you don’t want to limit the conditions that each peer must check to only the validity of the digital signature before accepting any changes in the shared balance sheet.
You decide that each message can also contain a script: a description stating other conditions that the receiving account (or accounts) must meet again in order to spend again. For example, the sender may require a combination of several secret keys (linked or separated) or a certain waiting time before consumption. Starting from these very simple (and easily auditable) basic types, complex smart contracts can be constructed that can effectively program funds even in the absence of a central participant.
3. Durability (and scalability) issues
Unlike an encrypted messaging system (if Alice sends some messages to Bob, only Bob can read them), your solution is not really optimized for durability (if Alice sends Bob to sat, it must be displayed outside of Bob Her news, at least for those who will get the same sat in the future).
Funds are circulating. The payee cannot trust any transfer, even if the signature is correct, it cannot verify whether the transferred sat has actually been transferred to the specific payer, and so on, returning from the upstream to the original PoW-based issuance. As long as sat has sufficient liquidity, active peers can understand a large number of past transactions and can use forensic analysis technology to statistically correlate the quantity, time, metadata, and accounts, thereby making many users anonymous and eliminating their denial Sex.
This is problematic: As discussed in Part 2, durability is a basic quality for money, both from an economic and sociological point of view.
Smart contracts make this problem even more serious because specific cost conditions may be used to identify specific software implementations or specific organizational strategies.
This lack of durability is more serious than affecting your previous electronic gold experiments. At that time, you stored most of the transaction metadata on a central server, but at least it was you, not anyone (including many Mallory agents), who could access it! In addition, you can implement some particularly advanced encryption strategies to make yourself at least partially invisible to what is actually happening between users.
There is also a small scale problem related to this design: the digital signature is very large, in order to verify everything, the transfer chain that the payee needs to receive includes many signatures, which may increase the cost of verification. In addition, account changes are difficult to verify in parallel.
4. A new example: “CoinJoin”
To alleviate such problems, you decide to change the basic entity of the model from a bank-like account to an unused transaction output (UTXO).
Unlike the instruction to transfer sat from one account to another, each message now contains a list of old UTXOs that are derived from past transactions and are consumed as ingredients, and there is also a list of new UTXOs, as The product “generates” to prepare for future transactions.
Bob must provide a new, one-time public key for each payment he wants to receive, instead of issuing a single, static public key as a general account reference (such as a bank IBAN or email address). When Alice paid him, she signed a message to unlock some sats of the previously created UTXO and relock them to some new UTXOs.
Just like cash, the bills that can be spent do not always match the payment request, so changes are often required. For example, if Alice wants to pay Bob 1,000 satellites, but she only controls a few UTXOs that lock 700 satellites, she will sign a UTXO that consumes 700 satellites (total unlocked 1,400 satellites) and generate Two new UTXOs are traded: one is associated with Bob’s key to lock payment (1,000 sat), and the other is associated with Alice’s key to lock change (400 sat).
Assuming that people will not reuse keys for different payments, this design itself adds darkness. However, this is especially true when your users begin to realize that UTXOs consumed and generated by a single transaction do not necessarily come from two entities.
Alice can create a message, use the old UTXOs she controls and generate new UTXOs (associated with Bob), then she can pass the message to Carol, and Carol can simply add the old UTXOs she wants to consume and the old UTXOs she wants to create New UTXOs (associated with Daniel). In the end, both Alice and Carol signed and broadcast the composite message (paying Bob and Daniel at the same time).
This special usage of UTXO model is called “CoinJoin”. (Trigger warning: In the actual history of Bitcoin, this usage is not the basis for Satoshi Nakamoto to design the UTXO model itself, but many years after the release of UTXO, other developers discovered a potential problem in the design). It breaks the statistical linkability between outputs while retaining the so-called atomicity: transactions are either completely valid or invalid, so Alice and Carol do not have to trust each other. (If one of them tries to change a partially signed message before adding its own signature, the existing signature will be invalid.)
Your system may be changed, which may actually improve the situation further: a different digital signature scheme, which can replace the digital signature scheme you are using now, is a linear signature. This means: After getting two private keys (nothing but two numbers), signing the same message for each message, and then adding the resulting signature (that is, two very large numbers) together, the result It happens to be the sum of the two public keys associated with the corresponding correct signature and the two initial private keys.
This sounds complicated, but the meaning is simple: when CoinJoining, Alice and Carol can add their respective signatures, and then only broadcast the sum, and everyone can verify against the sum of their public keys. As we said, since the signature is the heaviest part of the transaction, the possibility of only broadcasting one instead of multiple broadcasting will save a lot of resources. External observers will eventually suspect that every transaction is CoinJoin, because many users may pursue efficiency improvements. This assumption will break most forensic heuristics.
Even without further improvements, the UTXO model has improved scalability in some way: unlike the state changes in the account model, it can effectively batch and parallelize verification.
So far, you have learned:
- You can use digital signatures to delegate ownership;
- You can use the script system to convert transactions into programmable smart contracts;
- A more complex paradigm called CoinJoin can further increase the darkness and scale.
However, since your users can issue sats and transfer them in a completely decentralized manner, how can they ensure that they follow a single chronology and thus avoid double-spending attacks or attempt to modify the inflation schedule?
Source CSDN
