Introduction to Blockchain | Re-understanding BTC Time Chain, Mining Rewards and OTC Trading

Source: Blockchain Base Camp

Editor's Note: The original title was "Re-understanding the Concepts of BTC Time Chain, Mining Rewards and OTC"

Based on the use of digital signatures and the CoinJoin paradigm, this article will explore the concepts of Bitcoin's unique time sequence, mining fees, and OTC transactions.

This is an important question, because it proves that the introduction of the so-called "blockchain technology" is reasonable. This is an expression that is obviously abused. In its original meaning, it was only for a unique time sequence The answer is labeled. (Interestingly, in this regard, Satoshi Nakamoto himself refers to this structure as a "time chain," which is the term we will use here).

Back to our little story, let's try to understand what problem it solves. You design a digital cash system in which issuance and ownership are decentralized, cleverly combining puzzles and signatures.

But how do we prevent users from spending the same UTXO twice? If a dishonest user Carol transfers sat to an address controlled by Daniel, and then signs another transaction, retransmitting the same sat to an address controlled by her, which transaction will the network perform? From the point of view of the signature and script chain, they will both be "valid" and both will point to a valid initial release with the correct PoW difficulty.

In your previous e-gold experiment, your trusted timestamp server easily solved both of these issues. But now there is no central server, so who defines the unique chronological order of events?

If the network can vote in some way, a democratic consensus can be reached on this. But while the voting process works in a system with a fixed number of known participants (commonly referred to as a "confederation"), it does not work in a dynamic collection of unknown anonymous participants.

You can't simply use "nodes" as a proxy for voting rights, because each user can "pretend" millions of different nodes in a "Sybil attack". You need another way of "resisting Sybil attacks" to push all nodes to find (and maintain) consensus in a single, consistent, and unchanged history.

Unfortunately, mathematically based determinism and final solutions are theoretically impossible. But statistical and asymptotic solutions based on economics are actually feasible, and you are smart enough to find it. This is an idea: every time a miner tries to solve the PoW puzzle, they should include a timely snapshot of the current transaction timeline in the message!

They shouldn't just pass the release message, they should pass more complex pieces of information through a hash function, each block containing a solution (along with the release message, the timestamp, and the random number needed to solve the puzzle on the correct difficulty). The previous block (a block discovered by other miners about 10 minutes ago) and a list of recent transactions made by other users.

Containing a transaction block that was already contained in a previous block is considered invalid. Blocks with timestamps that are significantly incompatible with the previous timestamp are also released.

Using this technique, all participants are motivated to aggregate to a consistent version of the same time series. Minnie may include a valid transaction that contradicts a previously confirmed transaction (double spend), or change the timestamp to trick the difficulty adjustment, but then other nodes will reject such transactions, thereby wasting the value of the new issue and wasting time And energy.

Miners spend money to solve problems, so at least in some cases, they only follow the system's internal economic incentive mechanism, and can assume that they want to enjoy the relevant rewards, and it is quite safe to create blocks that will not be rejected .

02 mining costs

Although this solution is excellent, it still lacks a mechanism to motivate miners to participate in other people's transactions. They may just choose to save the computational power needed for verification scripts and signatures (although they do not have the computational power required for hash collisions, but they are still relevant), but still include their valid issuance in other empty blocks and publish them.

In addition, due to the control of the supply model, the reduction in the number of sats allowed in such distributions will reduce (even discount on the increase in sat's purchasing power) the incentive to resolve obstacles, eventually being completely cancelled at the end of the last era and will not Inflation.

You can solve this problem by introducing mining fees: users can add a small extra fee to the transaction to motivate miners to include them.

It works like this: The system allows miners to include their reward transactions, as well as issue new “mined” sat (compatible with the current era), all valid transactions created and included in the block are also included Sat balance between consumed UTXOs. The fee never depends on the transaction volume, but only on the transaction size (script complexity, number of signatures, etc.) and the required priority within the block.

03 scalability (and durability) issues

The minimum mining fee required for transactions contained in a block varies according to the supply and demand of "block space". On the supply side, the number of transactions that can be added to the time chain is limited by the maximum block size (less than 4 megabytes per block) and the maximum block rate (approximately one every 10 minutes).

On the demand side, each user has different constraints and preferences (some users can wait more time to pay less, some users can pay more to reduce waiting time, and some users have excellent Some wallets with dynamic cost estimation are not used). Generally speaking, increased demand for block space will imply an increase in mining fees.

This obviously limits the scalability of the system (especially, since miner fees have nothing to do with the amount of value transferred, we can say that it actually reduces severability).

In general, using a time chain also means that every node in the network must always listen to everything: every transaction on the chain must be downloaded and verified by each participant who will use the entire history of the system , Even after a long time. Such a system is obviously not scalable. It also lacks durability because everyone must keep a copy of every transaction forever, so any form of forensic analysis and deanonymization attempt can be performed.

For some users, things can look better, but at the cost of creating another more "privileged" user category. For example, if you increase the size and frequency of blocks, the supply of block space increases and its price decreases. However, the cost of running nodes (the ability to independently verify the validity of transactions and blocks) has grown much faster than the aforementioned supply, thereby centralizing the topology of the entire system.

Of course, a new specialized node can be provided as a kind of "signed message" to non-verified low-level users, thereby providing them with some guarantee of transaction effectiveness. After all, money was introduced to delegate the expensive task of validating precious metal coins to a few dedicated trusted entities. But, just like coinage, this strategy (known as "SPV") implies a powerful centralization with the risk of political interference or censorship by Mallory and others.

04 A new paradigm: "Off-Chain"

There is a clever way to alleviate the basic size limitations of a global consensus system without sacrificing its fragmentation. We call this the "off-chain paradigm."

The idea is simple: As long as you don't submit every transaction to a transaction block before it is absolutely necessary, you can put most of the traffic outside the public time chain (its expensive global consensus) and only use it For conflict resolution and regular resolution.

This evolution is similar to the way people use courts and contracts in the common law system: courts can create publicly binding precedents and reach some sort of "legal global consensus", but it is relatively slow and expensive, so Most transaction parties usually only sign private two-way contracts, requiring the court to verify and enforce them only in the event of a conflict or requiring regular resolution.

Advanced smart contracts can be used to minimize this "recourse" trust: Unlike actual legal systems, a decentralized time chain can avoid artificial biases and corruption, relying primarily on passwords and codes. Unlike the credit certificates discussed in a virtualized environment, off-chain transactions are not "virtual." They are practical and effective transactions, regardless of whether the parties involved are honest or not, they are very likely to be enforced by the system.

You will soon realize that this paradigm can also greatly improve the durability of the system. Rather than having all nodes permanently register all transactions, most of these transactions will only be exchanged privately between interested parties, making the forensic analysis of malicious eavesdroppers more difficult, expensive, incomplete and unreliable.

The main implementation of this strategy is an auxiliary network of pre-funded bilateral "payment channels" that can route transactions across multiple hops in an atomic manner with minimal trust. Users refer to it with a very poetic name: "Lightning Network" (the abbreviation is usually included in the label of the entire protocol suite of the system, named "LNP / BP", similar to the historical "TCP / IP") .

However, there are other smaller examples in the same paradigm. For example, there are several techniques that keep the actual script out of the required time frame, while also saving block space and privacy. (People give these technologies a lot of strange names, such as "Taproot", "Graftroot", "g * root", "Scriptless Script", etc.)

By introducing these end technologies, your users will eventually have everything they need to use the system in real life in order to recoup some of the most important currency features.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!