1

After reading a lot of articles, whitepapers and videos I am still confused why do we need SegWit an Lightning instead of just bigger blocks. I don‘t want to debate Bitcoin vs Bitcoin Cash but what are the technical arguments? For a non-involved Bitcoin developer the debate is just crazy and both sides have their pros and cons but there must be technical arguments or not..?

DISCLAIMER: I do not have Bitcoin Cash but Bitcoin

  • this question has the risk of creating "opinion based" answers. On SegWit and LN: this is the scaling solution to really high throughput, whereas BitcoinCash is just pushing the can down the road. It does not solve anything at all. The limitations we see today still appear in the future, and as such prevents mass adoption. Just my view, now let's see the fantastic answers by all the experts! – pebwindkraft Dec 28 '17 at 9:41
  • Yes there are a lot opinion based answers but (maybe I am naive ) there should be some clear technical facts where the community should be able to talk about..Or maybe there is a paper/article where the technical arguments both sides are listed/described in a fair way... (fingers crossed) – 0xjacobb Dec 28 '17 at 21:09
5

After reading a lot of articles, whitepapers and videos I am still confused why do we need SegWit and Lightning instead of just bigger blocks.

It's not a question of one or another. They are all approaches to capacity increases, and I expect that in the long term, all of them will happen. However, due to the risks and tradeoffs involved some were far easier to deploy and get agreement across the ecosystem on.

SegWit is a solution to the transaction malleability problem, introduced in a way that also provided a moderate capacity increase. By design, SegWit is backward compatible - meaning that it did not require the entire ecosystem to migrate to different software.

Lightning is one proposal for a layer on top of Bitcoin that makes much more efficient use of transaction capacity, as well as giving instant transactions. Implementing Lightning became much simpler with SegWit. It only affects those who use it.

Just a block size increase is a bit underspecified, as SegWit for example was technically a block size increase too. If you mean increasing the capacity without any other changes, that is something that I expect will happen in the long term, but has multiple issues. One is that it is a hard fork, which means the degree of consensus needed for it happen without incidents across the network is much greater.

The biggest issue - and this is certainly subjective - is that it is not a solution at all to scaling. It offers a way to double the capacity of the system while making everything twice as costly (in terms of resources) for participants to validate the system's security. If we want to make Bitcoin accessible to the world, no such approach will help. Blocks could be made 2x bigger or 10x bigger, but the result is only 2x or 10x more transactions. Who cares? That does not fundamentally enable use cases that weren't otherwise possible. In my view, the part of the ecosystem that views capacity increases in this way as a necessity do so from an expectation that all transactions need to happen on the blockchain. That's just not what the technology is good for. Building layers on top is harder, and will require time, research, and money. But it may bring us a world where billions have access to a currency without third party control. In contrast, larger blocks risk setting the ecosystem on a path where its only way forward is ever increasing blocks size.

Lastly, there is the issue of immutability. Bitcoin is hard to change if people believe it is hard to change. And this on itself is an incredibly valuable property. This means people can rely on it retaining the properties they signed up for, even if potentially powerful entities would like it to change. If controversy is a reason to step away from this, it's an avenue to outside influence. This does not mean change cannot happen at all, but it must happen in a way that is cooperative, and without rush. We're in it for the long term…

  • I realize that this answer ended up being much more political than just technical reasons as OP asked. Perhaps another answer with just the technical benefits of SegWit and Lightning is useful? – Pieter Wuille Dec 28 '17 at 10:12
  • Thx for your answer! Yes a technical answer would be defenitly helpful. I agree that both sidechains and bigger blocksizes will be used on the longterm, but now I am struggeling a lot with the technical part. Especially when you find some proof-of-concepts for sidechains and for large blocksizes (1 GB), pros and cons etc. Then I am asking myself all the time: „There must be some hidden technical specifications where I should compare...“. Why should we implement SegWit and Sidechains if it is „so easy“ to implement „just bigger Blocksizes“ like Bitcoin Cash propagates... – 0xjacobb Dec 28 '17 at 12:44
  • The short answer to that is that they do different things. SegWit is primarily a fix for the malleability problem (it just happened to also permit a small increase without a hardfork). Lightning primarily gives you fast payments (but also enables many more payments than any capacity increase can achieve). – Pieter Wuille Dec 28 '17 at 12:54
  • So you mean, LN will add additional features like cross payment channels (BTC to Crypto xy) what just a blocksize increase can not do... But LN offers a similar scaling like eg 1GB blocks..correct? If correct, why do you think these cross plattform payments are needed and not just a block size increase to solve the (Bitcoin) scalability issue? – 0xjacobb Dec 28 '17 at 16:50
  • LN can do far more than that. It offers instant payments (while BTC transactions take minutes to hours to settle). It also increases capacity for some use cases by a factor that no blocksize increase can achieve (you mention 1 GB blocks, which may be theoretically possible for at a tremendous cost to anyone running a network node, while LN does it with no cost to anyone not involved in the payments). – Pieter Wuille Dec 28 '17 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.