Detailed explanation of Bitcoin Segregated Verification’s call for SW synthetic fork consensus

The Origin of “Synthetic Fork”

Bitcoin Fusion synthetic fork was not proposed by a single person, but a concept proposed by multiple people in our Chinese Bitcoin coin circle through mutual communication and improvement. This is the crystallization of the overall thought and wisdom of our entire Chinese coin circle, and it is our Chinese Bitcoin circle’s contribution to the world.

A more comprehensive early blog post is available at: Bitcoin Fusion: An optimal fork solution combining soft fork and hard fork, 2016-10-19. The following diagram can be used to understand the details:

The idea was first proposed by @江卓尔 in "【Completely End the Soft and Hard Fork Dispute】Safe Hard Fork is Soft Fork Expansion", which has the idea of ​​unifying the computing power before the hard fork. At the same time, some people have also proposed introducing a computing power difficulty bomb to prevent the party with less computing power from continuing to mine.

The specific and detailed plan was proposed by @vatten in his article "A brief introduction to the new fork plan for a safe hard fork or synthetic fork". Through communication, it was roughly confirmed that there were two steps, and the first step was to unify the computing power in the form of a soft fork. Then there was the blog post above, which introduced the name "fusion synthetic fork", or "synthetic fork" for short. A WeChat group was established for comprehensive communication (currently this Bitcoin Fusion group is a high-quality discussion and exchange group in the currency circle, and everyone is welcome to leave a message to contact and join).

The latest situation is that it is difficult to reach a full consensus on the SW soft fork (around 24% support) and the BU hard fork (around 13% support). More and more people are turning their attention to synthetic forks. Like this post by @wwkmtg, "First release of the phenomenon to see the essence, on whether (zipper effect) is a phenomenon that must be produced by decentralized projects!"   There is a core diagram, see the figure below, which is essentially the idea of ​​fusion, synthesis and bifurcation. Interestingly, the word fusion is also mentioned in the diagram. According to the communication, the poster should have never heard of fusion, synthesis and bifurcation before. It should be "great minds think alike", a consensus that coincides with each other.

Zipper effect consensus diagram

　　Combining the existing SW soft fork launched by Core and the concept of SW hard fork proposed by BU supporters, I advocate a SW synthetic fork that integrates the two: in simple terms, it is to bind an HF hard fork after the SW soft fork. This "SW+HF" is integrated. Voting in favor of SW also means voting to support the later HF, and after SW is activated, HF will automatically activate after judging that certain conditions are met. No additional activation vote is required for hard forking HF, because the vote has been passed in the first step of SW and the computing power has been unified. HF contains 2M expansion or expansion similar to BU but with an upper limit on EB, and also contains simplified SW hard fork code and deletes compatible code that is no longer needed. The so-called "judgment that certain conditions are met" is mainly to continue to confirm full computing power support and the majority of full node agreement (currently 0.13.1 SW full nodes account for more than 40%), so as to avoid a large number of nodes being invalidated and withdrawn from the network due to hard forks.

I hope everyone can reach a consensus and support the SW synthetic fork so that the expansion problem can be solved as soon as possible. In fact, this is also an extension of the idea of ​​the Hong Kong Roundtable expansion consensus.

Part 2: Misunderstandings about “Segregated Verification”

Steve Sokolowski lists 6 “technical flaws” in “Why I oppose the Segwit soft fork”

Jaqen Hash'ghar also listed 6 SW issues in 3 "Segregated Witness: As a soft fork, it will drag down Bitcoin"

The SW issues listed in the two articles overlap, and the descriptions are difficult to understand. I have summarized the following 8 points in easy-to-understand language, and explained my interpretation of the descriptions. If you have other questions about isolated verification, you can leave a message to communicate. Explain some common misunderstandings of SW.

2.1 Is SW a very complex improvement?

For details, please see the 2nd and 3rd points of Steve's article and the 3rd point of Jaqen's article. They said that SW is complex in various ways, and that upgrading and learning are difficult. They also gave a very high-sounding term "technical debt", which means that other upgrades in the future will be more difficult due to the complexity.

Segregated Witness uses five BIPs: 141, 142, 143, 144, and 145. BIP141 describes SW in general. BIP142 describes the format of the Pay to Segregated Witness Public Key Hash (P2WPKH) for Segregated Witness support and the format of the Pay to Witness Script Hash (P2WSH) for Segregated Witness support. BIP143 introduces the details of transaction verification in SW and how SW solves the quadratic signature hash. BIP144 discusses the changes to network information as a result of SW. BIP145 outlines changes to the getblocktemplate JSON-RPC call for the Bitcoin Core client.

Jaqen even uses the entire second chapter to describe the diagrams, charts, and codes, which makes it seem really complicated to people who don't understand the technology.

[Analysis] However, the fact is that as shown in the figure below, the entire Bitcoin transaction is similar to filling out a form. Just fill in the required data according to the definition. The overall format is that the input block is in front and the output block is behind. This can also be seen on the blockchain browser.

Although there are many changes in the specific details, in general, SW only moves the unlocking script in the red box in the figure below and puts it at the back, turning it into an input block, an output block, and a verification block. There are no major changes in other places. As for the specific codes described by Jaqen, they are all fixed. As long as there is a template to apply, there is no need to rewrite the code for the initial transaction. For example, for multi-signature, do you need to understand what each script means? No. Therefore, it is not very meaningful for Jaqen to draw so many complex diagrams. There may be a threshold for entry, but after giving a few specific code examples of SW transactions, it should not be difficult. Finally, this is only for developers. For ordinary users, there is no need to construct transactions by themselves. In fact, isolated verification optimizes the block structure, which is conducive to developers to use the Bitcoin blockchain more efficiently and conveniently. Click the link to learn more about the public class description of isolated verification.

2.2 SW block data occupies too much space?

In Steve's first point and Jaqen's first point, under isolated verification, transaction data is divided into: basic data and verification data. According to Jaqen, under the 1MB basic data limit, there can be a total of 4MB of transaction data at most, and the effect achieved is equivalent to a 1.7MB expansion effect. Based on this situation, he thought that if the basic data 1MB becomes 2MB in the future, then the entire transaction data may change from 4MB to 8MB at most, so he concluded that it would make it more difficult to increase capacity in the future.

[Analysis] The actual maximum usage is 4MB, but the effect is only 1.7MB, which seems a bit of a loss. But please note that this is compatible with soft forks. Although the space for verification data is "wasted", the space for precious basic data is streamlined and optimized without hard forks, thereby accommodating more transactions . In addition, the verification data is only one-time. Once it has been written into the historical blockchain, it is useless. It should be possible to clean it up in the future to save storage space. As for network bandwidth, it is actually not a big problem. Most mining pools use SPV mining, which only requires a very short block header. For ordinary complete full nodes, there is no need for mining. As long as there is a network speed that can synchronize a block in about ten minutes, the network speed and bandwidth requirements are not high. In fact, the mining industry has long agreed that as long as it does not exceed 8MB, there will be no problem, and it will not bring too much difficulty to future expansion. It is even more impossible to expand hard after SW, as some hard expanders say.

2.3 How does SW solve transaction scalability?

In Steve's 5th point and Jaqen's 2nd point, it is said that under the SW soft fork, because all transactions are not forced to be SW, non-SW outputs are still vulnerable to transaction malleability attacks. The assumption that users change their behavior to adopt better security practices is basically doomed to fail. Steve even said that solving transaction malleability attacks is "redundant", and as long as it is handled properly, malleability issues will not lead to capital losses.

[Analysis] SW is not intended to solve the problem of capital loss under transaction malleability attacks. In fact, Mentougou may not really lose coins due to this problem. It is very likely that it just takes the blame for this problem. SW solves this problem mainly to pave the way for the elegant implementation of lightning network and side chain technology . As for non-SW outputs, there are still problems with transaction malleability attacks, but these non-SW outputs are not allowed to use these lightning networks. In other words, if you use the lightning network, you must use SW output transactions, which can completely solve the problem caused by transaction malleability in the lightning network. Non-SW outputs can be converted to SW outputs after one transaction, so there should not be much difference and it will not affect the fungibility of Bitcoin.

In addition, some hard expansion supporters say that transaction ductility can be solved by other means, and there is no need to use SW. Steve mentioned BU's extremely thin blocks (probably just similar to SPV mining, which cannot be solved), Classic's flexible transactions (restructure the transaction content from the treasure), and modifying the algorithm for calculating TXID to skip signatures, etc. But I think considering compatibility, reliability and feasibility , SW should be the better of these solutions.

2.4 Almost no one will use SW to trade?

In Steve's first point and Jaqen's third point, it is said that the SW soft fork upgrade may be slow or not be carried out at all. In addition, if others upgrade and adopt SW and move their data to the witness field, saving basic data space, then even if they do not upgrade or use SW transactions, they can still benefit. Therefore, they are more willing to let others take the risk first, rather than taking action first.

[Analysis] SW trading is not all about risk and no benefits. In fact, the following question they asked themselves can answer their own doubts. Users of SW trading can save transaction fees because they can isolate and verify data and reduce basic data. Under the temptation of reduced fees, some people will naturally use SW trading. After observing that there are no problems with these transactions, more and more people will gradually use it.

2.5 Subsidize SW transaction fees?

In Steve's first point and Jaqen's fourth point, it is said that SW subsidizes a large amount of transaction fees. Some articles also say that it is equivalent to a 75% discount on SW transactions. Jaqen even said that this will change the economic incentive policy.

[Analysis] According to the above 1MB of basic data and the maximum 4MB of overall transaction data, corresponding to this 75%, or 1/4, it can be understood that since transaction fees are only charged for the basic data in this 1MB, it is equivalent to exempting the verification data of SW transactions. This reduces the overall transaction fees of SW, and the minimum reduction is only 1/4 of non-SW transactions.

It seems that the fee design is unreasonable and there are benefits for SW, but in fact it is reasonable that SW should naturally reduce the handling fee because it occupies less data in 1MB of basic data. When miners pack transactions, the 1MB of basic data is scarce. Whoever occupies less data space in 1MB with transaction data will of course have a lower handling fee. Because the signature data in SW will not occupy the 1MB of data, the SW handling fee is naturally low and reasonable. Although the SW transaction fee is low, the volume can be large, so comprehensively speaking, it will not reduce the actual total income of miners from transaction fees . For example, the space occupied by a traditional non-SW transaction can fit in the space of about 4 SW transactions at most, so 4*1/4=1 will not reduce income.

2.6 Does SW reduce the security of full nodes?

In Article 5 of Jaqen, it is said that SW will make full nodes that are unwilling to upgrade downgrade to SPV nodes and unconditionally accept security losses, thereby reducing the overall integrity of the Bitcoin network.

[Analysis] Data speaks for itself. According to the latest statistics from 21.co in the figure below, more than 40% of full nodes are running the Satoshi:0.13.1 version that supports isolated proof. The full nodes that are downgraded to SPV nodes after activating SW are just old nodes that have not been upgraded. And as SPV nodes, they can continue to send and receive Bitcoin normally without any security loss. More than 40% of SW nodes have verified new SW transactions of Bitcoin, which is enough to maintain the overall security of the Bitcoin network . In addition, this is when SW has not yet been activated. The proportion of activated nodes will continue to increase in the future. When SW reaches 95% of the blocks and is activated, I believe that the number of SW nodes will have exceeded half by then, so there will be a large number of full nodes that support SW to verify the security of SW transactions, which will not affect the security of the Bitcoin network.

2.7 Suppose SW has a critical defect that cannot be undone?

In Steve's 4th point and Jaqen's 6th point, it is said that once SW is activated, it must be kept in the Bitcoin code base forever, and it cannot be revoked even if there is a critical defect. The problem they consider is that, looking at the above figure, for the sake of compatibility, SW transactions are seen by old nodes as transactions that can be spent by anyone, which means that old nodes will lose the ability to verify SW transactions and simply accept them. SW transactions are verified by SW nodes. Therefore, it is believed that even if there is a problem with SW, it cannot be returned to the state without SW.

[Analysis] In fact, they underestimated the power of hard forks. Hard forks can do almost anything . If SW is really found to have huge defects, it is completely possible to return to the SW-free version through hard forks. Note that this is a new version without SW that is newer than SW, not the old version without SW before SW . In the new version without SW of the hard fork, the SW transactions that seem to be spendable in the old version can be uniformly recalled by the system, and then the system will provide new codes to resend and distribute to the private key holders. These tasks can be completed and implemented at the code level, and there is no need for a centralized person or team to act as an intermediary. Of course, it will not directly return to the old version without SW where everyone can spend coins. Hard forks can do anything and fix any vulnerabilities.

This issue has also been extended by some hard extension supporters to a "coin theft" attack similar to a replay attack, that is, a hard fork can be created when SW is activated. The SW transactions on the SW main chain can be replayed, so that the coins of SW transactions can be obtained on the forked chain. First of all, SW is activated at 95%. Under the threat of 51 attacks, whether 5% of the computing power can maintain the safety and survival of this hard fork is a problem. In addition, even if it survives, its price will not be very high. The replay "theft" only loses the split coins on this forked chain, and the Bitcoin on the SW main chain will always be safe and normal . It is this forked chain, not the main chain, that is affected by this replay attack. In addition, SW transactions are not mandatory. Even after SW is activated, non-SW transactions can continue to be issued. If it is really found that this hard fork chain survives at that time, then everyone just needs to temporarily not issue large SW transactions.

2.8 Would it be better to implement SW with a hard fork?

In Steve's 6th point and Jaqen's 5th point, soft forks are cowardly acts, they are a way to force changes on people that they don't want. Soft forks are bad because Bitcoin's users (i.e. people other than miners) don't have a chance to agree or opt out, even though they are the most affected by such radical changes. Hard forks allow everyone in the community to make the decision. Activating SegWit via a hard fork ensures that the entire community (not just miners) can decide on changes to the protocol.

[Analysis] This view is the last resort for hard expansion supporters to hinder SW technology. That is, they admit that SW is indeed a good thing, but it must be activated by a SW hard fork, not a SW soft fork, in order to hinder the normal advancement of SW.

Many hard fork supporters, including V Pool, Roger, Gavin, and Jiang Zhuoer, have reached a consensus that SW is indeed a good thing and have expressed no opposition, but they insist that SW must be activated through a hard fork, not a soft fork. The reasons are as follows:

1) Soft forks "cheat" old nodes, hard forks "honest"

The so-called "cheating" is actually just for compatibility, so that non-upgraded nodes can continue to access the network, but they cannot verify SW transactions and are downgraded to SPV wallets for sending and receiving coins. This should not be considered a cheat. If it is a hard fork, the so-called "honesty" is incompatibility. If it is not upgraded, these non-upgraded nodes will be directly kicked out of the Bitcoin network and cannot be used at all. Obviously, a soft fork that "cannot verify new transactions but can send and receive transactions" is better than a hard fork that "kicks out completely". In addition, there is no need to worry about SW transactions not being effectively verified, as they are verified by a large number of SW full nodes that have been upgraded to the new version.

2) Soft forks only require miner voting, hard forks require all-member voting

In fact, the miner vote originally represents the vote of the whole community, and the whole community can influence the miner vote through the community. In addition, miners can use block voting to facilitate quantitative statistics. Another advantage is that the entire community does not need to vote directly, which can avoid the loss of users who hold opposing votes. Under soft forks, even if you oppose SW, if SW is activated, your QT wallet can still be used without leaving. Under hard forks, if you oppose SW and SW is activated, then the QT wallet version that you do not support SW will no longer be usable, forcing you to either accept or leave. It is best not to cause anyone to leave due to upgrade issues.

3) Soft fork code is complex, hard SW code is simple

It is true that hard forks do not need to consider compatibility issues, and some codes can be simplified. But I think the simplification effect should not be too obvious. The soft fork implementation SW needs to be isolated and signed, and the hard fork SW also needs to be isolated and signed. In terms of the main code, it is estimated that not much code will be simplified. The core developers have creatively achieved compatibility and do not force old nodes to upgrade. This is a good thing. For example, if the document doc is upgraded to docx, the later version that supports docx can be compatible with the previous doc. Isn't this a good thing? If it is not done, it makes sense to say that it takes too much time and energy to achieve compatibility, and it is not worth doing. However, now that compatibility has been achieved, it is a bit unreasonable to delete the deliberate incompatibility.

In addition, the conclusion of these hard expansion supporters that more code means more bugs is too intuitive. This is a manifestation of ignorance of the program. Sometimes, the increase of some compatible codes is conducive to the reduction of bugs. The SW soft fork has been running on the test network for a long time, and it is unlikely that bugs will appear. Besides, bugs are not terrible, as long as there is a strong enough development team to fix them in time.

Part 3: Suggestions for the correct expansion route

3.1 Choose a better fusion synthesis fork upgrade mode

Simple changes to general software codes, such as fixing minor bugs and optimizing the interface, can be done directly through ordinary upgrades. When major changes cannot be made with fully compatible ordinary upgrades, try to use soft forks with better compatibility when soft forks can be implemented. Hard forks are divided into active hard forks for upgrades and passive hard forks for fixing major vulnerabilities. When an active hard fork must be performed, try to choose a fusion fork solution that combines the advantages of soft forks and hard forks.

The route for calling for capacity expansion can be: SW synthetic fork .

The first stage: SW soft fork , first achieve node compatibility, do not force old full nodes to upgrade, but first unify the computing power. After this stage, 100% computing power can support SW synthetic fork.

Phase 2: SW+HF hard fork , with 100% computing power support and after detecting that most of the full nodes have switched to the new version, activate the hard fork of hard expansion HF and simplified SW. At this time, the computing power and nodes are almost all supported, and the risk of splitting the coin circle is extremely small.

3.2 The activation threshold is best set to 95%

  Currently, Bitcoin upgrades generally follow the BIP9 upgrade specification, which means that it will only be activated if there is a threshold support ratio in 2016 blocks. For example, the SW isolated verification soft fork has a 95% activation threshold. For details, see: 9.6 Bitcoin block version number knowledge and upgrade specification BIP9 As long as there is a mining pool that can mine more than 5% of the blocks and disagrees, it can veto the activation of SW and maintain the status quo. According to the block situation in the past 7 days, there are as many as nine mining pools that have the veto power for this version activation, namely:

1. AntPool, 18.7%

2. F2Pool, 15.9%

3. BW.com, 10.4%

4. BTCC, Guochi, 9.2% (support SW)

5. BitFury, 8.6% (support SW)

6. ViaBTC, V Pool, 6% (support BU)

7. SlushPool, 5.5% (mainly supports SW , with a small amount of BU and Classic, etc.)

8. BTC.com, 5.3%

9. HaoBTC, 5.1%

Pay attention to some versions that do not set activation thresholds, do not follow the BIP9 upgrade specification, or have too low activation thresholds. The cryptocurrency mining industry should ignore them directly. Versions that really want to compete need to be fair and set high activation thresholds. 8.4 proposes restrictions on the BU unlimited version. There is no order without rules.

The activation threshold determines the risk of a split in the cryptocurrency world to a large extent. If a hard fork is hastily initiated at 50%, it will most likely cause a split in the cryptocurrency world. Those who support a hard fork at 50% consensus are actually very close to directly supporting a split in the cryptocurrency world.

Soft forks are compatible with full nodes and blockchains. In theory, even if they are activated with very low computing power, no forked chain will be formed. However, if they are activated with too low computing power, some people may disagree and force a hard fork at the moment of soft fork activation, causing a split. In order to avoid this, even if it is a soft fork or a synthetic fork, it is best to activate it only when there is enough computing power voting consensus.

The higher the activation threshold, the lower the possibility of causing a split in the cryptocurrency circle.

3.3 Allow enough time for voting

Fork upgrades require enough time to test and review the code, as well as to learn what has been modified. It also requires enough time to reach a consensus on whether to upgrade. In addition, users need time to upgrade the latest QT wallet and synchronize, third-party currency applications need time to develop compatible apps and push updates, and some code base compatibility tests and design updates all require time. Therefore, try to give enough time, rather than rushing.

For example, the voting for the isolated verification soft fork started on November 18, 2016, and the voting is counted every 2016 blocks, which is about two weeks. There is enough time to prepare. If you are not ready, you can vote again in the next 2016 block, the next 2016 block, etc. The longest time can be extended to the end of next year when it is possible to reach 95% support for activation. Currently, there are about 25% of blocks and more than 40% of nodes. Among the coin companies, 86 coin companies or projects have stated that they will support SW, but only 35 are ready to support it, which still needs time.

https://bitcoincore.org/en/segwit_adoption/

Segwit Ready: 35, work-in-progress: 26, planned: 25

I hope you will follow "Bite Jiang". If there are any mistakes or disagreements, please leave a message for discussion. Thank you. If you think it is good, please share it.