A few clarifications following a discussion with BIP author Jonas Schnelli yesterday and then thanks to review feedback from both Jonas and Murch.
These are compatible with the reference implementation in the BIP and with the current implementation in Bitcoin Core.
It is worthwhile to read the discussion in reference implementation https://github.com/bitcoin/bitcoin/pull/10387 (particularly https://github.com/bitcoin/bitcoin/pull/10387#discussion_r156861038).
24+Bitcoin right now only offers the <code>NODE_NETWORK</code> service bit to indicate that a peer can serve
25 all historical blocks.
26-# Pruned peers can relay blocks, headers, transactions, addresses and can serve a limited number of historical blocks, thus they should have a way how to announce their service(s)
27-# Peers no longer in initial block download should consider connecting some of its outbound connections to pruned peers to allow other peers to bootstrap from non-pruned peers
28+# Pruned peers can relay blocks, headers, transactions, and addresses, but they guarantee serving only a minimum limited number of historical blocks; thus, they should have a way to announce their service(s)
29+# Pruned peers are defined by this BIP in service bit terms as those having <code>NODE_NETWORK_LIMITED</code> set and any service bit that signals serving the complete block chain, like <code>NODE_NETWORK</code>, not set
NODE_NETWORK and NODE_NETWORK_LIMITED) are set?
33@@ -34,6 +34,8 @@ This BIP proposes a new service bit
34 | NODE_NETWORK_LIMITED || bit 10 (0x400) || If signaled, the peer <I>MUST</I> be capable of serving at least the last 288 blocks (~2 days).
35 |}
36
37+Pruned/limited peers <I>MUST</I> have <code>NODE_NETWORK_LIMITED</code> set and any service bit that signals serving the complete block chain (e.g. <code>NODE_NETWORK</code>) <I>MUST NOT</I> be set. Signaling serving all historical blocks overrides <code>NODE_NETWORK_LIMITED</code>.
Actually, seeing line 34, defining that NODE_NETWORK_LIMITED means that a node is capable of serving at least the last 288 blocks makes me think that it would be correct for nodes with the entire blockchain to indicate both NODE_NETWORK and NODE_NETWORK_LIMITED.
I don’t understand the motivation for the first half-sentence. A pruned node should be permitted to not signal NODE_NETWORK_LIMITED. As far as I understand you want to clarify that a pruned node should not be advertising NODE_NETWORK?
0Pruned/limited peers <I>MUST NOT</I> set a service bit that signals serving the complete block chain (e.g. <code>NODE_NETWORK</code>.
43@@ -42,13 +44,15 @@ Full nodes following this BIP <I>SHOULD</I> relay address/services (<code>addr</
44
45 === Counter-measures for peer fingerprinting ===
46
47-Peers may have different prune depths (depending on the peers configuration, disk space, etc.) which can result in a fingerprinting weakness (finding the prune depth through getdata requests). NODE_NETWORK_LIMITED supporting peers <I>SHOULD</I> avoid leaking the prune depth and therefore not serve blocks deeper than the signaled <code>NODE_NETWORK_LIMITED</code> threshold (288 blocks).
48+Peers may have different prune depths (depending on the peers configuration, disk space, etc.), which can result in a fingerprinting weakness (finding the prune depth through getdata requests).
49+
50+Pruned peers (<code>NODE_NETWORK_LIMITED</code> nodes that do not also signal serving the full block chain) should avoid leaking the prune depth and therefore <I>SHOULD NOT</I> serve blocks deeper than the signaled <code>NODE_NETWORK_LIMITED</code> threshold of 288 blocks.
This seems unnecessarily specific. A node that signals NODE_NETWORK_LIMITED but not NODE_NETWORK should serve only the last 288 blocks, regardless of whether they are pruned or not.
0Peers that signal <code>NODE_NETWORK_LIMITED</code> that do not also signal <code>NODE_NETWORK</code> should avoid leaking the prune depth and therefore <I>SHOULD NOT</I> serve blocks deeper than the signaled <code>NODE_NETWORK_LIMITED</code> threshold of 288 blocks.
NODE_NETWORK_LIMITED indicates being able to at least serve 288 blocks, it seems perfectly compatible with also signaling NODE_NETWORK.
19@@ -20,7 +20,7 @@ Define a service bit that allow pruned peers to signal their limited services
20 Pruned peers can offer the same services as traditional peer except of serving all historical blocks.
21 Bitcoin right now only offers the NODE_NETWORK service bit which indicates that a peer can serve
22 all historical blocks.
23-# Pruned peers can relay blocks, headers, transactions, addresses and can serve a limited number of historical blocks, thus they should have a way how to announce their service(s)
24+# Pruned peers can relay blocks, headers, transactions, and addresses, but they guarantee serving only a minimum limited number of historical blocks; thus, they should have a way to announce their service(s)
Feel free to ignore, but it would make more sense to me to put the “only” before guarantee, otherwise it sounds like they guarantee not serving more than the minimum, which doesn’t match the specification. Also, isn’t “minimum limited” done twice?
0# Pruned peers can relay blocks, headers, transactions, and addresses, but they only guarantee serving a minimum limited number of historical blocks; thus, they should have a way to announce their service(s)
ACK b3e6e24de5cebaa630534e5683c36c4e24831818
Good improvement, one optional nit, if you feel like taking it.
33@@ -34,6 +34,8 @@ This BIP proposes a new service bit
34 | NODE_NETWORK_LIMITED || bit 10 (0x400) || If signaled, the peer <I>MUST</I> be capable of serving at least the last 288 blocks (~2 days).
35 |}
36
37+Pruned/limited peers <I>MUST NOT</I> set a service bit that signals serving the complete block chain (e.g., <code>NODE_NETWORK</code>.
NODE_NETWORK) can also signal NODE_NETWORK_LIMITED as it is inclusive (which would reflect the current behavior on the network)?
e.g. that NODE_NETWORK is not set
See reference implementation
https://github.com/bitcoin/bitcoin/pull/10387
and this comment in that pull
https://github.com/bitcoin/bitcoin/pull/10387#discussion_r156861038
Not the same meaning, so not a purely editorial fixup, but I think "unwittingly"
expresses the intended meaning.
) and removed an extra ) from my last push, and simplified the fingerprinting recommendation to benefit from the latest changes. Let me know what you think.
52 === Risks ===
53
54 Pruned peers following this BIP may consume more outbound bandwidth.
55
56-Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling <code>NODE_NETWORK_LIMITED</code> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.
57+Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwittingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling <code>NODE_NETWORK_LIMITED</code> and not also signaling serving the full block chain, if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.
Sorry for the piecemeal review, but re-reading that paragraph again, I was thinking that it might be good to describe both cases comprehensively:
0Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwittingly connect to a pruned peer and ask for (filtered) blocks at a depth below the peer’s pruned depth. Light clients should therefore check the service bits and (1) connect to peers signaling <code>NODE_NETWORK_LIMITED</code> that preferably do not also signal serving the full block chain, if they only require [filtered] blocks around the tip, or (2) connect to peers signaling serving the full block chain if they need data older than the latest 288 blocks. Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.
Oh, and I noticed that
ACK 22f7f0477c825031a8be80589464766cb2eb2559
One optional elaboration