So, voting on core’s implementation of Segwit is now enabled, and all 3 of the miners that support core have already cast their vote (2 pools and 1 cloud mining MLM), totalling about 23% of the network. Adoption seems to have stalled (as of 4Dec16) as the rest of the undecided vote remain undecided. Perfect time for an analysis breakdown of segwit, the good, the bad, and the ugly.Segwit has been called a ‘much needed upgrade’ to the network by core proponents, which has a somewhat jury-rigged way of expanding the effective block size of a block. (to 1.7mb)
Let’s first cut through all the marketing jazz and spin that people supporting Blockstream want to put on it and evaluate it on its technical merits alone, addressing its first its pros, then its cons.
First, though, let’s review what segwit does (generally)
- It removes the signatures (witness) from the inputs of a txn, instead putting it into a special ‘extension’ section of the block. Where the signature used to be, it will just put a dummy empty string ”.
- It’s outputs are marked as ‘anyone can spend’. Which means non-upgraded miners can technically try to steal the coins in any segwit txn. This is why they need 95% support of the miners to agree not to do this. (by running segwit enabled clients)
- It gives a discount to witness data, it gets a 75% discount in the fees/byte calculation. This is the ‘fudge’ to get effectively more txns in the same 1mb blocks.
Now for the good stuff, the Pros:
Segwit fixes the malleability issue. Well, it does in the same way fumigating your house will kill that pesky mosquito that has been irritating you all night. There is no malleability issue anymore if there is no signatures in the inputs anymore.
Segwit fixes the sighash quadratic hashing problem, by changing the way the hash of the signatures is generated.
Now the Cons, or the stuff they won’t tell you:
Non-upgraded wallets will not be able to receive txs from a segwit wallet. If someone with a segwit wallet tries to send you money, you will not see that txn until after a miner has confirmed it in a block. This essentially breaks 0-conf payments for all wallets which do not wish to upgrade to segwit.
Non-upgraded full nodes may get invalid blocks because they will not be able to verify the txns with segwit inputs. This means more block reorgs, or potential double spend attacks if the full node is serving a web wallet.
Complicated new payment types may cause bugs in poorly written wallets. Segwit wallets need to be smart about how they handles sending to upgraded and non-upgraded wallets alike. If they make a mistake, funds can be lost.
Segwit actually lowers fees collected for miners**. Miners will still use the same bandwidth as a 1.7mb block (as there actually is 1.7mb worth of data to be downloaded!), but only be paid 0.25x on the excess witness data, effectively getting paid the same as a 1mb block worth of data. Segwit sacrifices txn fees in order to get more txn/s throughput on the network. Compare this to the normal expectation of increase txn/s leading to increase in txn fees*** for a normal block limit increase.
Segwit grows technical debt. The idea of shoehorning the merkel root of the signatures into the coinbase message is a cludge made just so that segwit could be deployed as a soft-fork. How many kludges do we want to put into the Bitcoin base layer? Are we going to make soft-forks (and thus kludges) the normal practice? I don’t see anyone benefitting from this beside developers who can demand larger and larger commissions for their advice, which may someday be nothing more than knowing where all the kludges are.
Segwit cannot be rolled back because to unupgraded clients, a segwit txn looks to pay anyone (technically, anyone can spend the outputs). After activation, if segwit is rolled back via voluntary downgrade of a majority of miners software, then all funds locked in segwit outputs can be taken by unscrupulous miners. As more funds gets locked up in segwit outputs, the incentive for miners to collude to claim them grows. Compare this to a block limit increase hardfork, which can be rolled back by a block limit decreasing softfork.
Segwit doesn’t actually increase the blocksize, it just counts blocksize differently giving a discount for the segregated witness data. That means normal non-segwit txns will not be discounted. This also means that the effective block size increase can only be realized if everyone on bitcoin used segwit-style transactions exclusively. Given its adoption is hard to predict, its actual txns processing capability increase can be anything between 1x to 2x what it currently is. This is why I call the segwit block size increase more of a pseudo increase.
Segwit doesn’t actually fix malleability bug or quadratic hashing, for outputs which are not segwit outputs. Yes, this means that as long as there are non-segwit outputs in the blockchain (for instance, long untouched coins like Satoshi Nakamoto’s) these problems will still be exploitable on the network. Much like the pseudo block size increase, segwit actually does not deliver unless the whole network upgrades, and also converts their non-segwit coins into segwit coins. If you combine this with the previous notion that as more coins are put into segwit outputs, the perverse incentive for a collusion of miners to steal them becomes greater and I’m not so sure that a fully segwit enabled network would have its incentives balanced in the way they are now. For instance, presently the danger of a 51% miner collusion is just the danger that txn can be censored, or that a miner can double spend their own txn. There is nothing that a 51% cartel can do to steal your bitcoins. But if everyone was using segwit, then that actually becomes a reality.
So, now you got the details. Will you upgrade to it? Or will you opt for simpler solutions?
** Actually a segwit activation without a solid coded plan for block limit hardfork expansion (like Bitcoin Unlimited’s emergent consensus block limit setting) is nothing more than the staging step for 2nd layer Lightning networks which will shift tx fees away from miners, and given them to payment hubs instead, changing the economic model of Bitcoin forever.
*** A large footnote on fees — Detractors to increasing the block limit claim that a full mempool is important to keep a competitive fee market working in order to raise fee revenue for miners. They claim that an unlimited block size will mean empty mempools, theoretical infinite capacity, and thus zero fees. This is not really the case, fees will stay low or close to zero yes, but this will grow the network size, and when the network efficient block limit is reached (tempered by orphan rate risks) a fee market will still emerge to help prioritize txns. A full mempool can be thought of as a ‘peak load’ operating state of an electrical grid, where power users will need to pay premiums. But the ‘normal state’ of the network should be mostly empty mempools and low fees in order to continually grow the network size and user base. Bitcoin has been operating under this economic regime from 2009-2015, and showed no evidence of being ‘broken’ under it.