Bitcoin’s Segregated Witness: More Than Just Malleability Fixes and Scaling

[ebliever]

https://medium.com/@ryanshea/bitcoins-segregated-witness-more-than-just-malleability-fixes-and-scaling-241e2c9800d4

Good listing of the benefits of Segwit.

Go UASF!

[jonald_fyookball]

look, just out of curiosity:

Since activating a UASF can very likely cause a network split,
do you find it at all hypocritical that the same people who are calling for UASF
were and are against "contentious hard forks"?

[Alex.BTC]

LOL, SegWit is just like IE for Bitcoin. Overly complex, buggy, insecure, impossible to remove once installed.
 
Anyone who've looked into SegWit knows it's just a poison pill designed to give BlockStream eternal control over Bitcoin.

I have posted about it before but this time I'll just quote kiklo's post:

Segregated Witness: A Fork Too Far by Jaqen Hash’ghar
https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179

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:

    The lightning network, and/or other second-layer payment layers, may reduce on-chain transaction volume and consequently, fees
    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.

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.

 

[Alex.BTC]

look, just out of curiosity:

Since activating a UASF can very likely cause a network split,
do you find it at all hypocritical that the same people who are calling for UASF
were and are against "contentious hard forks"?

UASF is just Blockstream getting desperate and try to shove SegWit down everyone's throat using bot nets.

The only thing that is really difficult to fake is hash power. That's why Blockstream/Core are now attacking miners.

[jonald_fyookball]

I know but I'm just curious how the OP rationalizes their behavior.

[Alex.BTC]

I know you know too, actually I think it was you who posted that link first.

I am replying because OP is a well known Blockstream/Core shill.

He's trying to dupe newbies again so I have to call out on Blockstream/Core's bullshit.

[Xester]

https://medium.com/@ryanshea/bitcoins-segregated-witness-more-than-just-malleability-fixes-and-scaling-241e2c9800d4

Good listing of the benefits of Segwit.

Go UASF!

The list in that article were awesome and if it is what segwit will offer the we can be sure of a bright future in bitcoin. Fast transactions will replace the slow confirmation of transactions which is a big burden to the community. But there was one item that was missing and it was also a very important thing that we bitcoin user is looking for and that is the minimal fee, I hope that when segwit will be implemented the miner fee will also decrease.

[housebtc]

look, just out of curiosity:

Since activating a UASF can very likely cause a network split,
do you find it at all hypocritical that the same people who are calling for UASF
were and are against "contentious hard forks"?

There are many proposals been considered now, I believe the best the team will go with the best option. UASF will go forward if miners continue to hold the space ransom

[ebliever]

look, just out of curiosity:

Since activating a UASF can very likely cause a network split,
do you find it at all hypocritical that the same people who are calling for UASF
were and are against "contentious hard forks"?

I find it ironic that we are forced to it. Not hypocritical, insofar as it was no one's first choice.

[ebliever]

I know you know too, actually I think it was you who posted that link first.

I am replying because OP is a well known Blockstream/Core shill.

He's trying to dupe newbies again so I have to call out on Blockstream/Core's bullshit.

I've posted maybe 1/10 the messages here that BU folks like franky1 or jonathan f have posted in the same timeframe. If that makes me a shill for core (I'm not, just an ordinary bitcoiner with absolutely 0 ties to Blockstream or any dev), what does that make you guys? You seem to have nothing better to do than hang around this board and reddit all day posting up a storm.

Folks are encouraged to read both sides of this debate (Proverbs 18:17) and make up their own mind, because it is important for the future of Bitcoin.

I guess pretty much everyone outside your group is a shill for core - that is, for bitcoin - outside your mining cartel:
https://coin.dance/poli

[franky1]

blockstream chose to go soft. (pools only)
instead of going full wetard tantrum and do a UASF. blockstream should actually ask the abstainers/ naysayers 'why not' ..
and instead of using lengthy wordplay.. blockstream should make code changes to then address the issues and gain more functions the COMMUNITY as a whole would appreciate.

funny part.
blockstream want to just ram segwit down the communities throats no matter what. no stepping back, no second recodes. no community feedback.. just segwit or nuke

so if bip9 doesnt have adequate 85%ish pool flag by august for hopes of 95% by november. blockstream wont re-evaluate.. they will just press the squeeze button to add threats and bribes and blackmails of UASF

Why was the date of August 1, 2017 chosen?

Because BIP9 is time based, BIP148 needs to account for the possibility for some of the hash power to exit (eg. to mine another fork) which would make block intervals longer. The August 1st date allows for the economic majority to successfully activate SegWit. Theoretically, if the hashpower drops by up to 85%, it might take up to 13 weeks to complete an activation period. In this scenario, SegWit will still activate for all BIP148 compliant nodes.

..
now if UASF also fails to get segwit in.. guess what.. no backing down, no rcoding, no community review.. just make another deadline for end of 2018 and keep poking the bear with the half assed gestures of 2merkle no promise fixes verion segwit. just to delay and provoke the community.

http://www.uasf.co/

Can BIP148 be cancelled?

Yes. In the event that the economic majority does not support BIP148, users should remove software that enforces BIP148. A flag day activation for SegWit would be the next logical steps and require coordination of the community, most likely towards the end of 2018.

tl:dr;
dont expect blockstream(core) to even attempt to listen to the community by adding in any dynamic 1merkle (proper full node/pool consensus upgrade)version of segwit before 2019

[Alex.BTC]

I've posted maybe 1/10 the messages here that BU folks like franky1 or jonathan f have posted in the same timeframe. If that makes me a shill for core (I'm not, just an ordinary bitcoiner with absolutely 0 ties to Blockstream or any dev), what does that make you guys? You seem to have nothing better to do than hang around this board and reddit all day posting up a storm.

Folks are encouraged to read both sides of this debate (Proverbs 18:17) and make up their own mind, because it is important for the future of Bitcoin.

I guess pretty much everyone outside your group is a shill for core - that is, for bitcoin - outside your mining cartel:
https://coin.dance/poli

It's not your post count that makes you a shill, it's your ignorance, here is just one example:

Re: Do you support Segwit?
Yes, of course. I don't see any downside to it, and the upsides are major ones.

I just posted a bunch of reasons why SegWit is an obvious poison pill.
Yet you ignore it and go straight for framing me as 'BU folks'.
Show me one post where I sell BU, seriously, just try and find one, just one.
 
There is no debate, the evidence is clear,  Blockstream/Core are simply crooks who've taken the code hostage since 2015.
Instead of just increase the blocksize to 2M/4M and let things progress naturally, let SegWit face natural competition, Blockstream/Core used dirty tactics to force feed it to everyone.

Github commits, BIPs and mailing lists are now all under Blockstream control.

Complex trojan horses like SegWit gets merged without a hiccup,while  simple 2M increase pull request got instantly closed by Blockstream co-founder, then they locked it so the submitter couldn't even reply. Then they turn around and bullshit about 'community consensus'.

And you have similar posts-per-day as franky/jonald, how do you even come up with bullshit like 'I've posted maybe 1/10 the messages here that BU folks like franky1'.

Just try me, just quote me and reply with bullshit again, and I'll compile a long list of dirty shit Blockstream/Core have done, and every time you shill for SegWit I'll start your so called debate with it. Let's see how well you do in that debate.

Just do your job, but don't act like a smart ass when you're selling bullshit.

[scox]

And here we go again....

Too much impetus for little to none effect. This forum has seen enough of this dispute's blubberish.

[jonald_fyookball]

look, just out of curiosity:

Since activating a UASF can very likely cause a network split,
do you find it at all hypocritical that the same people who are calling for UASF
were and are against "contentious hard forks"?

I find it ironic that we are forced to it. Not hypocritical, insofar as it was no one's first choice.

You seem to be making a huge assumption that we must follow core's roadmap, no matter what, even
if the miners disagree, even if it violates principles that core has been espousing.

And you can't even admit there is ANY degree of hypocrisy.

I am not here to judge you.  But I hope you can see why some people think you're a shill...
because you are basically supporting Core no matter what, making huge assumptions like
that, and brushing all of their wrongdoings under the rug.

If you think I am mistaken, I'm here to have an honest and reasonable discussion about it,
if that's something you're interested in.  

[QuestionAuthority]

Why would anyone want to change anything with Bitcoin right now? Almost no one is spending Bitcoin. The daily transaction volume has fluctuated in the same range since October 2016 and before that it hardly went up at all for several years. The daily transactions are Asian speculators driving the price through the roof. Leave everything alone and sail this boat to profitland.

[cellard]

LOL, SegWit is just the IE for Bitcoin. Overly complex, buggy, insecure, impossible to remove once installed.
 
Anyone who've looked into SegWit knows it's just a poison pill designed to give BlockStream eternal control over Bitcoin.

I have posted about it before but this time I'll just quote kiklo's post:

Segregated Witness: A Fork Too Far by Jaqen Hash’ghar
https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179

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:

    The lightning network, and/or other second-layer payment layers, may reduce on-chain transaction volume and consequently, fees
    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.

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.

 

Wrong, segwit is opt-in, so you voluntarily use it or not. BUcoin hard fork is the one that would become impossible to uninstall. BUcoin is an instakill for bitcoin, that's why it has 0 real support and segwit gets majority support in all fields except hashrate (which is controlled by a small amount of people with incentives to block bitcoin progress)

[jonald_fyookball]

Why would anyone want to change anything with Bitcoin right now? Almost no one is spending Bitcoin. The daily transaction volume has fluctuated in the same range since October 2016 and before that it hardly went up at all for several years. The daily transactions are Asian speculators driving the price through the roof. Leave everything alone and sail this boat to profitland.

 

That is not true.  Japan is starting to use Bitcoin.  Things are picking up in Venezuala, Africa... a lot of places.  If we don't increase the capacity beyond 3TPS, then Bitcoin could lose its place to Ethereum or something else. 

[Alex.BTC]

Wrong, segwit is opt-in, so you voluntarily use it or not. BUcoin hard fork is the one that would become impossible to uninstall. BUcoin is an instakill for bitcoin, that's why it has 0 real support and segwit gets majority support in all fields except hashrate (which is controlled by a small amount of people with incentives to block bitcoin progress)

Another total noob who doesn't even understand Bitcoin, hash rate is the only thing that can't be easily faked, it's the only thing that can reliably solve the Byzantine Generals' Problem.

Your so called 'real support' can be easily bought. Any half ass Eastern European botnet operator can launch a bunch of nodes for UASF. Hell even windows script kiddies can just card a bunch of Amazon cloud and bam, another 1000 of your so call 'real support'.

Can't do that with hash rate. Even if you bribe all the universities and use all their super computers to mine Bitcoin, it'll only cause a blip in the hash rate.

Miners are what made Bitcoin a success.

Blockstream went soft fork with SegWit because they thought they could fuck over both miners and nodes at the same time, that failed, that's why they're now attacking miners and go for UASF.

They're running around like a bunch of amateurs.

[QuestionAuthority]

Why would anyone want to change anything with Bitcoin right now? Almost no one is spending Bitcoin. The daily transaction volume has fluctuated in the same range since October 2016 and before that it hardly went up at all for several years. The daily transactions are Asian speculators driving the price through the roof. Leave everything alone and sail this boat to profitland.

 

That is not true.  Japan is starting to use Bitcoin.  Things are picking up in Venezuala, Africa... a lot of places.  If we don't increase the capacity beyond 3TPS, then Bitcoin could lose its place to Ethereum or something else. 

Daily transaction volume just doesn't support what you're saying. Sure, there have been advances in the number of businesses accepting Bitcoin but the number of people using Bitcoin hasn't followed suit.

[jonald_fyookball]

Why would anyone want to change anything with Bitcoin right now? Almost no one is spending Bitcoin. The daily transaction volume has fluctuated in the same range since October 2016 and before that it hardly went up at all for several years. The daily transactions are Asian speculators driving the price through the roof. Leave everything alone and sail this boat to profitland.

 

That is not true.  Japan is starting to use Bitcoin.  Things are picking up in Venezuala, Africa... a lot of places.  If we don't increase the capacity beyond 3TPS, then Bitcoin could lose its place to Ethereum or something else. 

Daily transaction volume just doesn't support what you're saying. Sure, there have been advances in the number of businesses accepting Bitcoin but the number of people using Bitcoin hasn't followed suit.

facepalm... the volume isn't growing because we've hit the limit!  You can't put the cart before the horse.