📅 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
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 18:01:05
in reply to nevent1q…s9qj
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 18:01:05Event JSON
{
"id": "e98cf037dbb958392e68fcf54675d3edd01df86394aa6ca891d3c5fddefc2278",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160865,
"kind": 1,
"tags": [
[
"e",
"ecbaf4d140ccee9ce74dedeb116844b1d75736de0eaa0dec1da0b9d0e7ac8c74",
"",
"root"
],
[
"e",
"42b6491a0646eb062a67c4ce7868a510e897c59b7561719d22300c684f142212",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2017-05-11\n📝 Original message:\u003e A peer signaling NODE_NETWORK_LIMITED_LOW \u0026 NODE_NETWORK_LIMITED_HIGH MUST\n\u003e be capable of serving at least the last 7'056 blocks (~49 days)\n\u003e (NODE_NETWORK_LIMITED_HIGH's value ^2).\n\nIs 49 days particularly useful? Would it be a problem to instead leave both-\nbits undefined? I'm thinking this might be better as a way to indicate \"7 \ndays, plus a deterministically chosen set of historical blocks\"...\n\n\u003e Current Bitcoin-Core pruned full nodes guarantees a minimum of 288 blocks,\n\u003e thus allowing to signal NODE_NETWORK_LIMITED_LOW with the current minimum\n\u003e configuration.\n\nThis is technically true right now, but as soon as segwit activates, it will \nno longer be... Therefore, I suggest striking it from the BIP, expounding on \nit in greater detail, or making it true for the longer term.\n\n\u003e Peers following this BIP SHOULD connect a limited amount of their available\n\u003e outbound connections to peers signaling one or both of the\n\u003e NODE_NETWORK_LIMITED_* service bits if they expect to request less blocks\n\u003e than the signaled number.\n\nThis isn't entirely clear whether it refers to peers downloading blocks, or \npeers serving them. (I assume the former, but it should be clarified.)\n\n\u003e Light clients (and such) who are not checking the nServiceFlags (service\n\u003e bits) from a relayed addr-message may unwillingly connect to a pruned peer\n\u003e and ask for (filtered) blocks at a depth below their pruned depth.\n\nWouldn't this already be a problem, without the BIP?\n\nLuke",
"sig": "8bf59a176860a0acb79956a8839ab11280f7ec1d1f588809a38676a20b5aa7ad69cb9d0f2491780bb0fffbed48977a74773a66bf1fe348b58f80ce09451dedf2"
}