Bitcoin System Scaling FAQ

What new technologies are included in the roadmap and when are they expected to be available?

The following technologies are mentioned in the roadmap and are expected to be completed in the following time after sufficient testing.

* The dates with an asterisk are the estimated time for code completion. Code will only be published after sufficient review, and soft forks also take time to complete. (BIP66 took several months to take effect in July 2015, while BIP65 took only five weeks to take effect in December 2015)

1. Segregated Witness Testnet: A separate testnet that is not part of the normal testnet. It allows Bitcoin Core developers and wallet developers to test Segregated Witness functionality.

2. Libsecp256k1 verification: Improves transaction verification speed by five to seven times on x86_64 hardware. Helps new nodes join the network and reduces the burden on existing nodes.

3. OP_CHECKSEQUENCEVERIFY: Allows bidirectional payment channels to be used indefinitely, increasing efficiency by 25 times.

4. VersionBits: Allows 1 to 29 soft forks to be implemented simultaneously, making the system upgrade process faster and more decentralized.

5. Segregated Witness: allows transaction capacity to increase by 1.75 to 4 times, solves third-party scalability to make smart contracts more secure, improves the efficiency of two-way payment channels by 66%, provides fraud proofs so that lightweight nodes can also execute system rules, and makes it easier to upgrade the script system to allow more powerful contract functions.

6. IBLT and weak blocks: By only increasing the total bandwidth slightly, the bandwidth required for block propagation can be reduced by more than 90%, allowing miners to traditionally send blocks in the shortest time and bring the benefits of the Bitcoin broadcast network to all full nodes. IBLT and weak blocks can make the bandwidth required by full nodes more even, making it safer to increase block capacity in the future.

I’ve heard different theories that SegWit can increase the block size to 4MB, 2MB, or 1.75MB. What is that exactly?

The current proposal is to implement segregated witness via a soft fork and count each byte of witness content as 0.25 bytes, so the maximum block size will be slightly less than 4MB.

However, blocks are not supposed to have only witness content, and there is no discount when calculating the size of non-witness content, so a 4MB size is not possible.

According to calculations by Anthony Towns, if a block is filled with standard single-signature P2PKH transactions, the size is about 1.6MB; if it is a 2-of-2 multi-signature transaction, the size is about 2.0MB.

Segregated Witness seems very complicated. Are all aspects of the Bitcoin ecosystem ready?

Some ideas are easier said than done, while others are easier said than done. Segregated Witness seems to be the latter.

Since Segregated Witness can be implemented gradually without breaking compatibility, no special preparation is required for each part of the ecosystem. Developers can get practical experience and test their software on the testnet launched in December 2015.

Initially, only miners who wish to support SegWit will need to upgrade to make the new rules available on the mainnet. Existing applications will only need to change if they want to use the new features.

Segregated witness transactions charge lower transaction fees, have better performance, and support multi-signature smart contracts, such as two-way payment channels, which can make a large number of transactions without making additional records on the blockchain. We strongly recommend wallet upgrades, but even if you do not upgrade, existing wallets can still continue to work normally.

I still find SegWit complicated, why not simply increase the block size?

There is a line of code in Bitcoin Core that specifies that the maximum block size is 1,000,000 bytes (1MB). The easiest way is to use a hard fork to change this line of code, for example to 2,000,000 bytes (2MB).

But the hard fork itself is far from simple:

1. We have no experience: Miners, merchants, developers, and users have no experience with hard forks, so the technology that makes hard forks safe to implement is untested. Soft forks are different. Soft forks were initially managed by Satoshi Nakamoto, and then we learned from the problems encountered in implementing BIP16, which led to an improved method for implementing BIP34, and later BIP66 and 65. In future soft forks, we are preparing to use BIP9 version bits to allow multiple soft fork proposals to proceed simultaneously.

2. Forced upgrade: A hard fork requires all full nodes to upgrade, and anyone using an old version of the node may lose money, including not only the operator of the full node wallet itself, but also the lightweight wallet that relies on the full node to provide data.

3. Other changes are needed: Even if you only change one line of code to increase the maximum block size, it will affect other code in the system, some of which are even adverse. For example, it is now possible to create a transaction of nearly 1MB, and it takes more than 30 seconds for a modern computer to verify the transaction (such a transaction already exists on the blockchain). With a 2MB block, verifying a 2MB transaction will take 10 minutes, which will become a very dangerous attack method. In order to avoid such attacks, it is necessary to change other code.

Despite the above problems, as long as there is sufficient preparation, hard forks will not be fatal, and we also expect hard forks in the future. However, segregated witness can be completed with soft forks that we are more familiar with, and it brings more benefits besides increasing transaction volume.

Segregated Witness requires more changes at different software levels than simply increasing block size. But if we really want Bitcoin to scale, we need fundamental changes anyway, and Segregated Witness can gradually encourage people to upgrade to a more scalable solution without forcing them to do so.

Developers, miners, and the community are already experienced with soft forks, and we believe that implementing SegWit will take no longer than a hard fork to increase capacity and will be safer.

Will there be a hard fork before SegWit is implemented? Will the SegWit proposal itself include a hard fork?

No, this is not part of the roadmap.

If a hard fork is going to happen eventually, why not do it now?

Using a soft fork with broad consensus, we can scale the system without the side effects of a hard fork, so even if a hard fork is expected, it is not a good reason to do it now.

In addition to providing additional transaction capacity, the improvements mentioned in the roadmap, combined with other technologies such as two-way payment channels, can allow users to reduce the use of blockchain, thereby increasing the capacity of the Bitcoin system in disguise without increasing the bandwidth used by full nodes. For example:

1. BIP68 and BIP112 allow for indefinite bidirectional payment channels, which can significantly reduce the number of transactions recorded on the blockchain.

2. Segregated Witness allows new payment channels to be opened while closing them, reducing the blockchain space required to change channels by approximately 66%.

3. Segregated Witness allows for easier soft fork changes to Bitcoin’s scripting language in the future, such as extracting public keys from signatures, or using merged Schnorr signatures, thereby reducing the average size of transactions.

4. After the implementation of Segregated Witness, a very concise fraud proof can be generated when an invalid block appears, which will make the security of lightweight nodes performing simple transaction verification (SPV) closer to that of full nodes, allowing the entire network to operate with fewer full nodes.

The actual effects of these technologies are still unknown, but implementing a soft fork with broad consensus will allow us to gain immediate benefits and measure medium-term possibilities, and use this data for long-term planning.

How will wallets use SegWit?

Wallets that currently support P2SH can migrate to full SegWit in two phases:

1. Phase 1: The script needs to be hashed twice, first to 256 bits and then to 160 bits. This 160-bit hash is compatible with existing P2SH addresses, so upgraded wallets can send and receive money from existing wallets.

2. Phase 2: Scripts only need one hash operation to become 256 bits. This format is incompatible with existing wallets, but allows more efficient use of block space and provides stronger anti-collision attack performance.

If no one is forced to upgrade, why would anyone upgrade? I heard that it took almost two years for P2SH to be widely used.

In a Segregated Witness transaction, each byte of the witness portion is counted as only 0.25 bytes, which means that the transaction fee for this part is discounted by 75%, but only for Segregated Witness users.

David Harding provides the following table to estimate the savings for different fees and transaction types. For example, if a common 250-byte transaction costs $0.01, spending a P2PK-in-P2SH output with SegWit can save about $0.003.

(The fee amounts are for reference only. We do not expect transaction fees to reach the highest levels shown in the table above.)

Web wallets and exchanges that charge a fixed fee (e.g., free or 1% of transaction volume) will be the first to adopt Segregated Witness, because even if the savings per transaction are small, they can add up to a significant amount over thousands of transactions per day.

I heard that you will make zero confirmation unusable. Which technology is this on the roadmap?

No. As a default setting in the current Bitcoin Core version, after receiving an unconfirmed transaction, no other transactions with the same input will be accepted. Some people think this means that the first transaction they see is safe, but it is not; if that were true, we would not need a blockchain at all.

Under the current default settings, people cannot update their unconfirmed transactions. In the original version of Bitcoin, there was actually a way for users to indicate that they wanted their transactions to be updated, but Satoshi Nakamoto turned this off in 2010 to prevent denial of service attacks.

Recently, Bitcoin Core developers discovered that the denial of service attack can be prevented by requiring users to pay more fees to update transactions, so they reopened the mechanism that allowed transactions to be replaced by Satoshi Nakamoto. This feature will be launched in Bitcoin Core 0.12.0 in January or February 2016, but like Satoshi Nakamoto's original design, only users who want to be able to replace transactions need to choose to use a wallet that supports this feature.

Currently, no wallet provides this feature, but in the future, such wallets will be able to merge multiple unconfirmed transactions to reduce the required blockchain space, and will also allow users to increase the fees for unconfirmed transactions so that transactions will not be "blocked" in the wallet due to insufficient previous payments.

In the roadmap, weak blocks and IBLT are only listed as being completed in 2016. Do you not know when they will be completed?

Weak blocks and IBLT are two technologies that are still under research and require appropriate parameters to be selected, but due to the limited number of developers involved, it is difficult to estimate when they can be launched.

Both weak blocks and IBLT involve network improvements rather than soft or hard forks, so they will only require a short testing period before they can be rolled out to allow nodes to upgrade, which we hope to complete within 2016.

After introducing weak blocks and IBLT, we can use a simple and non-contentious soft fork to standardize the transaction order and make them more efficient. This soft fork can be introduced through BIP9 versionBits.

“If SegWit doesn’t reduce the bandwidth, storage, and processing time used by miners, why would they support it?”

In fact, most of the previous soft forks did not bring these benefits to miners, for example:

| BIP16 (P2SH) | New transaction type| | BIP30 (Duplicate Transaction ID) | Require duplicate transaction ID check | | BIP34 (Record block height in Coinbase) | Reduce coinbase space available to miners by 4 bytes| | BIP65 (OP_CLTV) | New script command|

The BIP66 (strict DER signing) soft fork officially implemented in July 2015 allowed us to switch to libsecp256k1 for transaction verification, which greatly reduced the verification time and benefited miners.

Segregated Witness can bring the following benefits to its users:

This permanently solves third-party scalability issues, enables multi-stage smart contracts, reduces transaction fees, and makes it easier for Bitcoin scripts to upgrade and wallets to gain new features.

Through previous soft forks and communications, such as the Miner Panel at the Hong Kong Bitcoin Scaling Conference, miners have repeatedly expressed their desire for Bitcoin to be the most usable system possible, even if they may not directly benefit from it. Segregated Witness and other improvements on the roadmap could significantly increase Bitcoin’s usability.

Additionally, Segregated Witness allows miners to include more transactions in a block, thereby increasing the revenue they receive in each block.

How can I help?

First read the Bitcoin Core Contributors page on Bitcoin.org. Code review is an extremely important part of implementing a soft fork.

If you want more advice on how to contribute, join the discussion in the #bitcoin-dev IRC channel.

Original: https://github.com/jl2012/bitcoin.org/blob/capacity-increases/zh_CN/bitcoin-core/capacity-increases-faq.md
Translation: jl2012