📅 Original date posted:2013-08-16
📝 Original message:Oops, hit send too early.
Besides, prioritisation isn't very hard. Nodes can just hand clients a
> signed timestamp which they remember. When re-connecting, the signed
> timestamp is handed back to the node and it gives priority to those with
> old timestamps. No state is required on the node side. Signing and checking
> can be passed onto the general ECDSA thread pool that works its way through
> pending signature operations, they'd be prioritised lower than checking
> blocks/broadcasts.
>
The other nice thing about this approach, besides being stateless on the
server side, is that it's up to the client whether or not they present the
cookie. So the node can say "if you don't present your cookie I'm going to
disconnect you" but when the node has sufficient resources, it'd just not
request this and the client remains anonymous. If the client thinks the
server is calling its bluff, it can just wait and see if it really does get
disconnected and if so, present the cookie up front next time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130816/4fa6ae3d/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:06:05
in reply to nevent1q…hddj
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:06:05Event JSON
{
"id": "776b58fa913a3a7cdfe9f991b88ec03399dc5329cf104eec028468e40b7e8973",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686150365,
"kind": 1,
"tags": [
[
"e",
"5a9ab6946b435e1e53322190b144cf294684f6977db12281caf5c76891efbbe7",
"",
"root"
],
[
"e",
"24f44190ec0713ca25cbe34b6df82c349feaa281d200ccd4cdf918e83279ed9a",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2013-08-16\n📝 Original message:Oops, hit send too early.\n\nBesides, prioritisation isn't very hard. Nodes can just hand clients a\n\u003e signed timestamp which they remember. When re-connecting, the signed\n\u003e timestamp is handed back to the node and it gives priority to those with\n\u003e old timestamps. No state is required on the node side. Signing and checking\n\u003e can be passed onto the general ECDSA thread pool that works its way through\n\u003e pending signature operations, they'd be prioritised lower than checking\n\u003e blocks/broadcasts.\n\u003e\n\nThe other nice thing about this approach, besides being stateless on the\nserver side, is that it's up to the client whether or not they present the\ncookie. So the node can say \"if you don't present your cookie I'm going to\ndisconnect you\" but when the node has sufficient resources, it'd just not\nrequest this and the client remains anonymous. If the client thinks the\nserver is calling its bluff, it can just wait and see if it really does get\ndisconnected and if so, present the cookie up front next time.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130816/4fa6ae3d/attachment.html\u003e",
"sig": "6cbab8ad9ac69f21b0f887eae16fd7c6c26074111159a1fd490012ac809d0795570af718bb6ffc12fa0de2b52740323db951e20342f1eb553f1795d2d4409b0c"
}