Bitcoin Forum

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?

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.

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.


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.

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".

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

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

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.

Do you mean something like Black Wednesday (https://en.wikipedia.org/wiki/Black_Wednesday)?
Sooner or later there will be something similar here.

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.

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.

Technical reference please so I can verify?

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.

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.

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.

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.

Now I need a sigwit :-P

sorry I couldn't resist

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.

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.

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.

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.

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.

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).

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.

Isn't this a user problem rather than a protocol issue?  First, the protocol doesn't specify that a user must destroy their private key when creating nLockTimed transactions.  Second, since there's no guarantee that any given transaction will ever be successfully mined, it doesn't seem prudent to pre-sign transactions which sit off-chain and only become valid for broadcast and potential mining in some distant future whilst also deleting the private key.  If this destructive behaviour can be condoned, it beggars belief that zero conf transactions are considered unsafe.

While that is a user issue, it is not something that changing the protocol should mess with. If you change the protocol and you cause several users to suddenly have transactions that they just sent suddenly be invalid, you will anger many users and potentially cause them to stop using Bitcoin.

About destroying the keys, there are some companies that provide multisig addresses and a pre-signed timelocked transaction to allow users to withdraw their balance should the service suddenly go down. If the service went down and this change happened, those users would no longer be able to access their coins.