How exactly does SegWit fix malleability and cut block space?

11 replies 57 views
sage404Member
Posts: 3 · Reputation: 100
#1Feb 8, 2019, 08:32 PM
Been reading about ways to save on tx fees and stumbled on SegWit. So I get that it was supposed to fix malleability stuff and make better use of block space, but honestly the mechanics are still fuzzy to me. Can someone break down what's different in a SegWit tx versus the old format? How does that lead to cheaper fees? And why does separating witness data actually stop malleability attacks? Would be great to see some concrete examples too, legacy vs segwit side by side.
5 Reply Quote Share
ColdGangMember
Posts: 156 · Reputation: 183
#2Feb 9, 2019, 02:14 AM
Alright so SegWit stands for Segregated Witness, basically what it does is split up the witness stuff (sigs and pubkeys) from the actual transaction payload. This separation means you save on the data size and that translates to lower fees because less data gets packed into blocks. Now with legacy transactions everything including witness gets hashed together to make the TXID, which creates this weird vulnerability where tweaking the witness doesn't break the signature but changes the ID. SegWit fixes it by computing TXID without the witness part at all.
2 Reply Quote Share
chrisomegaFull Member
Posts: 159 · Reputation: 631
#3Feb 9, 2019, 04:43 AM
Yeah and here's the real problem with legacy inputs. If you got legacy inputs in your tx, someone (like a miner) can just modify the witness data and flip the transaction ID without breaking anything. So imagine you have an unconfirmed parent tx with legacy inputs and you build a child tx on top of it. A miner could mutate that parent's ID, your child becomes invalid even though the parent still exists on chain. With SegWit inputs only? Miners can't pull this off. The ID stays locked.
3 Reply Quote Share
gang2015Member
Posts: 693 · Reputation: 62
#4Feb 9, 2019, 06:51 AM
This question gets asked a lot, there's actually a decent write-up from Bitcoin Core back in the day that covers most of this. But since you're on the tech board I gotta point out a couple things: you're mixing up P2SH-wrapped SegWit (P2SH-P2WPKH and P2SH-P2WSH) with pure SegWit. They're not the same thing. Also P2WSH exists separately and was meant to eventually replace P2SH entirely. One more thing, Bech32 wasn't just for SegWit, it was designed for future upgrades, but they had to swap to Bech32m later because of error detection problems.
3 Reply Quote Share
mr_apeNewbie
Posts: 407 · Reputation: 35
#5Feb 9, 2019, 07:53 AM
To really get SegWit you need to understand how Bitcoin's script engine works. And honestly this isn't even the first time Bitcoin did something like this. Think about OP_HASH160 <160-bit data> OP_EQUAL, super simple script. It takes the top stack item, hashes it, pushes your 160-bit value, then checks if they match. Years back they did a soft fork that added new rules so when the interpreter saw certain patterns it would...
2 Reply Quote Share
Posts: 117 · Reputation: 19
#6Feb 9, 2019, 11:07 AM
Hold up, witness data isn't actually separated from the transaction structure itself. It's right there in each transaction, just sits before the nLocktime field. The separation is more conceptual for the TXID calculation, which prevents someone from changing signatures and breaking child transactions. It's not like it changes the actual space. Fees go down indirectly because witness data doesn't count against the old block size cap anymore. They replaced that with a weight limit instead, kind of like measuring block space differently now.
6 Reply Quote Share
Posts: 187 · Reputation: 37
#7Feb 9, 2019, 01:29 PM
OP seriously, why is "sigwit" in your title? It's SegWit. This isn't just pedantic, bad spelling kills searchability. Someone tries to find SegWit discussions and your thread vanishes from results. Kinda inconsiderate to everyone looking for this stuff.
2 Reply Quote Share
Posts: 117 · Reputation: 19
#8Feb 9, 2019, 06:58 PM
Already fixed that for them. Though honestly sometimes typos can be useful context clues.
4 Reply Quote Share
sage404Member
Posts: 3 · Reputation: 100
#9Feb 9, 2019, 10:10 PM
Thanks @gmaxwell for cleaning that up. Yeah that was just a typo on my end, didn't catch it before posting.
6 Reply Quote Share
just_sageFull Member
Posts: 13 · Reputation: 603
#10Feb 10, 2019, 02:38 AM
So I dug into this a while back trying to figure out why SegWit even matters and ngl it's confusing at first. But it clicks once you break it down. SegWit wasn't the first upgrade like this. There was P2SH before it, where older nodes would just check if a hash matched using OP_HASH160 <somehash> OP_EQUAL, but newer nodes could go deeper and actually execute the hidden script behind that hash. That soft fork made it possible.
4 Reply Quote Share
lord42Newbie
Posts: 33 · Reputation: 30
#11Feb 12, 2019, 09:36 AM
Quick question: witness and signatures are the same thing or what? I've read a bunch but still not 100% clear. From what I gathered the main difference is signatures sitting separate. With SegWit they're not next to each input, the whole input gets processed and validated by the signature at the end. Legacy does it per input which takes more space and shows up in fees.
1 Reply Quote Share
mr_apeNewbie
Posts: 407 · Reputation: 35
#12Feb 12, 2019, 12:50 PM
Witness is basically all the stack data needed to complete script validation. Depends on the script type. For P2WPKH you get the pubkey and signature as two separate items. For P2WSH you get the redeem script itself.
4 Reply Quote Share

Related topics