đź“… Original date posted:2017-05-11
đź“ť Original message:> 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"…
I though two service bits allow three states and we should define all three combinations.
But I guess an adequate „definition“ would be to reserve it for future „definitions“.
Or use Gregory's proposal of min 2016*2 blocks & keep it „undefined“ for now.
49 days was chosen to allow SPV peers to be „offline“ for a month and still be capable to catch-up with a peer pruned to a datadir of ~10GB.
>
> 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.
AFAIK Core does also guaranteed the 288 blocks post segwit activation:
https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/validation.h#L204
But maybe I’m confused.
>
>> 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.)
Indeed. I’ll try to make that more clear.
>
>> 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?
AFAIK, Core does currently only relay NODE_NETWORK addresses.
But yes, It may be a problem already.
</jonas>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170511/96f3a942/attachment.sig>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 18:01:05
in reply to nevent1q…08d8
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 18:01:05Event JSON
{
"id": "7f7179a5f8f8034e0a84ec58e799543563c50a04e24a908c8bb59e7fbfa10508",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686160865,
"kind": 1,
"tags": [
[
"e",
"ecbaf4d140ccee9ce74dedeb116844b1d75736de0eaa0dec1da0b9d0e7ac8c74",
"",
"root"
],
[
"e",
"e98cf037dbb958392e68fcf54675d3edd01df86394aa6ca891d3c5fddefc2278",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-05-11\n📝 Original message:\u003e Is 49 days particularly useful? Would it be a problem to instead leave both-\n\u003e bits undefined? I'm thinking this might be better as a way to indicate \"7\n\u003e days, plus a deterministically chosen set of historical blocks\"…\n\nI though two service bits allow three states and we should define all three combinations.\nBut I guess an adequate „definition“ would be to reserve it for future „definitions“.\nOr use Gregory's proposal of min 2016*2 blocks \u0026 keep it „undefined“ for now.\n\n49 days was chosen to allow SPV peers to be „offline“ for a month and still be capable to catch-up with a peer pruned to a datadir of ~10GB.\n\n\u003e \n\u003e This is technically true right now, but as soon as segwit activates, it will\n\u003e no longer be... Therefore, I suggest striking it from the BIP, expounding on\n\u003e it in greater detail, or making it true for the longer term.\n\nAFAIK Core does also guaranteed the 288 blocks post segwit activation:\nhttps://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/validation.h#L204\nBut maybe I’m confused.\n\n\u003e \n\u003e\u003e Peers following this BIP SHOULD connect a limited amount of their available\n\u003e\u003e outbound connections to peers signaling one or both of the\n\u003e\u003e NODE_NETWORK_LIMITED_* service bits if they expect to request less blocks\n\u003e\u003e than the signaled number.\n\u003e \n\u003e This isn't entirely clear whether it refers to peers downloading blocks, or\n\u003e peers serving them. (I assume the former, but it should be clarified.)\n\nIndeed. I’ll try to make that more clear.\n\n\u003e \n\u003e\u003e Light clients (and such) who are not checking the nServiceFlags (service\n\u003e\u003e bits) from a relayed addr-message may unwillingly connect to a pruned peer\n\u003e\u003e and ask for (filtered) blocks at a depth below their pruned depth.\n\u003e \n\u003e Wouldn't this already be a problem, without the BIP?\n\nAFAIK, Core does currently only relay NODE_NETWORK addresses.\nBut yes, It may be a problem already.\n\n\u003c/jonas\u003e\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170511/96f3a942/attachment.sig\u003e",
"sig": "b72ff45fad41325ece3458631a0d10fbafe4df6e2de5e6a9be22ed3c42e8c5049015155d17ddcf2b5e3d20704cc25ea4f5091ddba9738bb6e4edb49277203146"
}