Topic: Convince me that SegWit is necessary - page 2. (Read 2204 times)

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.

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.

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

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.

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

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.

Compound what problems?

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.

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

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.

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.