Segregated Witness: A Soft Fork That Will Drag Down Bitcoin

introduction

This article first examines Segregated Witness (SW) and demonstrates how it fails to achieve its design purpose, how it has become an irreversible technical debt that burdens Bitcoin, and how it threatens the fungibility of the currency. After reading this article, it should be clear to miners why they should: 1) refuse to activate the Segregated Witness soft fork; 2) try to negotiate with Bitcoin Core to reach a new agreement to promote the implementation of Segregated Witness as a hard fork to increase the block supply accordingly, or switch to support the implementation of the implementation that insists on a market-driven increase in the block supply.

1. What is the problem?

Bitcoin faces many challenges. At the highest level, these challenges include transaction malleability and scaling. Segregated Witness claims to solve交易延展性and enable a one-time increase in capacity and establish the foundation for second-layer scaling solutions. Before explaining why these claims are not true, let’s review the problems that Segregated Witness is trying to solve.

1.1 Transaction Scalability

What is transaction scalability in one sentence?

Transaction malleability is the ability to generate multiple valid transaction identities for a single transaction.

How does it work?

A Bitcoin transaction consists of the following components:

Figure 1: Bitcoin transaction diagram

Why is this a problem?

An attacker can trick users in the following way. Alice needs payment from Bob, and Bob broadcasts a transaction (txid-a). Alice detects Bob's transaction (txid-a) and modifies it to txid-b by invalidating the signature but producing a different identity. Alice broadcasts txid-b to the network, where it may be received and accepted by miners instead of txid-a. If so, Alice can claim to Bob that the transaction did not succeed and ask for payment again. Bob checks txid-a on the blockchain, but cannot see the latest block and concludes that something went wrong. If Bob is not running a full node and is not keeping an eye on his wallet, he can be tricked into paying Alice more funds. Alice can then replay this attack again and again until Bob realizes what is happening.

This is a particularly important problem to solve on the Lightning Network, where people need to constantly monitor the network to ensure their counterparties are not secretly publishing old channel states (effectively stealing funds that should be transferred to you). A consistent index value would make this process much easier.

How to solve it?

The digital signature needs to be separated or "isolated" from the data used to generate the index value. This means that the index value will always be the same and cannot be modified without invalidating the digital signature, thus rendering the attack ineffective.

1.2 Capacity Expansion

The current on-chain scaling problem of Bitcoin refers to the fact that the block size generated every 10 minutes is limited to a maximum of 1MB. Because of this limitation, the number of transactions that can be "included" in a block is limited, which hard limits the amount of on-chain transactions on the payment network.

This blockage has become problematic as demand for on-chain transactions has grown along with Bitcoin’s user base (Figure 2). In 2016, repeated instances of this limitation caused on-chain transaction fees to rise by 213% (Figure 3), and regular transaction backlogs have become commonplace. If nothing changes, this trend is expected to get worse. One effect of these backlogs is a significant disruption to Bitcoin’s consumer services. Many of these services report receiving a large number of customer service tickets for the same issue: transactions failing to enter blocks.

Increasing the capacity of on-chain transactions is more than just changing a single variable. Making such a change to the protocol requires a “fork” of the network, where the blockchain history diverges at a given point and the branch supporting the old rules is abandoned in favor of the branch supporting the new rules.

A network fork can happen suddenly if some users are running a different version of the protocol from other networks, or they can be planned in advance to allow the entire network to upgrade the software from other peers to avoid being forked. Competing clients such as Bitcoin XT, Bitcoin Classic, and Bitcoin Unlimited can trigger a hard fork after they have majority hashrate support.

Quadratic Signature Hashing

Whatever the approach, there is a more significant problem that threatens on-chain scalability: quadratic signature hashing. To be clear, this problem is already an issue with the 1MB block size, but could become a serious problem with larger blocks.

What is the quadratic signature hashing problem in one sentence?

The work required to verify a transaction increases by O(n²) based on the number of inputs. (e.g. quadratically)

Why is this a problem?

Certain transactions can be designed to contain a large number of inputs and outputs that require miners and full nodes to expend a lot of CPU work to verify (Figure 4). For miners, this verification time can delay their work on the next block, putting them at a disadvantage. The worst case scenario is that the verification time for a transaction exceeds the 10 minute target for mining the next block. This could be used to launch a denial of service attack against miners and the entire network, because full nodes will not propagate blocks without completing verification first, unless they mine without verifying the transaction and break the consensus rules of the network. This attack is exacerbated with larger blocks, which can accommodate more or larger malicious transactions using secondary signature hashing.

How does it work?

If the amount of data being hashed is the same each time we perform an additional hash operation, the total hashing time will increase linearly (Table 1).

However, if the amount of data per additional hash operation increases, the total hashing time will increase quadratically even if the number of hash operations increases linearly (Table 2). (Table 2)

In Bitcoin, each additional input requires (at least) one additional hashing operation, but each additional input also increases the overall size of the transaction, thus the amount of data that has to be hashed each time.

How should it be solved?

BIP-143 changes how data is hashed when performing signature checks. Specifically, the input values ​​are serialized and hashed (called hash1), and the output values ​​are serialized and hashed (called hash2). The hashed data for each signature verification is [hash-1, hash-2, input_metadata, some_other_tx_metadata]. Because hash1 and hash2 are the same size no matter how large the transaction is, the size of the data hashed each time the signature is verified is roughly the same, which means linear scaling is achieved.

Tom Zander described an alternative approach to the problem. Zander's proposed solution is to retire OP_CHECKSIG and replace it with a new version of OP_CHECKSIG (with a fallback NOP). This new version will sign the same area of ​​the transaction used to calculate a new index value (e.g.: all the data minus the proof data). This design is currently under development.

It is important to note that these changes will only affect new UTXO sets created after the two methods are adopted, and will have no effect on the current UTXO set.

2. Segregated Witness

2.1 Specifications

Segregated Witness is described using five BIPs: 141, 142, 143, 144, and 145. BIP141 describes SW in general. BIP142 describes the format of the native pay-to-witness-public-key-hash (P2WPKH) and the format of the public key address (P2WSH) that supports Segregated Witness. BIP143 introduces the details of transaction verification in SW and how SW solves the quadratic signature hash. BIP144 discusses the changes that the results of SW bring to network information. Finally, BIP145 outlines changes to the getblocktemplate JSON-RPC call for the Bitcoin Core client.

At the time of writing this article, a very nice high-level video of the SW was made public (see Figure 5). To highlight the issues we found, we present the SW in more detail below.

https://youtu.be/DzBAG2Jp4bg (Translator's note: The subtitles of the video are not yet translated and will be uploaded to youku after translation)

2.2 Standard Transactions

To understand how SW works, we need to compare it to today's standard transactions. We will examine two main transaction types: Pay to Public Key Hash ( P2PKH ) and Pay to Script ( P2SH ).

Figure 6: Standard P2PKH and P2SH transactions. (A) A P2PKH output from transaction A is consumed by transaction B, creating a P2SH output consumed by transaction C. Transaction B (B) and transaction C (C) are verified by evaluating the signature and hash on the stack.

P2PKH

Figure 6A shows a standard input to a P2PKH output and a P2SH transaction. In the pubkey script, a standard unspent output contains a set of instructions that, when combined with the signature script, evaluates whether the digital signature is valid (Figure 6B-C).

The pubkey script for an unspent P2PKH output will contain:

OP_DUP OP_HASH160 <pubeyHash> OP_EQUALVERIFY OP_CHECKSIG

In a transaction, when someone wants to spend this output, they need to provide the <signature> and <pubkey> found in the input’s signature script (Figure 6A-B), which will satisfy the pubkey script requirements. Figure 7 depicts how this output is verified on the stack when a node attempts to validate the transaction.

Figure 7: Script verification of a P2PKH transaction (word explanation in the figure, The Stack: stack; Script: script;)

The final OP_CHECKSIG is where we find the root problem of the secondary signature hash. By default, most transactions will contain inputs with signature formats, specifically hash types, and when OP_CHECKSIG is pushed to the stack, it triggers a verification method called SIGHASH_ALL.

Under SIGHASH_ALL , transactions are replicated and modified in the following way (Figure 8):

1. All input signature scripts in the transaction are deleted

2. For the specific input being checked, the signature script is replaced with asubscript which is just the Pubkey script of the unspent output (i.e. OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG)

Figure 8: Creating a copy of the transaction and calculating a double SHA256 hash when checking the signature of the input

A copy of this transaction is then double-SHA256-hashed. This hash is what the spender has digitally signed and provided as input <signature> in the signature script. Check the digital signature of the hash against the Pubkey:

检查签名（ Signature check(pubkey, signature, SHA256^2[transaction]) pubkey ，签名， ） SHA256 ^ 2 [交易] ）（译者注：原文：

If the check passes, OP_CHECKSIG will push a TRUE instruction to the stack and the transaction will be accepted.

This process needs to be repeated for every input in a transaction, adding the work of checking the quadratic signature of each input.

This problem is not just a theoretical one, but something that has caused problems in Bitcoin before. Block 364,422 contains one transaction (999.651kB) with 5,569 inputs and 1 output. That’s ~1.2 GB of data that needs to be hashed for the transaction to be verified, which takes a total of about 11-25 seconds to verify!

P2SH

P2SH transactions (more similarly to multi-signature transactions) work slightly differently, as shown in Figure 6. In a P2SH transaction, the spender provides a redeem script in the signature script that, when hashed, will match the redeem script hash in the pubkey script of the unspent output. The pubkey script that performs this initial check is:

OP_HASH160 <redeemScriptHash> OP_EQUAL

The redeem script is provided in the input signature script (Figure 6A). In the deserialized redeem script there is a set of instructions to determine if the transaction is valid (Figure 6C).

Redeem scripts can take many formats, providing a very good level of flexibility in the types of transactions supported by Bitcoin. One of the most commonly used formats is a multi-signature transaction:

 <OP_0> <signature_1> <signature_2> OP_2 <pubkey_1> <pubkey_2> <pubkey_3> OP_3 OP_CHECKMULTISIG

In this redeem script, two of the three signatures are required for the transaction to be considered valid.

This particular method of validating transactions was a bit of a hack and was controversial at the time, but it worked without leaving much technical debt. Old nodes will not perform the additional validation steps found in the redeem script, and will only check that the redeem script hashes to the redeem script hash in an unspent output. Incidentally, perhaps the most damaging legacy of BIP16 (which proposed P2SH) is the acceptance of a protocol that facilitates attacks in the name of precedent.

2.3 Segregated Witness Transactions

SW introduces new data fields into the transaction format: marker, flag, and witness. Marker and Flag are set to 0 and 1 respectively (can be used for future expansion). The witness field contains serialized data, which includes the signature, public key, and witness script of the P2SH transaction, which we will introduce later. Since all signature data is saved in the witness field and is not used to calculate the txid, the transaction is no longer malleable.

As with Bitcoin today, there are two types of SW transactions: Pay to Witness Public Key Hash (P2WPKH) and Pay to Witness Script Hash (P2WSH), which are used to replace P2PKH and P2SH transactions respectively. There are two other types of SW transactions, P2SH-P2WPKH and P2SH-P2WSH, which will be primarily used (at least initially) if SW is activated. These transactions accomplish the same purpose as P2WPKH and P2WSH, but are nested in a redeem script. We'll explore why below.

P2WP

Figure 8 shows a transaction that spends a P2WPKH output and the validation steps required for the transaction to be considered valid. Unlike normal P2PKH transactions, the pubkey script (in a P2WPKH output) contains a special instruction called a "witness program". A witness program is simply a data format that tells the SW-upgraded client to trigger a specific type of transaction validation. To activate a P2PKH transaction, the witness program needs to:

OP_0 <20-byte-pubkey-hash>

Where OP_0 (or 0) is the version number, and <20-byte-pubkey-hash> is the RIPEMD-160 hash (HASH160) of the public key (pubkeyHash in Figure 8). This witness program will verify the transaction based on the same operations contained in the Pubkey script of a standard P2PKH transaction (Figure 6B). Since the signature and pubkey are pulled from the witness field, the signature script of the transaction is left empty.

Unfortunately, the creation of a native address format for this type of transaction is “delayed”, meaning that regular users and wallets need to create P2WPKH addresses nested within P2SH transactions. This means that SW transactions will start with the number 3 and need to be prepared and processed differently (Figure 8).

Figure 8C shows a P2WSH transaction and the subsequent verification steps. The witness program in the pubkey script has the following format:

OP_0 <32-byte-witnessScript-hash>

Where OP_0 (or 0) is the version number, and <32 bytes – witnessScript-hash> is the SHA256 hash of the witness script (also known as witnessScript, Figure 8C). This proving program will verify the transaction according to the instructions contained in the witness script, which is found in the witness field as the last item after the signature and public key.

Figure 8: Spending a local P2WPKH-P2WSH output

It is important to emphasize that the length of the hash in the witness program determines the type of transaction and how it is verified: P2WPKH (20 bytes) vs P2WSH (32 bytes). Like P2WPKH, P2WSH does not have a native address format, which means that P2WSH needs to be nested in a P2SH transaction in order to be compatible with existing wallets (discussed further below). To be clear, this does not mean that native P2WPKH or P2WSH transactions cannot be made, they just lack a special address format for now.

In order for P2WPKH transactions to be compatible with existing wallets, they must be nested within a P2SH transaction (Figure 9). First, instead of the signature script being empty in write-through P2WPKH and P2WSH, it contains a redeem script similar to any normal BIP16 P2SH transaction (Figure 6). Again, the pubkey script contains the following:

OP_HASH160 <redeemScriptHash> OP_EQUAL

The node first verifies that the redemption script in the transaction is equal to the pubkey script of the unspent output (Figure 9B). If so, the redemption script is deserialized to produce the witness program:

OP_0 <20-byte-pubkey-hash>

From the witness field, the signature and public key are extracted and evaluated using a standard P2PKH script (Figure 9C)

Figure 9: Spending a P2SH-P2WPKH/P2WSH transaction

Similar to P2SH-P2WPKH, the pubkey script of a P2SH-P2WSH transaction contains instructions for verifying the redeem script:

OP_HASH160 <redeemScriptHash> OP_EQUAL

The signature script field contains the redemption script, which in turn contains the P2WSH witness program when deserialized:

OP_0 <32-byte-witnessScript-hash>

The signature, pubkey, and witness script are unpacked from the witness field to create the final script that is verified by upgraded nodes. Non-upgraded nodes will see P2SH-P2WPKH/P2WSH as an anyone-can-spend transaction and will always treat it as valid.

2.4 Aspects of SW Success

When evaluating the benefits of SW, we must remember that these benefits only apply to the SW UTXO set. It relies on the user creating the SW output and adhering to the specifications of any advertised benefit to be achieved. With this in mind, here are some of the main benefits of SW.

Increasing Bitcoin on-chain transaction capacity

Since the signature data is moved to the witness field, spending a SW output takes up less space in the block than spending a non-SW output. Only non-witness data is counted towards the base size, while witness data is discounted when calculating the total size of a SW transaction (Figure 10). When calculating the fee/byte of transaction data, witness data is equivalent to 25% of non-witness data. For example, 400 bytes of witness data would generate the same transaction fee as 100 bytes of non-witness data.

non-witness data * 4 + witness data < 4MB

Assuming all transactions in a block are spent on SW outputs, a 1MB block will be able to carry 1.7-2X the number of transactions relative to standard format transactions.

Figure 10: Transaction capacity difference between standard transactions and SW transactions

Eliminating transaction malleability and secondary signature hashing

By moving the signature data to a new witness field, modifying the digital signature will no longer change the txid of the SW transaction. With the scalability fix, second-layer systems that use unconfirmed transactions (such as the Lightning Network) are more secure. SW also changes the way transaction data is hashed for signature checking, making the process grow linearly instead of quadratically.

Backward compatibility .

SW adoption will be triggered after 95% of blocks indicate their intention to switch to the new rules, two weeks after the voting period. This soft fork, if activated, will be backwards compatible to non-upgraded nodes. Users who want to take advantage of SW functionality can do so at will, without the risk of invalidating non-SW transactions. In addition, SW lays the foundation for upgrading Bitcoin's scripting language, paving the way for Schnorr signatures, as well as merkelized abstract syntax trees (MAST), both of which are exciting and welcome advances.

A more complete list of the benefits of SW can be found on Bitcoin Core’s website.

3. Issues with Segregated Witness

While Segregated Witness does provide some improvements to the Bitcoin network, we will now examine why these advantages are not sufficient to outweigh the dangers of SW as a soft fork.

3.1 SW creates an economic incentive policy to stimulate the growth of witness data

SW theoretically allows for a maximum block size limit of about 4MB. However, this is only true if the entire block is occupied by a very small "base size" (e.g., P2WPKH with 1 input, 1 output). In practice, based on the current average transaction size and the types of transactions conducted, the block size limit is expected to have a maximum limit of 1.7MB after SW.

(Figure 10: Assuming all transactions use SW unspent outputs - a very exaggerated assumption).

However, the 4 MB theoretical limit raises a key problem. Miners and full node operators need to ensure that their systems can handle the 4 MB limit, even if they can only support about 40% of the transaction capacity at best. Why? Because malicious attackers use economic incentives to design transactions with small base data instead of large and complex witness data. The problem is exacerbated by the fact that witness scripts (i.e., P2SH-P2WSH or P2SH-P2WSH) will have a higher script size limit than normal P2SH redeem scripts (i.e., from 520 bytes to 3,600 bytes [policy] or 10,000 bytes [consensus]). These potential problems will only worsen with future increases in block size limits, e.g., a 2 MB maximum base data size would allow the creation of an 8 MB malicious block. This problem hinders scalability and makes future capacity increases more difficult.

3.2 SW failed to adequately address the problem it set out to solve

If SW is activated by a soft fork, Bitcoin will effectively have two kinds of UTXO (non-SW and SW UTXO), each with different security and economic properties. Linear signature hashes and scalability fixes can only be applied to SW UTXOs. Most seriously, there are no enforceable constraints on the growth of non-SW UTXOs. This means that the network (even upgraded nodes) is still vulnerable to transaction malleability and quadratic signature hashes of non-SW outputs that existed before the soft fork or were created after the soft fork.

The lack of enforceability of soft forks leaves Bitcoin users and developers vulnerable to the exact type of attacks that SWs prevent. While using non-SW outputs will be more expensive than SW outputs, this is still a relatively weak impediment to a motivated attacker.

It is also unclear what percentage of the total number of traditional UTXOs will migrate to SW outputs. Long-term Bitcoin holders, such as Satoshi (who hypothetically owns 1 million Bitcoins), may maintain their coins in non-SW outputs (if they move, it would be a significant vote for Satoshi against SW!). This makes future soft and hard forks of Bitcoin more difficult, as multiple categories of UTXO coins must now be prevented from being burned or stolen.

The key issue is that the coexistence of two UTXO types may tempt developers and miners to destroy non-SW UTXOs in the future. Some may think this is an unfounded concern, but it is important to point out in this article that the opinions of influential individuals in Bitcoin Core, such as Greg Maxwell, who said that "unbound UTXOs should be deleted, making them unspendable", and Theymos claimed that "the initial consensus is that old digital currency should be destroyed before it is stolen to prevent catastrophic inflation.

Since the safety characteristics of SW output are slightly better than those of non-SW output, it can serve as sufficient justification for punitive action.

The existence of two UTXO types with different security and economics also worsens Bitcoin’s fungibility. Miners and fully validating nodes can decide not to broadcast or use only one type or the other in a block. On one hand, this is a positive step towards coercion (i.e., forced soft forks), but it is a disadvantage for naive Bitcoin users who have funds in old or non-upgraded wallets. Furthermore, it is perfectly reasonable for projects such as the Lightning Network to refuse to form bidirectional payment channels (i.e., multi-signature P2SH addresses) that use non-SW P2SH outputs due to the possibility of malleability. Fundamentally, this means that depending on the output type a Bitcoin originates from, its par value will not be treated in the same way economically.

It is widely understood in software development that relying on the assumption that users will change their behavior to adopt better security practices is essentially doomed to fail, especially when patches are allowed to continue and grow. The introduction of HTTPS and the subsequent snail’s pace is an example that most readers are familiar with.

3.3 SW requires developers to comply with complex requirements without guaranteeing any benefits

As a soft fork, SW introduces a mountain of irreversible technical debt, with multiple opportunities for developers to permanently cause user funds to be lost. For example, the creation of P2SH-P2WPKH or P2SH-P2WSH addresses requires strict use of compressed public keys, otherwise funds may be irretrievably lost. Similarly, the use of OP_IF, OP_NOTIF, OP_CHECKSIG, and OP_CHECKMULTISIG must be handled carefully in SW transactions to prevent loss of funds. It is undeniable that some future developers will cause user funds to be lost due to a failure to fully understand the complexity of the SW transaction format.

In terms of priority, SW is not a solution to the major customer service tickets that Bitcoin exchanges (such as BitPay, Coinbase, Blockchain.info, etc.) receive every day. Activating SW will not suddenly increase Bitcoin's transaction capacity, but will gradually increase the transaction capacity of SW outputs as a larger percentage is used. In addition, the growing demand for on-chain transactions, as evidenced by the increasingly frequent transaction backlog, may far exceed the block supply increase cap provided by SW.

With a hard fork that directly increases the block size limit (BBSI), many wallets and SPV clients will immediately benefit from the new capacity increase without having to rewrite their own software like SW. Unlike SW, when using BBSI, no Bitcoin-using applications need to change transaction formats or signatures.

Based on experience with previous Bitcoin soft forks, upgrades tend to be rolled out over time to the ecosystem. At the time of writing, of the 78 businesses and projects that have publicly committed to upgrading, only 28 (36%) are compatible with SW. Assuming transaction volume remains constant and does not continue to grow, any capacity increase that Bitcoin transactions and network users hope to use to alleviate on-chain cost pressures is unlikely to be felt for some time. This unpredictability of increased capacity and the growth of non-SW UTXOs is particularly troubling because Bitcoin transactions are viewed from a user growth and security perspective, respectively. In contrast, BBSI provides an immediate and predictable capacity increase.

The voluntary nature of SW upgrades is affected by the game theory question of who is the first mover. Moving transaction signatures to a new witness field that is invisible to some nodes is a risky upgrade, and rational actors prefer to let others take the risk first, rather than act first and wait and see if others lose funds or encounter problems. In addition, voluntary SW upgrades are also plagued by the game theory "free rider" problem. If others upgrade and move their data to the witness field, then even if you don't upgrade or use SW transactions, you can benefit. If SW is accepted by soft fork, these factors will further lead to unpredictable transaction capacity and fees in Bitcoin.

3.4 Economic distortions and price controls

As a soft fork, Segregated Witness changes economic incentives, modifying the only economic factor in Bitcoin: the block size. First, it subsidizes the signature data of large and complex P2WSH transactions (i.e., one-quarter of the transaction cost of UTXO data). However, witnessing signatures is more expensive than UTXOs, which is not justified in terms of computational cost. The discount itself seems to be arbitrarily determined, rather than based on any scientific or data-backed reasoning.

Secondly, block space is one of Bitcoin’s main economic resources, and it is a centralized top-down plan that prevents the market’s various financial derivatives from operating frictionlessly. SW, as a soft fork, aims to maintain the 1 MB capacity limit for on-chain transactions, which will bring chain fees to all Bitcoin users. Transaction fees are rising, and the fee market is a central economic plan made by one party that does not need to bear the fees (developers), and is collected by the Bitcoin block suppliers (miners). This is called the "fee market", but it is just a market. Economic history has always told us that the result of non-market factors intervening in the supply of goods and services is that the cost is transferred to consumers. The adoption of SW as a soft fork sets a bad precedent for further protocol changes that affirm this type of economic planning.

3.5 Soft Fork Risk

This section is a broader critique of soft forks, which can sometimes have a greater impact on the Bitcoin protocol and economics than SegWit. Soft forks reduce the security of full nodes without the consent of node operators. SW soft forks force nodes to either upgrade or unconditionally accept a loss of security by downgrading to SPV nodes.

When non-upgraded nodes cause the number of full validating nodes to drop, this will reduce the overall integrity of the Bitcoin network. This is because non-upgraded nodes only perform an initial check to see if the redeem script hash matches the pubkey script hash of the unspent output. For P2WSH transactions, the redeem script may contain an invalid proof program, which the non-upgraded node does not know how to verify, and the node will then blindly continue the invalid transaction on the network.

As a soft fork, SW is fragile. While the community wants the changes (i.e., increase transaction capacity), implementing those changes via a soft fork means that miners become a key target for lobbying (and they already are). In this context, a soft fork is risky because it is easier to change things. It is desirable if the features of the change are both small and broadly beneficial. However, in this context, a soft fork is bad because Bitcoin's users (i.e., people other than miners) are not given the opportunity to agree or opt out, even though they are the most affected by such sweeping changes. It's like a popular head of state who breaks the rules of jurisprudence and bypasses strict and time-consuming legal procedures to "change the law." The masses often don't care about, and don't understand, the specifics of these changes to the law, which is very dangerous for them until a new, less popular leader comes to power, by which time it's too late to reverse the changes. In contrast, activating SegWit via a hard fork ensures that the entire community (not just miners) can decide on the changes made to the protocol. Users who clearly disagree with the change can explicitly opt out of adopting the change, rather than using a soft fork.

3.6 Once activated, SW cannot be undone and must remain in the Bitcoin codebase forever

If any critical flaws produced by the SW are discovered after some time and are serious enough to consider withdrawing it, then anyone will be able to use the output in the native SW format, which will lead to catastrophic loss of funds.

4. Fork in the road

SW attempts to fix transaction scalability and lay the foundation for Bitcoin expansion through a "second layer", which is why SW supporters call it a "scaling solution." This leads to two relatively conflicting solutions to Bitcoin's current predicament.

Those who support the Bitcoin Core scaling roadmap believe that on-chain transaction capacity should be limited to encourage higher transaction fees and reduce the cost of running a fully validating node. Those who prefer to prioritize on-chain scaling believe that on-chain capacity should be increased to allow for more user growth, and that the field of running fully validating nodes will naturally shift to those with the greatest financial incentives: miners, enterprises, and institutions. Contrary to popular talking point claims, this will not harm the decentralized and trustless nature of the Bitcoin system, and this shift is what Nakamoto Consensus intended.

Figure 11: Satoshi’s impact on the balance of nodes, and consumers’ transition to SPV

Re: Scalability

The design outlines a lightweight client that doesn’t need the full blockchain. In the design’s PDF, it’s called Simplified Payment Verification. A lightweight client can send and receive transactions, it just can’t generate blocks, it doesn’t need to trust a node to verify payments, it can still verify their own transactions.

Lightweight clients are not yet implemented, but the plan is to implement them when needed. Right now, everyone just runs a full network node.

I expect there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it to add more nodes. The rest will be lightweight clients, which could be in the millions.

When balance sizing, many nodes will be server farms with one or two network nodes feeding the rest of the farm over the LAN.

There is a very clear trade-off. By keeping the block size constant, only wealthy individuals and institutions can afford on-chain transaction fees, while any user will be able to afford the cost of running a full node. By increasing the block size, just as Satoshi predicted, any user can afford transaction fees, but only wealthy individuals or institutions can afford the cost of running a fully validating node (Figure 12).

Figure 12: Satoshi’s prediction of Bitcoin’s future network topology

Scalability and transaction rates

The current system where every user is a network node is not a large scale intended configuration. It would be like each usenet user running their own NNTP server.

This design supports letting users just be users. The more burdensome it is to run a node, the fewer nodes there will be. These fewer and fewer nodes will be large server farms. The rest will be client nodes that only do transactions and do not generate blocks.

Quote: bytemaster July 28,2010,08:59:42PM

Besides, taking 10 minutes to verify that a payment is possible is too long. It needs to be as fast as swiping a credit card today.

See the fast food machine thread where I listed how payment processors can verify payments fast enough to actually be really good (lower fraud rate than credit cards), potentially 10 seconds or less. If you don't believe me or don't want to get it, I don't have time to try to convince you, sorry.

Among these visions, there are still unknown factors:

1. Lightning Network and/or other second-layer payment layers can reduce on-chain transaction volume and therefore reduce fees

2. The cost of running a full node is likely to drop significantly as hardware, software, and bandwidth improve

In other words, LN could reduce on-chain transaction volume by a tiny fraction, or the cost of running a full node with 10GB blocks could be negligible in 20 years’ time. Perhaps both are true.

4.1 Fee Market and Block Capacity Market

On the surface, those who favor limiting block size to around 1MB are concerned about whether Bitcoin’s decentralized topology will degenerate. However, this is untrue, because according to what we know, no one can calculate the target of the minimum number of nodes required to “decentralize”. This qualitative parameter can be used as a grassroots argument to reject any increase in block size, or reject anything, because it is impossible to object. Of course, this is also impossible to agree at the same time.

Before the decentralized scenario, we lack any empirical measures and we must reject this argument as a reason to constrain block size. This is more likely to develop into artificially restricting block space resources so that miners can maximize transaction fees.

Another more reasonable option is to allow on-chain transactions to be adjusted by miners (a block capacity market) in order to optimize the total transaction fees charged for each block based on supply and demand. This means that over time and the increase in transaction volume, the marginal on-chain transaction fees can be effectively reduced. The price of on-chain transactions with time and competition will be close to the marginal cost of supply at any given level of demand.

Figure 13: Effect of Satoshi Nakamoto on naturally emerging market-based transaction fees (Source)

The total circulation will reach 21,000,000 Bitcoins. When blocks are mined, they will be distributed to various nodes in the network, and the amount will be cut in half every 4 years.

First 4 years: 10,500,000 coins

Next four years: 5,250,000 coins

Next four years: 2,625,000 coins

Next four years: 1,312,000 coins

…etc

When the amount of Bitcoin is exhausted, the system can support transaction fees as needed. It is based on open market competition, and there will probably always be nodes willing to process transactions freely.

Satoshi Nakamoto

Password mailing list

Unsubscribe by sending "Unsubscribe cryptoqraphy" to major… @ metzdowd.com

in conclusion

Quarantine Witness is the most radical and irresponsible protocol upgrade Bitcoin faces in its eight-year history. The implementation of the SW soft fork puts Bitcoin miners in a difficult and unfair position, putting them under pressure to force them to execute complex and controversial changes in the Bitcoin protocol without community consensus or an honest tradeoff. The scale of code changes is far from trivial – almost every part of the code base is affected by SW.

Although the increase in Bitcoin’s trading capabilities has been significantly delayed, SW represents an unprofessional and ineffective solution to transaction ductility and scalability. As a soft fork, SW introduces more technical liabilities to the protocol, which is simply unable to achieve its design purpose. As a hard fork, combined with true on-chain expansion, SW can effectively mitigate transaction ductility and secondary signature hash hash. Each of these problems is too important for the future of Bitcoin, and betting on SW as a soft fork will become a baggage, always tied to Bitcoin.

The author of this article hopes that cleaning technology solutions that work hard to fix ductility and scalability are better than the Bitcoin protocol with permanent technical debt.