Topic: Block relay when pruning (Read 877 times)
Fair enough, and I agree with the suggest change. There is no reason not to send invs for blocks near the tip.
I think this https://github.com/bitcoin/bitcoin/pull/5863 is where it was merged.
Under the discussion you have point 2:
So it seems the intention is to fix it once they figure out a way to tell other nodes which blocks the node has.
EDIT: Also a PR is open to fix it: https://github.com/bitcoin/bitcoin/pull/6148
Under the discussion you have point 2:
Quote
We’ve disabled block relay (with a check to see if we’re NODE_NETWORK or not). In the future when we have worked out the service bit to use for an autopruned node and the behavior for block requests, we can re-enable this appropriately. (This differs from the behavior of #4701 .)
There is a litte further discussion further down as well.So it seems the intention is to fix it once they figure out a way to tell other nodes which blocks the node has.
EDIT: Also a PR is open to fix it: https://github.com/bitcoin/bitcoin/pull/6148
I was looking at the block relay code in master.
When a new block is added/connected, each node informs its peers about the new block.
With this code, pruning nodes won't do that. I don't think that is a good idea. When in initial download, the node shouldn't inform nodes about new blocks, but once synced, there is no reason not to.
The rule could be that if the block header extends the main chain, the main chain has passed the final checkpoint (or has POW > some_threshold) and the (median of 11) timestamp for the header is less than 6 hours old then a pruning node should inform its peers about the block. Leaving them in the dark about a new block seems worse.
Code:
// Don't relay blocks if pruning -- could cause a peer to try to download, resulting
// in a stalled download if the block file is pruned before the request.
if (nLocalServices & NODE_NETWORK) {
LOCK(cs_vNodes);
BOOST_FOREACH(CNode* pnode, vNodes)
if (chainActive.Height() > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : nBlockEstimate))
pnode->PushInventory(CInv(MSG_BLOCK, hashNewTip));
}
// in a stalled download if the block file is pruned before the request.
if (nLocalServices & NODE_NETWORK) {
LOCK(cs_vNodes);
BOOST_FOREACH(CNode* pnode, vNodes)
if (chainActive.Height() > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : nBlockEstimate))
pnode->PushInventory(CInv(MSG_BLOCK, hashNewTip));
}
When a new block is added/connected, each node informs its peers about the new block.
With this code, pruning nodes won't do that. I don't think that is a good idea. When in initial download, the node shouldn't inform nodes about new blocks, but once synced, there is no reason not to.
The rule could be that if the block header extends the main chain, the main chain has passed the final checkpoint (or has POW > some_threshold) and the (median of 11) timestamp for the header is less than 6 hours old then a pruning node should inform its peers about the block. Leaving them in the dark about a new block seems worse.
Jump to: