Quote from: ETFbitcoin on Today at 11:00:49 AM

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

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

Quote from: ETFbitcoin on Today at 11:00:49 AM

Quote from: fexkomin on Today at 10:42:07 AM

Fee Reduction: By optimizing the way transaction data is stored in blocks, SegWit transactions can require less space, resulting in potentially lower transaction fees.

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

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