-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/11/2017 01:36 PM, Aymeric Vitte via bitcoin-dev wrote: > 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
I agree. Every full node operator should (and likely would at some point) simply never connect to, or relay the address of, any "peer" advertising itself as diminished. Why on earth would a full node operator want to encourage shrinking support for bootstrapping and deep reorgs, resulting in greater load for himself. That's a race to the bottom. We are literally talking about $7.50 for the *entire chain* with breathing room. If someone wants to save a few dollars they are better off attempting to hide their pruning. e > Le 11/05/2017 à 22:10, Jonas Schnelli via bitcoin-dev a écrit : >>> 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/08a7316c144f9f2516db8fa624008 93f4358c5ae/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 > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJZFNHtAAoJEDzYwH8LXOFOYRwH/0By+TNSgnV6m4c7g1ZrjboG 8fZSeGaz7FXmAUZ69XMdQ1H+wlP0e4OAz9eRCcVqcn3K9OZJn++hbzI2K+zijyxZ cpQjg/2dcTc4B0Z3PZdnuZx5mnHzavr/1vPlgOYla7AbYqcKB5dkq/HqgD6tFsJP HXPClbEkVRF6UFP/7sDfzW8FMJycMSVcbEpuWAhcx2d+NusywWhbkuc5NiT9J1Ug /3OFhHVJtd+rDl2B4iRHXHOhysUGffvmmLANZpPMcOgplM6Xwv7nMT34FV4HCdgs Gyxc9GSFsD6xsOshBRPICtEZe+IDDb0cnOLjDdAnUnKeolUljFY52djSa300Fp0= =REyc -----END PGP SIGNATURE----- _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
