Convince me that SegWit is necessary

[BitcoinBarrel]

I haven't heard one good reason to upgrade to SegWit. Just a bunch of nonsense about the network not being able to scale. Seems to be scaling just fine to me....

Is the whole network going to crash if there is a million unconfirmed transactions? I don't think so.

Where did all the SegWit supporters come from all of a sudden? Many users registering in the last month all of a sudden know everything about why Bitcoin needs SegWit.

[achow101]

Segwit fixes transaction malleability, which means that a transaction composed entirely of segwit inputs will have only 1 txid. This makes it easier for services to track deposit transactions because then there is no need to actively watch for any malleated transations and track those as well. Those malleated transactions would be considered a double spend and ordinarily rejected.

Segwit also makes sighashing[1] a linear operation instead of quadratic with a new algorithm. This reduces the effect of a large transaction taking a long time to verify. Note that such a large transaction has happened before. A transaction was created a few months ago that was 1 MB in size. It was created by a miner and included in the miner's next block, i.e. not broadcast until confirmed. This transaction took ~30 seconds to confirm, which, in computer time, is an incredibly long time.

Segwit makes hardware wallets to their jobs better. The new segwit sighashing algorithm includes the value of the output being spent from so hardware wallets can easily verify whether the transaction that it is signing is valid. This helps with further verification done by the wallet itself prior to signing the transaction.

For the full list of what segwit does and its benefits, see https://bitcoincore.org/en/2016/01/26/segwit-benefits/


[1] Sighashing is the process where all of the transaction details are prepared and then hashed. The hash is then signed and the signature goes into the transaction.

[BitcoinBarrel]

What's wrong with a rejected transaction due to double-spend?

It's only happened to me 3-5 times in over 3 years after thousands upon thousands of transactions. And usually it is because I am impatient and I broadcast a new transaction before downloading the entire blockchain.

In regards to malleability that is such a non-issue that it does not warrant switching Bitcoin into a completely new Altcoin "SegWit"

When you complicate things even more that are "highly technical" you end up with more issues like "malleability" that compound problems later.

Bitcoin is working just fine, who is to say SegWit does not open the door for other problems that you people who think you are smarter than Satoshi fail to foresee...

[achow101]

What's wrong with a rejected transaction due to double-spend?

It's only happened to me 3-5 times in over 3 years after thousands upon thousands of transactions. And usually it is because I am impatient and I broadcast a new transaction before downloading the entire blockchain.

The issue is that there are two or more transactions, and the service is only watching one of them because it only knows about that, the malleated ones are rejected. If a malleated version of that transaction confirms, the service does not know about that because it does not see the original non-malleated one in the blockchain and does not credit any deposit even though the Bitcoin has been sent and confirmed.

Additionally, when a transaction is malleated, you actually run into an issue with wallets. Most wallets allow you to spend unconfirmed change because it is reasonably sure that the unconfirmed transaction to be spent from is trustworthy and will confirm, because you are the one that sent it. A lot of wallets do that. The problem happens when you go to spend, and you end up spending from unconfirmed change. If the original transaction is malleated and then the malleated transaction confirmed, whatever transaction you just created is now invalid and the recipient now will not receive any Bitcoin, and if they spent from that unconfirmed transaction, then neither will anyone else down the chain.

This case with the wallets is an issue and is hard to deal with when writing wallet software. This has happened to me a few times when people were malleating every single transaction they received and broadcasting those.

When you complicate things even more that are "highly technical" you end up with more issues like "malleability" that compound problems later.

Compound what problems?

Bitcoin is working just fine, who is to say SegWit does not open the door for other problems that you people who think you are smarter than Satoshi fail to foresee...

Satoshi failed to foresee a lot of things. Satoshi is not a god and all knowing creator that we should worship. We should not just take what he gave us and use only that, we should fix things that we see are broken and iterate on and improve what he gave us.

[piotr_n]

It is not necessary.
But would surely be more useful than e.g. the payment protocol.

[moonpie45]

What is it about malleability that is such a big problem? In the almost 7 years of Bitcoin's existence, I am only aware of two "companies" that have claimed to have been negatively affected by malleability, and I believe both of them are/were lying (I know for sure that at least one of them is lying).

I would think that a more common sense fix to the sighashing "problem" would be to limit the number of SigOps allowed in a transaction, as I do not think there are many "business reasons" why any given transaction would ever need to have a large number of SigOps.

[Swisscoinex]

What is it about malleability that is such a big problem? In the almost 7 years of Bitcoin's existence, I am only aware of two "companies" that have claimed to have been negatively affected by malleability, and I believe both of them are/were lying (I know for sure that at least one of them is lying).

I would think that a more common sense fix to the sighashing "problem" would be to limit the number of SigOps allowed in a transaction, as I do not think there are many "business reasons" why any given transaction would ever need to have a large number of SigOps.

Malleability is an issue for off-chain scaling solutions such as the Lightning Network.

[moonpie45]

What is it about malleability that is such a big problem? In the almost 7 years of Bitcoin's existence, I am only aware of two "companies" that have claimed to have been negatively affected by malleability, and I believe both of them are/were lying (I know for sure that at least one of them is lying).

I would think that a more common sense fix to the sighashing "problem" would be to limit the number of SigOps allowed in a transaction, as I do not think there are many "business reasons" why any given transaction would ever need to have a large number of SigOps.

Malleability is an issue for off-chain scaling solutions such as the Lightning Network.

I understand that, but that is not how SegWit is being "sold" to Bitcoin users! What achow101 et al is saying is that SegWit is fixing his horrible malleability "problem" and will help Bitcoin scale with a defacto block size increase (via a discount in how much space SegWit signatures take up), but are leaving out the fact that LN/thunder cannot function without SegWit.

[achow101]

I understand that, but that is not how SegWit is being "sold" to Bitcoin users! What achow101 et al is saying is that SegWit is fixing his horrible malleability "problem" and will help Bitcoin scale with a defacto block size increase (via a discount in how much space SegWit signatures take up), but are leaving out the fact that LN/thunder cannot function without SegWit.

LN can function without segwit. It is just a lot more complicated and has a few more failure scenarios. With segwit, its implementation is much simpler.

[moonpie45]

I understand that, but that is not how SegWit is being "sold" to Bitcoin users! What achow101 et al is saying is that SegWit is fixing his horrible malleability "problem" and will help Bitcoin scale with a defacto block size increase (via a discount in how much space SegWit signatures take up), but are leaving out the fact that LN/thunder cannot function without SegWit.

LN can function without segwit. It is just a lot more complicated and has a few more failure scenarios. With segwit, its implementation is much simpler.

If there are failure scenarios then I don't think it will work very well, nor do I think many people will be willing to even give it a try.

[achow101]

If there are failure scenarios then I don't think it will work very well, nor do I think many people will be willing to even give it a try.

There are failure scenarios in everything. Not having segwit for LN introduces a few more possibilities for failure (if coded improperly) than without segwit. Not having segwit requires more complexity and thus a higher possibility of a bug.

[moonpie45]

If there are failure scenarios then I don't think it will work very well, nor do I think many people will be willing to even give it a try.

There are failure scenarios in everything. Not having segwit for LN introduces a few more possibilities for failure (if coded improperly) than without segwit. Not having segwit requires more complexity and thus a higher possibility of a bug.

I have thought about this, and I cannot think of a way that LN can work without malleability being removed from Bitcoin, and without additional forks of any kind, and meeting the criteria of the ability to have instant, trustless, two-way transfers. If you want to explain how LN might work, then be my guest.

From a technical perspective, in a vacuum, LN should work once malleability is removed, assuming a client can be programmed in a way that it cannot be tricked into signing transactions "out of order". From an economical perceptive, I am not so sure for a couple of reasons.

[BitcoinBarrel]

Here's my position, if Bitcoin is not good enough As-Is then why don't you all get together and create a better Alt-Coin?

Oh that's right you can't. So if you can't create a better Alt Coin then why screw up Bitcoin?

[shorena]

What is it about malleability that is such a big problem?
-snip-

depends on what you consider big -> https://bitcointalk.org/index.php?topic=1198032.0

[moonpie45]

What is it about malleability that is such a big problem?
-snip-

depends on what you consider big -> https://bitcointalk.org/index.php?topic=1198032.0

In pretty much all cases, this was nothing more than a nuisance to end users. I have not read any reports of any entities losing money as a result of that attack (some may have lost potential revenue as a result of not being able to accept 0 confirmation transactions, but I would not consider that in the scope of 'losing money as a result of that attack')

Subsequent to that 'attack' the majority of nodes have been "programmed" to not relay high s-value signature transactions, so malleability has more or less been fixed for the end-user. The only way that I am aware that a high s-value signature transaction to get confirmed is for a miner to accept such transaction directly and the only type of business that remains vulnerable to malleability are gambling establishments that allow for on-chain gambling (businesses that tentatively accept 0-confirmation transactions can ignore transactions in which there is an unconfirmed input to the funding transaction in order to prevent fraud). 

[shorena]

What is it about malleability that is such a big problem?
-snip-

depends on what you consider big -> https://bitcointalk.org/index.php?topic=1198032.0

In pretty much all cases, this was nothing more than a nuisance to end users. I have not read any reports of any entities losing money as a result of that attack (some may have lost potential revenue as a result of not being able to accept 0 confirmation transactions, but I would not consider that in the scope of 'losing money as a result of that attack')

Same as the "spam attacks", yet somehow a lot of people think we need to do something about that in order to advance bitcoin.

Subsequent to that 'attack' the majority of nodes have been "programmed" to not relay high s-value signature transactions, so malleability has more or less been fixed for the end-user.

No, its not fixed. We just ignore all transactions. This causes issues for users using old software.

The only way that I am aware that a high s-value signature transaction to get confirmed is for a miner to accept such transaction directly and the only type of business that remains vulnerable to malleability are gambling establishments that allow for on-chain gambling (businesses that tentatively accept 0-confirmation transactions can ignore transactions in which there is an unconfirmed input to the funding transaction in order to prevent fraud). 

Its working, yes. Is that the metric here?

[moonpie45]

What is it about malleability that is such a big problem?
-snip-

depends on what you consider big -> https://bitcointalk.org/index.php?topic=1198032.0

In pretty much all cases, this was nothing more than a nuisance to end users. I have not read any reports of any entities losing money as a result of that attack (some may have lost potential revenue as a result of not being able to accept 0 confirmation transactions, but I would not consider that in the scope of 'losing money as a result of that attack')

Same as the "spam attacks", yet somehow a lot of people think we need to do something about that in order to advance bitcoin.

The spam attacks cause everyone to pay more to get their transaction confirmed. If the max block size were increased then the cost of these spam attacks would grow exponentially, and the effectiveness of these transactions to decline. 

Subsequent to that 'attack' the majority of nodes have been "programmed" to not relay high s-value signature transactions, so malleability has more or less been fixed for the end-user.

No, its not fixed. We just ignore all transactions. This causes issues for users using old software.

You can say the same thing about every soft fork. However users of non-full-node wallets should receive notification that their transactions have been rejected, which should hopefully get them to upgrade. Full node users tend to be more active in upgrading, however they can view their transactions (or that their transactions have been rejected) on one of many block explorers, which might get them to upgrade in addition to the warning message to upgrade.

Non-upgraded users will probably not receive high s-value signature transactions because other upgraded nodes they are connected to will not rebroadcast such transactions, and because the overwhelming percentage of users will not even attempt to broadcast such transactions.

The only way that I am aware that a high s-value signature transaction to get confirmed is for a miner to accept such transaction directly and the only type of business that remains vulnerable to malleability are gambling establishments that allow for on-chain gambling (businesses that tentatively accept 0-confirmation transactions can ignore transactions in which there is an unconfirmed input to the funding transaction in order to prevent fraud). 

Its working, yes. Is that the metric here?

I am not sure what you are saying here? I am trying to describe the small number of businesses that are affected by malleability under current node rules.

[shorena]

-snip-
The spam attacks cause everyone to pay more to get their transaction confirmed. If the max block size were increased then the cost of these spam attacks would grow exponentially, and the effectiveness of these transactions to decline. 

A mere inconvenience, same as having to wait for a confirmation in order to make sure you can trust the input. Both have a cost, one in time, the other in coins.

-snip-
No, its not fixed. We just ignore all transactions. This causes issues for users using old software.

You can say the same thing about every soft fork. However users of non-full-node wallets should receive notification that their transactions have been rejected, which should hopefully get them to upgrade.

They get messages alright, usually the message gives them no indication what to do though. You can blame that on bad error messages, its still a problem.

Full node users tend to be more active in upgrading, however they can view their transactions (or that their transactions have been rejected) on one of many block explorers, which might get them to upgrade in addition to the warning message to upgrade.

38% are currently running the latest version -> https://bitnodes.21.co/dashboard/?days=90

Old data are not shown (or only as other) so I cant say how long it exactly took until the network had upgraded to the mellability quick fix, but thats all it is. Im not inclined to believe that node operators are not more active in upgrading, unless you can show me data to support that statement.

-snip-
I am not sure what you are saying here? I am trying to describe the small number of businesses that are affected by malleability under current node rules.

SegWit is not needed, its not necessary, Bitcoin would still exist and work without it. SegWit however properly fixes a long term problem that keeps coming back and is currently crudely fixed. It also offeres many opportunities for a larger number of different transaction types. The increase in transactions per block doesnt hurt either.

[Jet Cash]

Bitcoin is expanding because it is a fantastic payment system, but it does not have the ability to become the dominant world payment system. There would be too many transactions for it to handle. It is the most sophisticated payment sytem in my opinion, and it has the potential to become even more sophisticated. SegWit allows it to incorporate these changes, and to keep the blockchain manageable. For this reason alone, I think SegWit is desirable, the other advantages are icing on the cake.

[stdset]

I have thought about this, and I cannot think of a way that LN can work without malleability being removed from Bitcoin

Take a look at this (not just quote, but whole post):

Code:

TX1:
0) Pays 3x: (Alice + HA1 after T1) or (Bob after T1 + T2) or (2 of 2 Alice + Bob) 
1) Pays x: (HB1 + Alice) or (2 of 2 Alice + Bob)
2) Pays x: (HA1 + Bob) or (2 of 2 Alice + Bob)
3) Pays 3x: (Bob + HB1 after T1) or (Alice after T1 + T2) or (2 of 2 Alice + Bob)
4) Pays Alice's change: (Alice)
5) Pays Bob's change: (Bob)

or at this discussion:

Frankly, I don't understand, how channels of indefinite duration could be created without SegWit or SIGHASH_NOINPUT or another possible patch, which makes txid independent on signatures. Explanation appreciated.