14

Why do pruned nodes download (segregated) witness data during IBD if much of that data is marked as Assumevalid?

These nodes seem to be downloading witness data just to prune it. Since we already know that such witnesses are valid, and we plan to discard all historic data but recent blocks, why not skip downloading old witnesses? It seems pointless to download witness data in this case.

2 Answers 2

14

Why do pruned nodes download (segregated) witness data during IBD if much of that data is marked as Assumevalid?

Good question, probably because nobody implemented it. Honestly, I had never considered this possibility.

These nodes seem to be downloading witness data just to prune it. Since we already know that such witnesses are valid, and we plan to discard all historic data but recent blocks, why not skip downloading old witnesses? It seems pointless to download witness data in this case.

You're right.

We can't just generally drop downloading witness data in full nodes, because NODE_NETWORK + NODE_WITNESS promise to other nodes the availability of all historical block and witness data.

But in the case of pruned nodes, the witness data that is both (a) before the assumevalid point and (b) sufficiently buried to be past the prune point, there is indeed little to gain from having it, as the data will be deleted soon.

One tiny change this implies is that not downloading the witness data implies the witness data cannot be validated at all, while assumevalid currently in Bitcoin Core only skips script validation. But there are other rules that involve witness data, such as resource limits and the rule that no witness data is allowed for non-witness inputs. If we treat assumevalid as also considering these pre-validated, that's a fine change though.

1
  • 4
    Yes, I think this would allow a non-trivial speed up of IBD for pruned nodes. Nowadays witness data is a big part of each block that pruned nodes are pointlessly downloading. In the extreme case of a 4MB block, a pruned node could just download a really small fraction of it. Intuitively, with Assumevalid CPU is less likely to be the bottleneck, but bandwidth and I/O, which is further reduced by downloading less data. Feb 4, 2023 at 22:44
5

This was described in the "Segregated Witness Benefits" article on bitcoincore.org (from Jan 2016, prior to Segwit's activation):

Efficiency gains when not verifying signatures

Signatures for historical transactions may be less interesting than signatures for future transactions – for example, Bitcoin Core does not check signatures for transactions prior to the most recent checkpoint by default, and some SPV clients simply don’t check signatures themselves at all, trusting that has already been done by miners or other nodes. At present, however, signature data is an integral part of the transaction and must be present in order to calculate the transaction hash.

Segregating the signature data allows nodes that aren’t interested in signature data to prune it from the disk, or to avoid downloading it in the first place, saving resources.

(Emphasis mine)

Your Answer

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

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