📅 Original date posted:2013-05-03
📝 Original message:On Fri, May 03, 2013 at 05:02:26PM +0200, Mike Hearn wrote:
> > If you're going to take a step like that, the <current-chain-height>
> > should be rounded off, perhaps to some number of bits, or you'll allow
> > DNS caching to be defeated.
> >
>
> Don't the seeds already set small times? I'm not sure we want these
> responses to be cacheable, otherwise there's a risk of a wall of traffic
> suddenly showing up at one set of nodes if a large ISP caches a response.
> (yes yes, I know, SPV node should be remembering addr broadcasts and such).
Hmm, on second thought you're probably right for the standard case where
it's really P2P. On the other hand it kinda limits us in the future if
seeds have high-bandwidth nodes they can just point clients too, but
maybe just assuming the DNS seed might need high bandwidth as well is
acceptable.
I dunno, given how badly behaved a lot of ISP dns servers are re:
caching, maybe we're better off keeping it simple.
--
'peter'[:-1]@petertodd.org
000000000000013bfdf35da40a40c35ccd75e09652ae541d94d26130a695f757
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130503/30c4eca0/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 14:56:19
in reply to nevent1q…evnm
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 14:56:19Event JSON
{
"id": "5e48c2e5b70753cfa14db1fc1fe20d8135e44d59a68e5426ac3a4104cbc680be",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686149779,
"kind": 1,
"tags": [
[
"e",
"29ec2e2b5b2f4dc51eb87cabd53d5f02656fee9d1f600fd1d211680c53c784ad",
"",
"root"
],
[
"e",
"b9ed7b22be5406fc09e511d88f738756c45fa7531439ca573166240eda08ebe9",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2013-05-03\n📝 Original message:On Fri, May 03, 2013 at 05:02:26PM +0200, Mike Hearn wrote:\n\u003e \u003e If you're going to take a step like that, the \u003ccurrent-chain-height\u003e\n\u003e \u003e should be rounded off, perhaps to some number of bits, or you'll allow\n\u003e \u003e DNS caching to be defeated.\n\u003e \u003e\n\u003e \n\u003e Don't the seeds already set small times? I'm not sure we want these\n\u003e responses to be cacheable, otherwise there's a risk of a wall of traffic\n\u003e suddenly showing up at one set of nodes if a large ISP caches a response.\n\u003e (yes yes, I know, SPV node should be remembering addr broadcasts and such).\n\nHmm, on second thought you're probably right for the standard case where\nit's really P2P. On the other hand it kinda limits us in the future if\nseeds have high-bandwidth nodes they can just point clients too, but\nmaybe just assuming the DNS seed might need high bandwidth as well is\nacceptable.\n\nI dunno, given how badly behaved a lot of ISP dns servers are re:\ncaching, maybe we're better off keeping it simple.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000013bfdf35da40a40c35ccd75e09652ae541d94d26130a695f757\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130503/30c4eca0/attachment.sig\u003e",
"sig": "6dcb1938b82d597e3e0cc1485d2ee6be13d9027066c0d16bbda411986c3331084273f9ecef4ed0219db684bd5c22c6927f425e58627377aa162e8a14c4a0d6bb"
}