<p>This was described in the <a href="https://bitcoincore.org/en/2016/01/26/segwit-benefits/#efficiency-gains-when-not-verifying-signatures" rel="noreferrer">&quot;Segregated Witness Benefits&quot;</a> article on bitcoincore.org (from Jan 2016, prior to Segwit's activation):</p>
<blockquote>
<h5>Efficiency gains when not verifying signatures</h5>
<p>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.</p>
<p>Segregating the signature data allows nodes that aren’t interested in signature data to prune it from the disk, <strong>or to avoid downloading it in the first place</strong>, saving resources.</p>
</blockquote>
<p>(Emphasis mine)</p>

CC BY-SA 4.0
2023-02-06T05:25:49.717Z
2023-02-06T05:36:17.607Z
2023-02-06T05:36:17.607Z
shesek
<blockquote>
<p>Why do pruned nodes download (segregated) witness data during IBD if much of that data is marked as Assumevalid?</p>
</blockquote>
<p>Good question, probably because nobody implemented it. Honestly, I had never considered this possibility.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>You're right.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-02-04T22:44:36.063Z
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.
Son Kaos999
CC BY-SA 4.0
2023-02-04T21:42:38.653Z
2023-02-04T21:42:38.653Z
Pieter Wuille
<p>Why do pruned nodes download (segregated) witness data during IBD if much of that data is marked as Assumevalid?</p>
<p>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.</p>

<segregated-witness><synchronization><pruning><witness-data><assume-valid>
Why is witness data downloaded during IBD in prune mode?
Son Kaos999
# Why is witness data downloaded during IBD in prune mode?

(Asked by: username_0 on 2023-02-04)

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.

**Tags:** segregated-witness, synchronization, pruning, witness-data, assume-valid


---

## 2 answers

### Answer by username_2 on 2023-02-04. Score: 16 | Accepted answer

> 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.

> **Comments:**
> **username_0**: 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.  

---

### Answer by username_1 on 2023-02-06. Score: 5

This was described in the ["Segregated Witness Benefits"](https://bitcoincore.org/en/2016/01/26/segwit-benefits/#efficiency-gains-when-not-verifying-signatures) 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)


---

