Bitcoin Stack Exchange is a question and answer site for Bitcoin users, developers, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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)
