Topic: What are segwit's benefits and overall goals? (Read 167 times)

The transaction malleability wasn't due to the failure of checking for signatures, but it segregated the signature from the actual transaction itself. This prevents the signature from being modified and thus being malleable.

It was anything but smooth. It was totally unnecessary for it to be dragged on for longer than it did. Segwit's activation requires miners to signal support for it as well and it definitely required a super majority of the miners to signal support for it to be activated. In fact, most if not all soft forks work in this manner. USAF was not materialized and it was definitely not activated by user signalling. Any forks should have consensus and majority support.

SegWit transactions enhance the security of the Bitcoin network by enforcing signature checks before any other checks.  This prevents certain types of attacks and makes the network more resistant to vulnerabilities that exploit transaction malleability. Besides, SegWit's introduction was a soft fork, meaning that it did not require a majority consensus of miners to activate.  This made the upgrade process smoother and allowed for a more gradual transition.
And here is a link for beginner to learn Segwit, hope it will be helpful.
https://blockgeeks.com/guides/what-is-segwit/

Technically transaction confirmation speed depends on the block intervals which is not changed by SegWit. What you meant to say is that SegWit increased the block capacity which then helped reduce mempool congestion hence emptying up the mempool helping txs not get stuck for long waiting for confirmation.

In raw bytes the SegWit transactions have the potential to be slightly bigger because we are adding extra bytes to the transactions containing witnesses.
If we compare a transaction spending P2PKH with P2WPKH the later has 3 extra bytes (assuming signature and public key sizes are the same):
- 2 bytes for the flag (0x0001)
- 1 byte for the witness count (0x02)

If we compare P2PKH with P2SH-P2WPKH (wrapped) then there is another additional size which is the redeem script and it is extra 22 bytes (25 bytes bigger in total).

If we only compare outputs, then a P2PKH output script is 25 bytes while P2WPKH is 22 bytes.
This means the net total size of creating P2WPKH and spending them (3 bytes less output, 3 extra input bytes) is zero.

yeah, that's the "take home" part, i.e. the noticeable effects to the user



are you sure about this? from what I remember, the hash-wrapped version of segwit and the bech32 encoded version (i.e. native) have different sizes as inputs and as outputs when compared to each other, as well as those measurements being different to those of the previous standard (compressed-key P2PKH), and that's also in terms of literal bytes, not just the witness-discounted (i.e. "virtual") bytes.

---

I'd also make a further point:

a bug existed in the design of P2PKH outputs (the old pre-segwit standard) that could cause an exponential blowup in verification time for full nodes


this had already been exploited in reality before segwit: someone sent a transaction on the main bitcoin network that despite being valid caused nodes to verify it very slowly (taking minutes where it would normally take sub-second lengths of time). Increasing the blocksize while not fixing that bug risked an effective DOS vector against the bitcoin node network. AFAIR, even today the bug is fixed only for segwit transactions, not for older utxo types, and so the 4MB max block size is only possible in a block full of segwit inputs. Therefore every utxo without a segregated witness decreases the possible max size of a given block, otherwise a malicious actor could craft 4MB full of the slow-verifying P2PKH tx's to attack the network

it's possible things changed since then, but it's difficult to see how P2PKH could be made safe at bigger blocksizes, as it's already a standard

@achow101 maybe this belongs in dev&tech?

In short,
1. Lower transaction fee.
2. Higher block size limit, assuming there are SegWit transaction on the block.


Wrong. Nothing is removed from calculation, it's just witness data is calculated differently.


Theoretically LN is possible without SegWit. But since SegWit fix transaction malleability, it makes LN development easier.


Inaccurate information. SegWit transaction doesn't always have lower size (in bytes unit), lower tx fee is achieved since witness data is calculated differently.

The main aim of segwit was to actually increase the transaction speed as this was caused by the block size which was actually just 1mb. So as bitcoin began to get more popularity the block size began to fill up easily with transactions there by slowing the speed of transactions. Then a soft fork was introduced which is the Segwit we have today to separate the witness which is the signature meant to verify the transaction from the block and this resulted in creating more space in the block.

Read more here

I am currently learning about SegWit and trying to understand what it is used for. It is clear to me that it was primarily introduced to overcome txid malleability, but if it’s overcoming txid malleability, as the main reason why SegWit was introduced, is no longer the main advantage of SegWit (since it can also be overcome without SegWit), what is? And what are the other advantages and purposes of SegWit in general? I just came across it, and I want to know more about it, so any explanation is welcome.