Re: [Bitcoin-development] Service bits for pruned nodes

2013-05-03 Thread Peter Todd
On Fri, May 03, 2013 at 05:02:26PM +0200, Mike Hearn wrote: > > If you're going to take a step like that, the > > 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 > re

Re: [Bitcoin-development] Service bits for pruned nodes

2013-05-03 Thread Mike Hearn
> If you're going to take a step like that, the > 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 sud

Re: [Bitcoin-development] Service bits for pruned nodes

2013-05-03 Thread Peter Todd
On Fri, May 03, 2013 at 04:06:29PM +0200, Mike Hearn wrote: > That's true, but we can extend the DNS seeding protocol a little bit - you > could query .dnsseed.whatever.com and the DNS server > then only returns nodes it knows matches your requirement. If you're going to take a step like that, the

Re: [Bitcoin-development] Service bits for pruned nodes

2013-05-03 Thread Mike Hearn
> Yes, I like that better than broadcasting the exact height starting at > which you serve (though I would put that information immediately in the > version announcement). I don't think we can rely on the addr broadcasting > mechanism for fast information exchange anyway. One more problem with this

Re: [Bitcoin-development] Service bits for pruned nodes

2013-05-03 Thread Pieter Wuille
(generic comment on the discussion that spawned off: ideas about how to allow additional protocols for block exchange are certainly interesting, and in the long term we should certainly consider that. For now I'd like to keep this about the more immediate way forward with making the P2P protocol no