Segregated Witness: A Fork Too Far

Introduction

This paper first examines Segregated Witness (SW), then demonstrates how it can only fail to realize its designed purpose, how it encumbers Bitcoin with irreversible technical debt, and how it threatens the fungibility of the currency. After reading this, it should be clear to miners why they should: 1) reject the activation of SW as a soft fork, and 2) attempt to negotiate a new agreement with Bitcoin Core to implement SW as a hard fork with a corresponding block size increase, or switch to implementations which support this with market-driven capacity increases.

Much of the discourse surrounding SW activation has been tainted by appeals to fear, authority, guilt, and social pressure. Miners should not be forced to implement changes to the Bitcoin protocol under these conditions. This work aims to illustrate critical shortcomings of SW to miners so that they are able to make more informed and responsible decisions regarding this highly contentious protocol change.

1. What is the Problem?

Bitcoin faces a number of challenges going forward. At the highest level, these challenges encompass transaction malleability and scaling. SW claims to solve transaction malleability, deliver a one-off increase in on-chain capacity, and lay the foundation for second layer scaling solutions. Before showing why these claims are not true, let us quickly review the problems that SW is trying to solve.

1.1 Transaction malleability

What is transaction malleability in one sentence?
Transaction malleability is the capacity to generate multiple valid transaction identifiers for a single transaction.

How does it work?
A Bitcoin transaction is comprised of the following components:

Figure 1: Bitcoin Transaction Schema (present day)

Why is this a problem?
An attacker can trick a user in the following way. Alice requires a payment from Bob, who broadcasts a transaction (txid-a). Alice detects Bob’s transaction (txid-a) and modifies it in such a way that doesn’t invalidate the signature but produces a different identifier: txid-b. Alice broadcasts txid-b to the network, where it may be received and accepted by the miners instead of txid-a. If so, Alice can then claim to Bob that the transaction never went through and ask him to send the funds again. Bob checks the blockchain for txid-a, but fails to see it in the latest block and concludes something went wrong. If Bob isn’t running a full node, and isn’t paying attention to his own wallet, he can be tricked into sending additional funds to Alice who can replay this attack again and again until Bob realises what is happening.

This is a particularly important problem to solve for the lightning network where one needs to constantly monitor the network to ensure that their counter party isn’t sneakily publishing an old channel state (in effect stealing funds that should otherwise go to you). A consistent txid would make this process much easier.

How should we fix it?
The digital signature needs to be detached or ‘segregated’ from data used to generate the txid. This means that the txid will always remain the same and cannot be modified without invalidating the digital signature, thereby neutralizing this attack vector.

1.2 Scaling

Bitcoin’s current on-chain scaling problem refers to the fact that blocks, generated every ~10 minutes, are size-constrained to a maximum size of 1 MB. As a result of this constraint, only a limited number of transactions can ‘fit’ into a block, which sets a hard limit on the on-chain transaction capacity of the payment network.

Figure 2: Historical log scale block-size

This handicap has become problematic, as the demand for on-chain transactions has grown with Bitcoin’s user-base (Figure 2). 2016 saw this limit reached repeatedly, resulting in on-chain transaction fees rising by 213% (Figure 3) and regular transaction backlogs that are becoming commonplace. These trends are expected to get worse if nothing changes. One effect of these backlogs is significant disruption to consumer-services for Bitcoin. Many of these services report receiving a considerable volume of support tickets about the same problem: transactions failing to be included in blocks.

Increasing on-chain transaction capacity goes beyond merely changing a single variable. Making such a change to the protocol requires a “fork” of the network, in which the blockchain history diverges at a given point, and the branch of the fork with the old rules is discarded in favor of the branch with the new rules.

Figure 3: Transaction fees as a percentage of block reward. We used the metric of “Transaction fees as a percentage of block reward,” and halved values post-July 2016 to account for the halving of the block reward.

Network forks can happen suddenly if some users run a version of the software with different consensus rules from the rest of the network, or they can be planned in advance to allow the entire network to upgrade their software to avoid being “forked off” from the rest of their peers. Alternative clients such as Bitcoin XT, Bitcoin Classic, and Bitcoin Unlimited have their own approaches for triggering a hard fork based on a majority of the hashing power.

Quadratic Signature Hashing
Whatever the approach may be, there is one over-shadowing problem that threatens on-chain scaling: quadratic signature hashing. To be clear, this is a problem that already exists with a 1 MB block size, but may become crippling with larger blocks.

What is the quadratic signature-hashing problem in a single sentence?
The work required to verify a transaction increases by the function O(n²) (i.e. quadratic scaling) based on the number of inputs.

Why is it a problem?
Certain transactions can be designed to include a large number of inputs or outputs that require miners and fully validating nodes to perform a significant amount of CPU-work to verify (Figure 4). For miners, this verification time can delay their work on the next block, placing them at a disadvantage. The worst case scenario would be a transaction where the verification time exceeds the 10 minute target for mining the next block. This can be used to launch a type of denial of service attack against miners and the network at large, as fully validating nodes will not propagate the block without first verifying it completely, unless they mine without validating transactions and undermine the consensus rules of the network. This attack vector is exacerbated with larger blocks, which can accommodate more or larger malicious transactions taking advantage of quadratic signature hashing.

Figure 4: Bitcoin Core’s excellent graphical summary of the problem (source).

How does it work?
If the amount of data being hashed is the same each time we perform one additional hash operation, the total hashing time would scale linearly (Table 1).

Table 1: O(n) linear scaling example

However, if the amount of data increases for each additional round of hash operations, then the total hashing time increases quadratically even though the number of hash operations has increased linearly (Table 2).

Table 2: O(n²) quadratic scaling example

In Bitcoin, each additional input calls for (at least) one additional hash operation, but each additional input also increases the overall size of the transaction and thus the amount of data to be hashed each time.

How should it be fixed?
BIP-143 changes how the data gets hashed when a signature check is performed. Specifically, the inputs are serialized and hashed (call this hash-1) and so are the outputs (call this hash-2), among other things. The data that gets hashed for each signature check is something like [hash-1, hash-2, input_metadata, some_other_tx_metadata]. Since hash-1 and hash-2 are the same size regardless of how large the transaction is, the size of the data which gets hashed for each signature check is always approximately the same size, which means linear scaling is achieved.

An alternate approach to fix the problem is described by Tom Zander. Zander’s proposed solution is to retire OP_CHECKSIG and replace it with a new version of OP_CHECKSIG (using one of the spare NOPs) that will sign the same area of the transaction used to calculate the new txid (i.e. everything minus the witness data). This design is currently under development.

It is important to note that these changes will only affect the new UTXO created after either approach is adopted, and will have no effect on the current UTXO.

2. Segregated Witness

2.1 Specification

Segregated Witness is described across five BIPs: 141, 142, 143, 144, and 145. BIP141 describes SW in general. BIP142 describes the format for native pay-to-witness-public-key-hash (P2WPKH) and pay-to-witness-script-hash (P2WSH) addresses. BIP143 goes into the detail of transaction verification in SW, and how this solves the quadratic signature hashing. BIP144 discusses the changes to the network messages as a result of SW. Finally BIP145 covers changes to the getblocktemplate JSON-RPC call for the bitcoin core client.

At the time of writing this article, an excellent video was published that gives a high-level overview of SW (Figure 5). Below, we will cover some of the finer details SW introduces in order to highlight the problems we’ve identified.

Figure 5: High-level overview of segregated witness

2.2 Standard Transactions

To understand how SW works, we need to compare and contrast it against how transactions are being done as standard today. We will examine the two major types of transaction: pay-to-public-key-hash (P2PKH) and pay-to-script (P2SH).

Figure 6: A standard P2PKH and P2SH transactions. (A) A P2PKH output from transaction-A is spent by transaction-B, creating a P2SH output that is spent by transaction-C. Transaction-B (B) and transaction-C © are verified by evaluating signatures and hashes on the stack.

P2PKH
Figure 6A shows standard input to output P2PKH and P2SH transactions. A standard unspent output contains a set of instructions in the pubkey script that, when combined with the signature script, evaluate whether the digital signatures are valid (Figure 6B-C).

The pubkey script of an unspent P2PKH output will contain:

OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

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

Figure 7: Script evaluation for P2PKH transactions

This final OP_CHECKSIG is where we encounter the root problem of quadratic signature hashing. By default, most transactions will contain inputs with a signature format, specifically a hash-type, which triggers a verification method called SIGHASH_ALL when OP_CHECKSIG is pushed to the stack.

Under SIGHASH_ALL, the transaction is copied and modified in the following way (Figure 8):

1. The signature scripts of all the inputs in the transactions are stripped out
2. For the specific input being checked, the signature script is replaced with a subscript, which is just the pubkey script of the unspent output (i.e. OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG)

Figure 8: Copy of the transaction created and double SHA256 hashed when checking the signature of an input.

This copy of the transaction is then double SHA256 hashed. This hash is what the spender has digitally signed and supplied as the <signature> in the signature script of the input. The digital signature of the hash is checked against the pubkey:

Signature check(pubkey, signature, SHA256^2[transaction])

If it passes, OP_CHECKSIG will push TRUE to the stack and the transaction will be accepted.

This process needs to be repeated for every input in the transaction, scaling the amount of work required to check signatures for every input quadratically.

This issue is not merely a theoretical one, but something that has caused problems in Bitcoin before. Block 364,422 contained one transaction (999.651 kB) with 5,569 inputs and 1 output. This one transaction required ~1.2 GB of data to be hashed for the transaction to be verified, requiring about 11–25 seconds of validation time in total!

P2SH
A P2SH transaction (more commonly associated with multisignature transactions) works a little differently, as shown in Figure 6. With a P2SH transaction, the spender supplies 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 to perform this initial check is:

OP_HASH160 <redeemScriptHash> OP_EQUAL

The redeem script is supplied in the signature script of the input (Figure 6A). Within the deserialised redeem script are a set of instructions to determine if the transaction is valid (Figure 6C).

The redeem script can take many formats, giving an interesting level of flexibility in the types of transactions that Bitcoin supports. One of the most commonly used formats are multisignature transactions:

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

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

This particular approach of validating transactions is a bit of a hack, and at the time was controversial, but it works without leaving too much technical debt in its wake. Old nodes will not perform the additional validation steps found in the redeem script, and will only check to see if the redeem script hashes to the redeem script hash in the unspent output. Incidentally the most damaging legacy of BIP16 (where P2SH was proposed) may be the precedent of accepting convenient hacks into the protocol in the name of expediency.

2.3 SW transactions

SW introduces new data fields into the transaction format: marker, flag, and witness. Both marker and flag are set to 0 and 1 respectively (which can be used for future extensions). The witness field contains serialised data that include: signatures, public keys, and witness scripts for P2SH transactions, which we will come to later. As all of the signature data is kept 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 classes of SW transactions: pay-to-witness-public-key-hash (P2WPKH) and pay-to-witness-script-hash (P2WSH), which are designed to replace P2PKH and P2SH transactions respectively. There are also two other types of SW transactions, P2SH-P2WPKH and P2SH-P2WSH, which will be used primarily (at least initially) if SW is activated. These transactions accomplish the same purpose as P2WPKH and P2WSH, but are nested inside a redeem script. We will explore the reasons why below.

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

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 (aka pubkeyHash in Figure 8). This witness program will verify the transaction according to the same operations contained in the pubkey script of a standard P2PKH transaction (Figure 6B). As the signature and pubkeys 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 was ‘deferred’, which means ordinary users and wallets need to create a P2WPKH address nested within a P2SH transaction. This means SW transactions will start with a 3, and need to be prepared and processed differently (Figure 8).

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

OP_0 <32-byte-witnessScript-hash>

where OP_0 (or 0) is the version number, and <32-byte-witnessScript-hash> is the SHA256 hash of the witness script (aka witnessScript, Figure 8C). This witness program will verify the transaction according to the instructions contained in the witness script, which is found within the witness field as the last item after the signatures and public keys.

Figure 8: Spending native P2WPKH and P2WSH outputs.

It is critical to highlight that the length of hash in the witness program determines the type of transaction and how it will be verified: P2WPKH (20-bytes) vs P2WSH (32-bytes). As with P2WPKH, there is no native address format for P2WSH, which means P2WSH needs to be nested within a P2SH transaction in order to be compatible with existing wallets (discussed further below). To be clear, it doesn’t mean one cannot make native P2WPKH or P2WSH transactions, they just lack a special address format for now.

To make P2WPKH transactions compatible with existing wallets, they must be nested within P2SH transactions (Figure 9). Firstly, instead of the signature script being empty as in straight P2WPKH and P2WSH, it contains the redeem script like any normal BIP16 P2SH transaction (Figure 6). Similarly, the pubkey script contains the following:

OP_HASH160 <redeemScriptHash> OP_EQUAL

Nodes first validate that the redeem script in the transaction is equal to the pubkey script of the unspent output (Figure 9B). If so, the redeem script is deserialised to produce the witness program:

OP_0 <20-byte-pubkey-hash>

From the witness field, the signature and pubkey are extracted and evaluated using the standard P2PKH script (Figure 9C).

Figure 9: Spending a P2SH-P2WPKH/P2WSH transaction.

Similar to P2SH-P2WPKH, the pubkey script of P2SH-P2WSH transactions contains instructions to validate that redeem script:

OP_HASH160 <redeemScriptHash> OP_EQUAL

The signature script field contains the redeem script that contains a P2WSH witness program when deserialised:

OP_0 <32-byte-witnessScript-hash>

The signatures, pubkeys, and witness script are extracted deserialised from the witness field to create the final script that is verified by upgraded nodes. Non-upgraded nodes will view P2SH-P2WPKH/P2WSH as anyone-can-spend transactions and will always consider them valid.

2.4 Where SW succeeds

When taking stock of the advantages of SW, we must keep in mind that these benefits only apply to the SW UTXO set. It relies on users creating SW outputs and adhering to the specification for any advertised benefit to be realised. With that in mind, what follows are some of the major benefits of SW.

Increases on-chain transaction capacity of Bitcoin
As the signature data is moved to the witness field, spending SW outputs occupies less space in blocks relative to spending non-SW outputs. The non-witness data counts as the base size, while the witness data is discounted when calculating the total size of a SW transaction (Figure 10). In terms of weight when calculating fees/byte of transaction data, witness data is equivalent to 25% of non-witness data. For example, it would require 400 bytes of witness data to incur the same transaction fee as 100 bytes of non-witness data.

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

Assuming that all transactions in a block are spending SW outputs, a 1 MB block will be able transmit to 1.7–2X the number of transactions relative to the standard format.

Figure 10: Transaction capacity differences between standard and SW transactions.

Eliminates transaction malleability and quadratic signature hashing
With the signature data moved to the new witness field, modifying the digital signature will no longer alter the txid of a SW transaction. With malleability fixes, second-layer systems using unconfirmed transactions such as the lightning network are more secure. SW also changes the way transaction data is hashed for signature checking so that this process scales linearly and not quadratically.

Backwards compatibility
SW adoption will be triggered after 95% of blocks over a two week period have signalled their intention to switch to the new rules. This soft fork, if activated, will be backwards compatible to non-upgraded nodes. Users who want to take advantage of the features of SW can do so at their leisure, and there is no risk of invalidating non-SW transactions. Moreover, SW lays the foundation for upgrading Bitcoin’s script language, paving the way for Schnorr signatures, as well as merkelized abstract syntax trees (MAST), both of which are exciting and welcome developments.

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

3. The Problems with Segregated Witness

While it is true that Segregated Witness offers some improvements to the Bitcoin network, we shall now examine why these benefits are not nearly enough to outweigh the dangers of deploying SW as a soft fork.

3.1 SW creates a financial incentive for bloating witness data

SW allows for a theoretical maximum block size limit of ~4 MB. However, this is only true if the entire block was occupied with transactions of a very small ‘base size’ (e.g. P2WPKH with 1 input, 1 output). In practice, based on the average transaction size today and the types of transactions made, the block size limit is expected to have a maximum limit of ~1.7 MB post-SW (Figure 10; assuming all transactions are using SW unspent outputs — a big assumption).

However, the 4 MB theoretical limit creates a key problem. Miners and full node operators need to ensure that their systems can handle the 4 MB limit, even though at best they will only be able to support ~40% of that transaction capacity. Why? Because there exists a financial incentive for malicious actors to design transactions with a small base size but large and complex witness data. This is exacerbated by the fact that witness scripts (i.e. P2SH-P2WSH or P2SH-P2WSH) will have higher script size limits that normal P2SH redeem scripts (i.e., from 520 bytes to 3,600 bytes [policy] or 10,000 bytes [consensus]). These potential problems only worsen as the block size limit is raised in the future, for example a 2 MB maximum base size creates an 8 MB adversarial case. This problem hinders scalability and makes future capacity increases more difficult.

3.2 SW fails to sufficiently address the problems it intends to solve

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

The lack of enforceability that comes with a soft fork leaves Bitcoin users and developers vulnerable to precisely the type of attacks SW is designed to prevent. While spending non-SW outputs will be comparatively more expensive than SW outputs, this remains a relatively weak disincentive for a motivated attacker.

It is also unclear what proportion of the total number of the legacy UTXO will migrate to SW outputs. Long-term holders of Bitcoin, such as Satoshi Nakamoto (presumed to be in possession of ~1 million Bitcoin), may keep their coins in non-SW outputs (although it would be a significant vote of confidence in SW by Nakamoto if they were to migrate!). This makes future soft or hard forks to Bitcoin more difficult as multiple classes of UTXOs must now be supported to prevent coins from being burned or stolen.

One key concern is that the coexistence of two UTXO types may tempt developers and miners in the future to destroy the non-SW UTXO. Some may view this as an unfounded concern, but the only reason that this is worth mentioning in this article are the comments made by influential individuals associated with Bitcoin Core: Greg Maxwell has postulated that “abandoned UTXO should be forgotten and become unspendable,” and Theymos has claimed “the very-rough consensus is that old coins should be destroyed before they are stolen to prevent disastrous monetary inflation.”

As the security properties of SW outputs are marginally better than non-SW outputs, it may serve as a sufficient rationalization for this type of punitive action.

The existence of two UTXO types with different security and economic properties also deteriorates Bitcoin’s fungibility. Miners and fully validating nodes may decide not to relay, or include in blocks, transactions that spend to one type or the other. While on one hand this is a positive step towards enforceability (i.e. soft enforceability), it is detrimental to unsophisticated Bitcoin users who have funds in old or non-upgraded wallets. Furthermore, it is completely reasonable for projects such as the lightning network to reject forming bidirectional payment channels (i.e. a multisignature P2SH address) using non-SW P2SH outputs due to the possibility of malleability. Fundamentally this means that the face-value of Bitcoin will not be economically treated the same way depending on the type of output it comes from.

It is widely understood in software development that measures which rely on the assumption of users changing their behavior to adopt better security practices are fundamentally doomed to fail; more so when the unpatched vulnerabilities are permitted to persist and grow. An example familiar to most readers would be the introduction and subsequent snail’s pace uptake of HTTPS.

3.3 SW places complex requirements on developers to comply while failing to guarantee any benefits

SW as a soft fork brings with it a mountain of irreversible technical debt, with multiple opportunities for developers to permanently cause the loss of user funds. For example, the creation of P2SH-P2WPKH or P2SH-P2WSH addresses requires the strict use of compressed pubkeys, otherwise funds can be irrevocably lost. Similarly, the use of OP_IF, OP_NOTIF, OP_CHECKSIG, and OP_CHECKMULTISIG must be carefully handled for SW transactions in order to prevent the loss of funds. It is all but certain that some future developers will cause user loss of funds due to an incomplete understanding of the intricacies of SW transaction formats.

In terms of priorities, SW is not a solution to any of the major support ticket issues that are received daily by Bitcoin businesses such as BitPay, Coinbase, Blockchain.info, etc. The activation of SW will not increase the transaction capacity of Bitcoin overnight, but only incrementally as a greater percentage of transactions spend to SW outputs. Moreover, the growing demand for on-chain transactions may very well exceed the one-off capacity increase as demonstrated by the increasing frequency of transaction backlogs.

In contrast to a basic block size increase (BBSI) from a coordinated hard fork, many wallets and SPV clients will immediately benefit from new capacity increases without the need to rewrite their own software as they must do with SW.. With a BBSI, unlike SW, there are no transaction format or signature changes required on the part of Bitcoin-using applications.

Based on previous experience with soft forks in Bitcoin, upgrades tend to roll-out within the ecosystem over some time. At the time of this writing, only 28 out of the 78 business and projects (36%) who have publicly committed to the upgrade are SW-compatible. Any capacity increase that Bitcoin businesses and users of the network desire to ease on-chain fee pressure will unlikely be felt for some time, assuming that transaction volume remains unchanged and does not continue growing. The unpredictability of this capacity increase and the growth of the non-SW UTXO are particularly troubling for Bitcoin businesses from the perspectives of user-growth and security, respectively. Conversely, a BBSI delivers an immediate and predictable capacity increase.

The voluntary nature of SW upgrades is subject to the first-mover game theory problem. With a risky upgrade that moves transaction signatures to a new witness field that is hidden to some nodes, the incentive for the rational actor is to let others take that risk first, while the rational actor sits back, waits, and watches to see if people lose funds or have problems. Moreover, the voluntary SW upgrade also suffers from the free-rider game theory problem. If others upgrade and move their data to the witness field, one can benefit even without upgrading or using SW transactions themselves. These factors further contribute to the unpredictable changes to Bitcoin’s transaction capacity and fees if SW is adopted via a soft fork.

3.4 Economic distortions and price fixing

Segregated Witness as a soft fork alters the economic incentives that regulate access to Bitcoin’s one fundamental good: block-size space. Firstly, it subsidises signature data in large/complex P2WSH transactions (i.e., at ¼ of the cost of transaction/UTXO data). However, the signatures are more expensive to validate than the UTXO, which makes this unjustifiable in terms of computational cost. The discount itself appears to have been determined arbitrarily and not for any scientific or data-backed reasoning.

Secondly, the centralized and top-down planning of one of Bitcoin’s primary economic resources, block space, further disintermediates various market forces from operating without friction. SW as a soft fork is designed to preserve the 1 MB capacity limit for on-chain transactions, which will purposely drive on-chain fees up for all users of Bitcoin. Rising transaction fees, euphemistically called a ‘fee market’, is anything but a market when one side — i.e. supply — is fixed by central economic planners (the developers) who do not pay the costs for Bitcoin’s capacity (the miners). Economic history has long taught us the results of non-market intervention in the supply of goods and services: the costs are externalised to consumers. The adoption of SW as a soft fork creates a bad precedent for further protocol changes that affirm this type of economic planning.

3.5 Soft fork risks

In this section we levy criticisms of soft forks more broadly when they affect the protocol and economic properties of Bitcoin to the extent that SW does. In this case, a soft fork reduces the security of full nodes without the consent of the node operator. The SW soft fork forces node operators either to upgrade, or to unconditionally accept the loss of security by being downgraded to a SPV node.

Non-upgraded nodes further weaken the general security of Bitcoin as a whole through the reduction of the number of fully validating nodes on the network. This is because non-upgraded nodes will only perform the initial check to see if the redeem script hash matches the pubkey script hash of the unspent output. This redeem script may contain an invalid witness program, for P2WSH transactions, that the non-upgraded node doesn’t know how to verify. This node will then blindly relay the invalid transaction across the network.

SW as a soft fork is the opposite of anti-fragile. Even if the community wants the change (i.e., an increase in transaction capacity), soft-forking to achieve these changes means that the miners become the key target of lobbying (and they already are). Soft forks are risky in this context because it becomes relatively easy to change things, which may be desirable if the feature is both minor and widely beneficial. However, it is bad in this case because the users of Bitcoin (i.e. everyone else but the miners) are not given the opportunity to consent or opt-out, despite being affected the most by such a sweeping change. This can be likened to a popular head of state who bends the rules of jurisprudence to bypass slow legal processes to “get things done.” The dangerous precedent of taking legal shortcuts is not of concern the masses until a new, less popular leader takes hold of the reigns, and by then it is too late to reverse. In contrast, activating SW via a hard fork ensures that the entire community, not just the miners, decide on changes made to the protocol. Users who unequivocally disagree with a change being made are given the clear option not to adopt the change — not so with a soft fork.

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

If any critical bugs resulting from SW are discovered down the road, bugs serious enough to contemplate rolling it back, then anyone will be able to spend native SW outputs, leading to a catastrophic loss of funds.

4. Fork in the road

Segregated Witness attempts to fix transaction malleability and lay the foundation for scaling Bitcoin through “secondary layers,” which is why SW supporters have dubbed it a ‘scaling solution.’ This immediately highlights that there are two conflicting visions of Bitcoin that need to be unpacked.

Supporters of Bitcoin Core’s scaling roadmap believe that on-chain transaction capacity should be limited in order to encourage higher transaction fees and decrease the cost of running a fully-validating node. Those who prefer prioritizing on-chain scaling believe that on-chain capacity should be increased in order to allow for more user growth, and that the domain of running fully-validating nodes will naturally transition to those with the greatest financial incentive to do so: miners, businesses, and institutions. Contrary to the claims of popular talking points, this does not compromise the decentralized and trustless nature of the Bitcoin system, and this transition was anticipated by Satoshi Nakamoto.

Figure 11: Satoshi on the equilibrium of nodes, and the consumer transition to SPV

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

Figure 12: Satoshi on the future network topology of Bitcoin

There are, as of yet, unknown factors within each of these respective visions:

1. The lightning network, and/or other second-layer payment layers, may reduce on-chain transaction volume and consequently, fees
2. The cost of running of a full node may significantly decrease with hardware, software, and bandwidth improvements

In other words, LN may reduce on-chain transaction volume to a fraction of what it is now, or the cost of running a full node with 10 GB blocks in 20 years time may be laughably trivial. Perhaps both will be true.

4.1 Fee Market vs Capacity Market

Ostensibly, those in favor of constraining the block-size at 1 MB or thereabouts are concerned with the degradation of Bitcoin’s decentralized topology. However, this is somewhat disingenuous as no one — to our knowledge — has been able to calculate a target for the minimum number of nodes required to be sufficiently ‘decentralised’. This qualitative parameter can be used as a strawman argument for rejecting any increase to the block-size, or to reject anything at all, because it is impossible to argue against. Of course, it is simultaneously impossible to argue for it.

In the absence of any empirical measures by which decentralization is defined, we must reject this argument as a reason to constrain the block-size. What appears to be the more likely justification for constraining the block-size is an attempt to maximise transaction fees collected by the miners by artificially suppressing the supply of the block-space resource.

This is at odds with a more reasonable approach of allowing the supply of on-chain transactions to be regulated by miners, a capacity market, to optimize the total transaction fees harvested in each block as a function of supply and demand. This means that marginal on-chain transaction fees can effectively decrease as volume grows over time. The price of on-chain transactions with time and competition will approach the marginal cost of supply at any given demand level.

Figure 13: Satoshi on the natural emergence of market based transaction fees (source).

Conclusion

Segregated Witness is the most radical and irresponsible protocol upgrade Bitcoin has faced in its eight year history. The push for the SW soft fork puts Bitcoin miners in a difficult and unfair position to the extent that they are pressured into enforcing a complicated and contentious change to the Bitcoin protocol, without community consensus or an honest discussion weighing the benefits against the costs. The scale of the code changes are far from trivial — nearly every part of the codebase is affected by SW.

While increasing the transaction capacity of Bitcoin has already been significantly delayed, SW represents an unprofessional and ineffective solution to both transaction malleability and scaling. As a soft fork, SW introduces more technical debt to the protocol and fundamentally fails to achieve its design purpose. As a hard fork, combined with real on-chain scaling, SW can effectively mitigate transaction malleability and quadratic signature hashing. Each of these issues are too important for the future of Bitcoin to gamble on SW as a soft fork and the permanent baggage that comes with it.

As much as the authors of this article desire transaction capacity increases, it is far better to work towards a clean technical solution to malleability and scaling than to further encumber the Bitcoin protocol with permanent technical debt.