Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-11 📝 Original message:> A peer signaling ...
📅 Original date posted:2017-05-11
📝 Original message:> A peer signaling NODE_NETWORK_LIMITED_LOW & NODE_NETWORK_LIMITED_HIGH MUST
> be capable of serving at least the last 7'056 blocks (~49 days)
> (NODE_NETWORK_LIMITED_HIGH's value ^2).
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"...
> Current Bitcoin-Core pruned full nodes guarantees a minimum of 288 blocks,
> thus allowing to signal NODE_NETWORK_LIMITED_LOW with the current minimum
> configuration.
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.
> 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.)
> 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?
Luke
📝 Original message:> A peer signaling NODE_NETWORK_LIMITED_LOW & NODE_NETWORK_LIMITED_HIGH MUST
> be capable of serving at least the last 7'056 blocks (~49 days)
> (NODE_NETWORK_LIMITED_HIGH's value ^2).
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"...
> Current Bitcoin-Core pruned full nodes guarantees a minimum of 288 blocks,
> thus allowing to signal NODE_NETWORK_LIMITED_LOW with the current minimum
> configuration.
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.
> 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.)
> 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?
Luke