12

Segregated witnesses sound like a win in a lot of ways, I'm just trying to understand how they apply to scalability. If I understand correctly, there is a second Merkle tree of witnesses mirroring the transaction data. The witness tree's root is committed to in the coinbase, but otherwise this second tree lives outside of the block.

Don't the witnesses still have to be relayed to other nodes to validate? Why is it acceptable now to send more data, but raising the block size was dangerous, and exclusionary of nodes on slow connections before?

Also, if witnesses are outside of the block and prunable, how will a fresh fully validating node get up to date? If a smaller subset of full nodes hosts all witnesses, does that trade off security for amount of transactions in a block?

Improve this question
2

1 Answer 1

Reset to default
7

If I understand correctly, there is a second Merkle tree of witnesses mirroring the transaction data. The witness tree's root is committed to in the coinbase, but otherwise this second tree lives outside of the block.

That is my understanding as well.

Don't the witnesses still have to be relayed to other nodes to validate?

Only nodes that actually care about the signatures. There are thousands of SPV nodes, for example, that want to be able to calculate the TXID of the transactions they care about but that don't actually need the scriptSigs other than that, since SPV nodes rely on confirmations for security instead of fully checking scripts.

Why is it acceptable now to send more data, but raising the block size was dangerous, and exclusionary of nodes on slow connections before?

Many people rejected the idea of increasing the block size limit simply because it was a hard fork. The extra data and exclusion of some nodes is still an issue, and I'm sure there will still be plenty of arguments about how to count the witness data. This just eliminates/postpones the hard fork max block size debate.

Pieter Wuille's current proposal is to give a 75% discount on signature data, increasing the effective max block size to about 4 MB in the worst case, but that would probably never come close to being realized in any normal, non-malicious, circumstance. I would estimate that a full 1M normal block would be a 1.8 MB block of completely SW transactions.

Also, if witnesses are outside of the block and prunable, how will a fresh fully validating node get up to date? If a smaller subset of full nodes hosts all witnesses, does that trade off security for amount of transactions in a block?

When a full node comes online now, it currently doesn't even check the script evaluations in anything older than the most recent checkpoint. In this sense, it's not a 'fully validating' node, it's more of a 'fully validating from 6 months ago onward' node. But, unfortunately, to build the UTXO set right now you still need to download the scriptSigs, even though they're not used for any validation. The Segregated witness change makes it so that in the case of SW transactions, excessively old scriptSigs that wouldn't be verified anyway don't have to also be downloaded, because the TXIDs don't use them.

Note that some transactions using Segregated witness doesn't magically make old-style transactions more prunable, unfortunately. However, if Segregated witness were fully in use by all transactions today, then in 5 years from now, a node that was getting up to sync wouldn't have to download a lot of the signature data from the past 5 years, just the most recent signature data.

So, there is a security trade-off there, but it's the exact same trade off that already exists. With SW, though, you just have to download less data (~60% less of the new SW transaction data) for the same security.

Improve this answer
4
  • 2
    To improve that security trade off another option will become possible thanks to SW: you could download for example a random 1% of the older signatures. If every node double checked a different random set of signatures, together they will quickly statistically cover 100%. And thanks to Fraud Proofs, which will also become possible with SW, nodes can actually inform each other about problems. Another extra security effort you could chose to do is, when you receive a payment, trace back and verify all the parent transactions that the coin came from by downloading only those signatures.
    – Jannes
    Dec 11, 2015 at 0:04
  • I'm not sure about the 2.5MB number. I get 2.22 MB, assuming signatures used to be 60% of the block and that they get a 75% discount while in SW.
    – Nick ODell
    Dec 11, 2015 at 1:20
  • @NickODell, I think 2.2 MB would be over the 1 MB counted limit. I just tried doing the math, and got a typical upper limit of 1.82 MB. pastebin.com/u4frCUfb Maybe you could check my math, and once we agree on the number I'll update my answer?
    – morsecoder
    Dec 14, 2015 at 15:47
  • @StephenM347, Re "but it's the exact same trade off that already exists", what are you referring to?
    – Pacerier
    Oct 26, 2017 at 2:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.