<p>Bitcoin Core does not support pruning witnesses. It supports pruning blocks entirely, but that is independent from segwit.</p>
<p>No full node in the network will accept a segwit block without the witnesses. It's simply impossible to validate a block without it, so not having a witness is treated as equivalent to not receiving a block at all.</p>
<p>SegWit does enable dropping witnesses <em>for relay</em>. It is a bandwidth optimization for lightweight clients, because they don't care about the witness data in the first place.</p>
<p>In theory, nodes could indeed choose to not store witnesses at all, but why bother? They can already delete the blocks entirely if they don't care about serving other nodes that want to verify history.</p>
<p>All pruning node implementations today have a minimum required number of kept blocks, which corresponds to a few days of time. That should be sufficient to overcome reorganizations and temporary partitionings.</p>

CC BY-SA 4.0
2017-07-28T13:50:22.897Z
2023-05-07T08:33:29.420Z
2023-05-07T08:33:29.420Z
Pieter Wuille
<p>From people oposed to SegWit I have heard about the argument, <em>that</em> after SegWit activation, nodes may chose to drop/prune all Witnesses. From my understanding, this may not be much different from nodes who are already only storing a pruned version of the blockchain. And a node using the ruleset from SegWit would not accept a block without the witnesses, only the backwards compatible nodes that do not follow the ruleset from Segwit would?</p>

<p>My question is what the default behaviour of a core node is, when it receives block up to X, and the blocks thereafter are only header-files with the actual block data pruned. </p>

<p>In other words: what happens if my node is somehow kept away from the true/whole bitcoin network, so that my node only receives pruned blocks which cannot be verified. Would my node only accept the blocks up to the one which was a block with complete data and drop the rest until complete data is received for those? What if my node is a mining node?</p>

<segregated-witness><pruning><block>
Default behaviour when network partitions/pruned network
Bjarne Magnussen
# Default behaviour when network partitions/pruned network

(Asked by: username_0 on 2017-07-28)

From people oposed to SegWit I have heard about the argument, *that* after SegWit activation, nodes may chose to drop/prune all Witnesses. From my understanding, this may not be much different from nodes who are already only storing a pruned version of the blockchain. And a node using the ruleset from SegWit would not accept a block without the witnesses, only the backwards compatible nodes that do not follow the ruleset from Segwit would?

My question is what the default behaviour of a core node is, when it receives block up to X, and the blocks thereafter are only header-files with the actual block data pruned.

In other words: what happens if my node is somehow kept away from the true/whole bitcoin network, so that my node only receives pruned blocks which cannot be verified. Would my node only accept the blocks up to the one which was a block with complete data and drop the rest until complete data is received for those? What if my node is a mining node?

**Tags:** segregated-witness, pruning, block


---

## 1 answers

### Answer by username_1 on 2017-07-28. Score: 7 | Accepted answer

Bitcoin Core does not support pruning witnesses. It supports pruning blocks entirely, but that is independent from segwit.

No full node in the network will accept a segwit block without the witnesses. It's simply impossible to validate a block without it, so not having a witness is treated as equivalent to not receiving a block at all.

SegWit does enable dropping witnesses *for relay*. It is a bandwidth optimization for lightweight clients, because they don't care about the witness data in the first place.

In theory, nodes could indeed choose to not store witnesses at all, but why bother? They can already delete the blocks entirely if they don't care about serving other nodes that want to verify history.

All pruning node implementations today have a minimum required number of kept blocks, which corresponds to a few days of time. That should be sufficient to overcome reorganizations and temporary partitionings.


---

