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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
