Author: Eric Voskuil 2017-05-11 21:05:09
Published on: 2017-05-11T21:05:09+00:00
The discussion in the email thread is about the default setting for pruning in Bitcoin. Some participants are expressing concern about the level of approximation and "useless maths/papers" that are being used to support various arguments. They suggest that the priority should be to scale full nodes rather than making pruning the default. One participant argues that every full node operator should simply not connect to or relay the address of any peer advertising itself as diminished. The cost of the entire chain is estimated at $7.50, with breathing room. The suggestion is made that anyone wanting to save a few dollars would be better off attempting to hide their pruning. A proposal is made to define all three combinations of two service bits but it is suggested that it may be better to leave both bits undefined or use Gregory's proposal of minimum 2016*2 blocks and keep it "undefined" for now. The 49-day time limit was chosen to allow Simplified Payment Verification (SPV) peers to be offline for a month and still be capable of catching up with a pruned peer.Further discussion revolves around whether peers following the 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. Light clients 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. The email also includes links to various resources including Zcash wallets made simple, Bitcoin wallets made simple, the torrent dynamic blocklist, the 10 M passwords list, anti-spies and private torrents, dynamic blocklist, Peersm, torrent-live, node-Tor, and GitHub.
Updated on: 2023-06-12T00:45:04.233740+00:00