Published on: 2017-05-12T02:22:15+00:00
The discussion in the Bitcoin-dev mailing list revolves around the proposal by Jonas Schnelli to improve the signaling of valuable services by pruned peers. The proposal can be found on Github and participants have expressed concerns about the instructions for relay addresses in the proposal. It is suggested that the instructions should not instruct individuals to relay specific addresses but rather relay addresses they would connect to, to avoid relaying information that is not useful.There are concerns raised about the default setting for pruning in Bitcoin, with some participants suggesting that the focus should be on scaling full nodes rather than making pruning the default. The level of approximation and "useless maths/papers" used to support various arguments is criticized. One participant suggests 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, and it is suggested that anyone wanting to save a few dollars would be better off attempting to hide their pruning.The discussion also revolves around defining the service bits for historical blocks. Some suggest leaving both bits undefined, while others propose using Gregory's proposal of a minimum of 2016*2 blocks. The reason for choosing a 49-day time limit is discussed, allowing Simplified Payment Verification (SPV) peers to be offline for a month and still catch up with a pruned peer. There is confusion about whether Core guarantees the 288 blocks post-segwit activation.There is also a concern raised about light clients who are not checking the nServiceFlags from a relayed addr-message, as they may unwillingly connect to a pruned peer and ask for filtered blocks below their pruned depth. The email includes links to various resources including Zcash wallets made simple, Bitcoin wallets made simple, torrent blocklists, and anti-spy software.In summary, the discussion focuses on the usefulness of defining a deterministically chosen set of historical blocks within a certain timeframe and whether it would be better to leave it undefined. The proposal suggests that peers should connect a limited amount of their available outbound connections to peers signaling the NODE_NETWORK_LIMITED_* service bits. There is also a concern about light clients unknowingly connecting to pruned peers. The author of the email has shared a BIP proposal to improve the signaling of valuable services by pruned peers and welcomes feedback on the draft.
Updated on: 2023-08-01T20:35:56.038210+00:00