Sorry again, is this discussion really serious?
In this thread, previous ones or others, the level of
approximation is obvious, often shadowed by useless maths/papers
and strange calculations that are not helping, at the end nobody
knows what would happen "if", how far the chain can roll back, etc
Then don't make pruning the default if it's the current concern, pruning is of no use
Again, the priority should be to scale the full nodes
Is 49 days particularly useful? Would it be a problem to instead leave both- bits undefined? I'm thinking this might be better as a way to indicate "7 days, plus a deterministically chosen set of historical blocks"…I though two service bits allow three states and we should define all three combinations. But I guess an adequate „definition“ would be to reserve it for future „definitions“. Or use Gregory's proposal of min 2016*2 blocks & keep it „undefined“ for now. 49 days was chosen to allow SPV peers to be „offline“ for a month and still be capable to catch-up with a peer pruned to a datadir of ~10GB.This is technically true right now, but as soon as segwit activates, it will no longer be... Therefore, I suggest striking it from the BIP, expounding on it in greater detail, or making it true for the longer term.AFAIK Core does also guaranteed the 288 blocks post segwit activation: https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/validation.h#L204 But maybe I’m confused.Peers following this BIP SHOULD connect a limited amount of their available outbound connections to peers signaling one or both of the NODE_NETWORK_LIMITED_* service bits if they expect to request less blocks than the signaled number.This isn't entirely clear whether it refers to peers downloading blocks, or peers serving them. (I assume the former, but it should be clarified.)Indeed. I’ll try to make that more clear.Light clients (and such) who are not checking the nServiceFlags (service bits) from a relayed addr-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth.Wouldn't this already be a problem, without the BIP?AFAIK, Core does currently only relay NODE_NETWORK addresses. But yes, It may be a problem already. </jonas>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-- Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms