2
I've had a hard time finding a good source online that explains segwit. I've read the basic idea is to store the scriptSigs separately as the scriptSig is potentially malleable, and then compute the txid without the scripSig. But the scriptSig still needs to be somewhere on the blockchain, so how does this save space?
1
It doesn't. See https://bitcoin.stackexchange.com/q/52196/208
– Pieter Wuille – 2017-05-03T05:11:24.733I don't get it. It sounds like you're putting the scriptSig in a separate place you're not calling a block, but still using the same amount of space. Why not just keep it in the block, and just compute the txid ignoring the scriptsig to get the non-malleability advantage? – relG – 2017-05-03T09:20:50.430
That would not be a softfork, and thus require every node in the whole network to adopt new software before the change can be deployed. It would also break existing wallet software. The way it is done is fully backward compatible. – Pieter Wuille – 2017-05-03T14:04:07.473
Is a softfork such a holy grail in itself, that anything that satisfies the definition is good? To me a natural softfork is one where the legitimate sender can get his tx unaccepted by new nodes if he doesn't upgrade his wallet to the new rules.. but here because the scriptSig is anyone_can_spend, anyone can fraudulently spend the output of the legitimate owner in the view of the old nodes. Thus, the old nodes will become completely useless almost immediately - they also cannot relay a legitimate transaction to the new nodes because they don't know they need to transfer the witness. – relG – 2017-05-03T14:59:40.527
1Softforks are not a holy grail. A softfork that freezes some specific person's coins would be a very bad thing. But what you're saying is an overstatement: old nodes indeed can't fully verify spends from segwit outputs, but they also don't care about them. – Pieter Wuille – 2017-05-03T15:18:12.290
2
See https://segwit.org/on-the-security-of-soft-forks-2c0a00077399
– Pieter Wuille – 2017-05-03T15:24:14.530