From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
Date: Fri, 3 May 2013 11:11:57 -0400 [thread overview]
Message-ID: <20130503151157.GA3902@petertodd.org> (raw)
In-Reply-To: <CANEZrP0mRW-QW60JJmon3ATuoTGnZSFFMne9Dv7FnVnP49GXbQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-05-03 15:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-28 15:51 Pieter Wuille
2013-04-28 16:29 ` Mike Hearn
2013-04-28 16:44 ` Pieter Wuille
2013-04-28 16:57 ` Mike Hearn
2013-05-03 12:30 ` Pieter Wuille
2013-05-03 14:06 ` Mike Hearn
2013-05-03 14:18 ` Peter Todd
2013-05-03 15:02 ` Mike Hearn
2013-05-03 15:11 ` Peter Todd [this message]
2013-05-04 18:07 ` John Dillon
2013-05-04 18:55 ` Jeff Garzik
2013-05-05 13:12 ` John Dillon
2013-05-06 8:19 ` Mike Hearn
2013-05-06 13:13 ` Pieter Wuille
2013-04-28 19:50 ` Gregory Maxwell
2013-04-29 2:57 ` John Dillon
2013-04-29 3:36 ` Gregory Maxwell
2013-04-29 3:42 ` Robert Backhaus
2013-04-29 3:48 ` John Dillon
2013-04-29 3:55 ` Peter Todd
2013-04-29 6:10 ` Jay F
[not found] ` <CAFBxzACw=G7UgG853zQrM-Z1-B4VqSQR5YUJQ5n1=wnv7EyWsw@mail.gmail.com>
2013-04-30 16:14 ` [Bitcoin-development] Fwd: " Rebroad (sourceforge)
2013-04-30 18:04 ` Jeff Garzik
2013-04-30 19:27 ` Andy Parkins
2013-04-30 19:31 ` Simon Barber
2013-04-30 20:11 ` Jeff Garzik
2013-05-01 14:05 ` Andy Parkins
2013-05-01 14:26 ` Jeff Garzik
2013-05-01 14:34 ` Andy Parkins
2013-04-30 20:06 ` [Bitcoin-development] " Brenton Camac
2013-05-01 13:46 ` Jeff Garzik
2013-05-16 11:26 Ricardo Filipe
2013-05-16 15:47 ` Jeff Garzik
2013-05-16 16:23 ` Ricardo Filipe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130503151157.GA3902@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox