SegWit is a waste of disk space?

[kano]

So ... I'm wondering why we should put up with an increase in the amount of disk space required for segwit for the same number of transactions?

Why do we NEED segwit?

Simply increasing the block size will have the same effect without making individual transactions bigger.
segwit makes individual transactions bigger.

Now the only argument I've seen given for this is that if you ignore the segwit data you can run a smaller blockchain.

However, if instead you run a pruned blockchain it will be smaller, so I see the segwit excuse as FUD.

More so, saying you don't need the segwit data is the equivalent of saying SPV mining is OK.

As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit?

Anyone got some answers that doesn't skip over and ignore these issues?

[gmaxwell]

segwit makes individual transactions bigger.

It does not. (unless you want to count a byte or two from flagging in particular serialization which could simply be compressed out, if anyone cares).

You should read the FAQ: https://bitcoincore.org/en/2016/01/26/segwit-benefits/

Key advantages include solving malleability, facilitating safe script upgrades, lowering resource usage for lite clients, allowing additional capacity without significant additional UTXO bloat risk (in fact, it largely corrects the issue that creating additional UTXO is significantly cheaper than cleaning them up). In doing so it significantly reduces some of the risk points in increased capacity.

saying you don't need the segwit data is the equivalent of saying SPV mining is OK

The network consists of more than just miners, segwit doesn't change the data miners need. Allowing a continuum of options in using the network is important for avoiding some users being 'priced out' by the operating cost of it.

As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit?

Segwit is the only proper solution for malleability. The only other alternative is long lists of canonical encoding rules-- a mess of bandaids which, at best, only solve it for a subset of transaction types-- and even then maybe not (it's very hard to be sure that a set of canonical encoding rules is actually sufficient to guarantee non-malleability). That kind of patchy approach is a huge pile of technical debt that would make it much harder to implement and maintain the consensus code in Bitcoin implementations.

[amaclin]

Why do we NEED segwit?

We do not need either segwit or any other technology.
We need profit.
Nobody knows how to make profit from bitcoin, so they are listening "gurus".

Segwit is the only proper solution for malleability.

Why do we need solution for the thing what is not a problem? 

[gmaxwell]

We need profit.

Pump at all costs altcoins are ----> over there.

Why do we need solution for the thing what is not a problem? 

It's a problem for some things and not others. The fact that whatever you're doing might not be bothered by it isn't a reason that it shouldn't be fixed for others that care about it.

[amaclin]

We need profit.

Pump at all costs altcoins are ----> over there.

Do you mean something like Black Wednesday?
Sooner or later there will be something similar here.

[unamis76]

We don't NEED SegWit, we need something that can make us scale properly.

SegWit is being proposed and supported because it is a conservative approach.

SegWit is not a waste of disk space, as far as I could see, it is instead a way of rearranging the "house", organising furniture in order to have more space, speaking figuratively.

As for the rest, gmaxwell said pretty much everything.

[Lauda]

We don't NEED SegWit, we need something that can make us scale properly.

Your statement is contradictory. LN will make the network scale 'properly'. LN requires Segwit, therefore we need Segwit.
OP it seems like you've read some false information somewhere. There are certain places that you should stay away from.

[TPTB_need_war]

Segwit is the only proper solution for malleability.

Technical reference please so I can verify?

[smooth]

Segwit is the only proper solution for malleability

There is some confusion between the concept of not including the signature in the txid and the particular package of changes that is being done in Core that does this and more but is also commonly called sigwit.

[Fatman3001]

We don't NEED SegWit, we need something that can make us scale properly.

Your statement is contradictory. LN will make the network scale 'properly'. LN requires Segwit, therefore we need Segwit.
OP it seems like you've read some false information somewhere. There are certain places that you should stay away from.

I'd love to hear kanos view on LN.

Maybe he could explain it in a way that doesn't result in a loose bowel.

[mookid]

We don't NEED SegWit, we need something that can make us scale properly.

SegWit is being proposed and supported because it is a conservative approach.

SegWit is not a waste of disk space, as far as I could see, it is instead a way of rearranging the "house", organising furniture in order to have more space, speaking figuratively.

As for the rest, gmaxwell said pretty much everything.

I think you were severely misled. SegWit was necessary, I for one, despite the fact that the Bitcoin's scale problem was left unresolved for so long, I mean, IPv6 was underworks 20 years before IPv4 addresses ran out.
Sure, creating a consensus is hard when you have a decentralized network, but let's be honest, miners will jump on everything you throw at them (if it's beneficial).
I have confidence in the developers to go through this, and I hope the community is mature enough to support the good decisions and commits that the core developers surely are going to push.

[beastmodeBiscuitGravy]

Lightning needs segwit, simple as that.

The time for complaining about it has passed. Waiting to observe the functionality, proliferation, and acceptance of the LN hub model is the only course of action now.

Astute miners realize that this topology is likely to result in on-chain fees increasing by 100x per tx. A small price to pay for uncensorable highly-decentralized settlement that you can’t get anywhere else.

[Itoo]

Segwit is the only proper solution for malleability

There is some confusion between the concept of not including the signature in the txid and the particular package of changes that is being done in Core that does this and more but is also commonly called sigwit.

Now I need a sigwit :-P

sorry I couldn't resist

[johnyj]

21 inc's LN has been out for months, it seems no one cares, so there is no market demand, if there is slightest market demand, 21inc's LN would be used at least to a degree, but no, I don't think average users would use prepaid model, and institutions would not trust a third party to handle their settlement

[Luke-Jr]

21 inc's LN has been out for months, it seems no one cares, so there is no market demand, if there is slightest market demand, 21inc's LN would be used at least to a degree, but no, I don't think average users would use prepaid model, and institutions would not trust a third party to handle their settlement

Lightning doesn't have trusted third parties, so if "21Inc's LN" does, it isn't Lightning.

[Jet Cash]

In my uneducated view SegWit is brilliant. Not only does it solve the blocksize problem in the short term, but it allows for a whole range of enhancements that will allow Bitcoin to become an intelligent programmable payment service that is independant of the fraudulent current banking system.

[Lauda]

In my uneducated view SegWit is brilliant. Not only does it solve the blocksize problem in the short term, but it allows for a whole range of enhancements that will allow Bitcoin to become an intelligent programmable payment service that is independant of the fraudulent current banking system.

Your 'uneducated' view is correct, which is quite unusual (as people tend to spread false information). Segwit does come with quite a few benefits, the added capacity increase is just a bonus. It should be (hopefully) merged soon.

Lightning doesn't have trusted third parties, so if "21Inc's LN" does, it isn't Lightning.

He has been spreading that piece of miss information for quite some time now even though several people have pointed out (on several occasions) that it is false.

[simonbtc]

As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit?

Fair question as the signature malleability issue is quite simple to fix.

When hashing the transaction data to generate a txid, simply skip over the signature data.  Everything else stays the same.  

Deployment and activation would be via a hard fork set at a certain block height.

[achow101]

As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit?

Fair question as it's simple to implement.

When hashing the transaction data to generate a txid, simply skip over the signature data.  Everything else stays the same. 

Deployment and activation would be via a hard fork set at a certain block height.

This has been discussed before albeit in another thread.

So what happens with transactions that are unconfirmed when that happens? Sure the idea of it sounds simple, but deploying such a hard fork would be a major clusterfuck.

[gmaxwell]

When hashing the transaction data to generate a txid, simply skip over the signature data.  Everything else stays the same.  

You still must have the block commit to the signature, or otherwise the signatures use in the network can be changed. (e.g. I could go add 200 GB to the size of the chain I give you by adding a megabyte of padding to the signatures in the first 200k blocks).  You also need all transaction relay to be changed to be in terms of a new ID which is the hash of the whole transaction, not the txid. (Otherwise I can take a transaction, corrupt the signature, and relay it to everyone fast to block the real transaction from the network.)

And when you've done that, tada you have segwit (specifically, you get the _exact_ construction that was used in elements alpha).  But a version of it with a ugly construction that requires every Bitcoin speaking program to upgrade _simultaneously_, and invalidates any pre-created nlocktimed transactions which _will_ confiscate some amount of users' Bitcoins (because some parties have been signing payments then destroying private keys as a time-lock-safe mechanism).

So what happens with transactions that are unconfirmed when that happens? Sure the idea of it sounds simple, but deploying such a hard fork would be a major clusterfuck.

Exactly, thats why we were unable to go forward with the original segwit design that we used in elements alpha: It's nearly impossible to deploy. The improved design is just simply better and a big part of that-- though far from all of it-- is that it's actually deployable.