On the Detriments of Segregated Witness for Bitcoin
Segregated Witness has been the center of Bitcoin’s long-lasting scaling debate since it was first introduced by Blockstream co-founder and Bitcoin Core developer Dr. Pieter Wuille two months ago.
A nifty method to move signature data from typical transactions into “add-on blocks,” Segregated Witness is set to improve the Bitcoin protocol in several ways . Moreover, the solution can be rolled out as a soft fork, meaning that only miners need to upgrade their software; all other nodes can do so if and when they please.
The innovation is positioned as the first step of a scalability “roadmap ” as set out by Bitcoin Core, and is supported by a large segment of Bitcoin’s development community.
But Segregated Witness is not free of controversy. Rather than a Segregated Witness soft fork, the recently launched alternative Bitcoin implementation Bitcoin Classic plans to increase Bitcoin’s block size limit to 2 megabytes through a hard fork, meaning all full nodes on the network need to upgrade synchronously.
These are the arguments against a Segregated Witness soft fork – and their counterarguments.
It Requires ‘Ugly’ Code
A purist argument against Wuille’s proposal is that a Segregated Witness soft fork constitutes an “ugly” workaround of code. Most important, it uses parts of the miner-generated coinbase transaction for purposes they were not originally intended for. The added complexity could potentially cause new problems as the protocol keeps evolving.
The counterarguments
While most developers agree a hard fork would be a cleaner solution, this does not necessarily mean a Segregated Witness soft fork is unsafe. The Bitcoin Core development team has rolled out several similar soft forks in the past, and maintains that this one would not carry any more risk.
A hard fork, meanwhile, renders all existing full node software incompatible with newer full node software, which is, arguably, not very graceful either.
It Burdens Developers Too Much
A Segregated Witness soft fork workaround imposes an added burden on developers — both now and in the future. This is particularly true for Bitcoin library and wallet developers, as they will need to adapt their software to integrate Segregated Witness. This will require more effort than a hard fork block size increase would.
The counterargument
Most current library and wallet developers don’t seem to consider the added burden a big problem. Many are even quite excited about the innovation, and they typically consider the added benefits worth the effort. (See Bitcoin Magazine ‘s development series, as linked below in this article.)
Growth of Added Block Space Will Be Slow
Like Bitcoin Classic’s proposed hard fork, Segregated Witness theoretically offers up to 1 megabyte of added block space, for a total of 2 megabytes. But this optimal added capacity is based on multisig transactions, as these get an accounting “discount.” Yet most transactions are currently not multisig transactions. A more realistic capacity increase could therefore be closer to .6 megabytes of added space, for a total of 1.6 megabytes.
Additionally, this added space might not be fully utilized right away. It can be used only after wallets and other apps have upgraded. In reality, it could take a while before even 1.6 megabytes is reached.
And while the Segregated Witness soft fork is scheduled for April, it remains to be seen if this can be achieved. The solution requires much coding and testing before it can be rolled out, as well as approval by miners.
The counterarguments
A public testnet version of Segregated Witness – SegNet – is already available for experimention. This suggests that development is on schedule.
Many library and wallet developers, moreover, estimate that it would take anywhere between a couple of days to several weeks to integrate Segregated Witness. An April release should, therefore, provide enough time for the bulk of wallet and app software to upgrade.
As soon as Segregated Witness is activated, all wallet and app software can utilize the benefits – such as lower fees – immediately. Whether other users utilize the added space as well does not not really matter for them. (And if the added block space is not used, it might just suggest that the need for extra block space was never that great in the first place.)
It should also be noted that multisig transactions might find increasing use as innovation and development of the Bitcoin protocol progresses, because added layers on top of Bitcoin – such as payment channels and the Lightning Network – typically use such transactions. The effective capacity could, therefore, come closer to 2 megabytes later on.
And while the Bitcoin Classic team maintains that a hard fork can be rolled out before April, this is considered overtly aggressive and outright risky by many within the development community. The need for all full node operators to both review and adopt the upgrade, they think, requires at least six months to a year.
It Skews Incentives
Removal of signatures from the original 1-megabyte blocks can effectively increase Bitcoin’s block size. But Segregated Witness does introduce a new type of maximum block size. Roughly: A block without the witness, plus one quarter of the witness size, must not exceed 1 megabyte. As such, upgraded nodes will see blocks that exceed 1 megabyte, since the actual size of the Segregated Witness is larger than the quarter accounted for.
This means that multisig transactions, which include more signature data, get a greater discount. And since multisig transactions are used to establish layers on top of Bitcoin, Segregated Witness artificially skews incentives toward these added layers.
Long-term consequences of such layers – such as the effect on mining fees – are controversial.
The counterarguments
Discounting signature data is how Segregated Witness allows for added block space without requiring a hard fork. While this is indeed accomplished through an accounting measure, it is a useful one.
Additionally, witness data can be reasonably considered expendable after a certain amount of time, decreasing the need for full nodes to store it in perpetuity. It, therefore, has a lower cost to the network, making it reasonable to charge a lower fee.
Furthermore, the only way Bitcoin can reach millions of users while also remaining decentralized, secure and censorship-resistant is through the use of added layers. Incentivizing development and use of these added layers is not a bad thing.
It Doesn’t Hold Well Under Adversarial Conditions
One argument in favor of a block size limit concerns block propagation and latency. In short: Bigger blocks tend to increase orphan rates, as more miners build on old blocks while newer blocks are still making their way through the network. This, in turn, favors larger miners (or pools): They find more blocks themselves, and start building on these right away, meaning they waste fewer resources.
This also means that large miners could have an incentive to actually create artificially large blocks, specifically designed to increase the orphan rate of competitors.
The current Segregated Witness proposal allows blocks up to about 2 megabytes – though a bit less is more likely. But due to the specific accounting measure to be employed, so-called “selfish miners” could create synthetic transactions designed to stuff up to 4 megabytes of data into a single block. As such, big miners could “attack” competitors with valid 4 megabyte blocks.
Segregated Witness, therefore, requires miners and full nodes to deploy hardware with 4-megabyte safety headroom, while getting significantly less real transaction capacity in return. And if the original block size limit is increased through a hard fork at some point in the future, this risk multiplyer will probably remain.
The counterarguments
If 4 megabytes is indeed large enough to successfully pull off an attack – which is unclear – this attack would require the attacking miner to discard all real transactions. The resulting loss of fees serves as a slight disincentive to carrying out such an attack, and it would be obvious to the rest of the network that an attack is going on.
And while the risk multiplier will probably indeed remain even if a hard fork is rolled out later on, it could potentially be decreased through a soft fork as well.
It Degrades Security of Non-upgraded Nodes
A fifth concern is that a Segregated Witness soft fork would degrade the security of all non-upgraded full nodes. These nodes could still accept Segregated Witness transactions, or transactions that depend on a previous Segregated Witness transaction, but be unable to verify whether the signature data is valid. As such, they’d have to rely on validation by miners.
Unconfirmed Segregated Witness transactions would, therefore, be insecure, as these are not yet verified by miners at all.
But even confirmed Segregated Witness transactions would be less secure, as miners could purposely mine invalid transactions into blocks with the intention to double-spend non-upgraded nodes. A non-upgraded node would believe these blocks to be valid until the miners switch their hash power back to the valid chain. If a non-upgraded node accepted transactions from the invalid blocks, he might have lost money.
The costs of such a double-spend would resemble the cost of any other 51-percent-attack, but with added leverage. Attacking miners could potentially leverage hash power from “SPV-miners,” who wouldn’t know what’s going on themselves, since they don’t validate transactions either. And the attacker could leverage funds to double-spend, as he could use any Segregated Witness-protected bitcoin that never belonged to him in the first place.
The counterarguments
A Segregated Witness soft fork will be publicly announced far in advance, and transparently voted on by miners. As such, any user running a full node will have plenty of time to take the necessary precautions.
Users running a non-upgraded node should not trust zero-confirmation transactions. But zero-confirmation transactions were always unsafe. Anyone who wants to pull off a double-spend attack with unconfirmed transactions can do so with or without Segregated Witness.
The added risk of confirmed transactions, meanwhile, can be offset by waiting for some additional number of confirmations. (For exact figures of the added risks, see these calculations by Bitcoin developer Oleg Andreev.)
A user who does not want to upgrade to the newest full node status at all, furthermore, could patch his non-upgraded full node with software that flags suspicious transactions – and potentially even reject such transactions completely.
Last, it should be noted that hard forks pose a much greater risk of double-spend transactions. Any non-upgraded node could, in the case of a hard fork, receive completely invalid transactions while potentially never realizing it at all.
It Will Be Deployed without Explicit User Consent
Though arguably small, the security degradation as described above does exist. And what’s perhaps more important: This security degradation would be enforced without explicit consent from users. Even if users strongly oppose Segregated Witness, and prefer not to upgrade, a majority of miners could push the change through regardless.
This is at odds with Bitcoin’s promise of personal autonomy; the idea that operators of a full node should always have the possibility to opt-out of any change.
The counterarguments
Soft forks cannot be prevented. Miners controlling a majority of hash power can always decide to enforce new rules, as long as they do not break the existing consensus rules. This is inherent to the Bitcoin protocol, and will be possible after a hard fork just as well.
As such, users running full nodes must always bear some responsibility. Either the responsibility to upgrade to the latest version of the software, or the responsibility to wait for an added number of confirmations, or perhaps even the responsibility to not accept any transactions after a soft fork is detected.
And while it’s technically true that users don’t need to change their software after a (contentious) hard fork, and can choose to “stay behind” on the original network, this will almost certainly not be the option in practice. Besides the risk of double-spend attacks, decreased hash power could ensure that transactions never confirm – or confirm very slowly.
An alternate scenario is that the minority chain by hash power introduces its own hard fork to change the proof-of-work algorithm. Bitcoin would then split up into two separate networks, and all users would have to upgrade their software to support one of the options – or both.
Thanks to Jonathan Toomim and Ciphrex CEO, Bitcoin Core, and Segregated Witness developer Eric Lombrozo for proofreading and added feedback.
For more information on Segregated Witness, see Bitcoin Magazine’s series on the subject, or part 1, part 2, part 3, part 4, part 5, part 6, part 7 and part 8 of Bitcoin Magazine’s development series.
The post On the Detriments of Segregated Witness for Bitcoin appeared first on Bitcoin Magazine.
