From: Peter Todd <pete@petertodd•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Date: Mon, 6 May 2013 12:12:16 -0400 [thread overview]
Message-ID: <20130506161216.GA5193@petertodd.org> (raw)
In-Reply-To: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4562 bytes --]
On Mon, May 06, 2013 at 04:58:56PM +0200, Mike Hearn wrote:
More generally, I think this shows clearly how SPV nodes have weaker
security than constantly operating full nodes, which we knew already, so
why not build a better SPV-specific system instead?
I've noticed on my Android phone how it often takes quite awhile to find
a peer that will actually accept an incoming connection, which isn't
surprising really: why should a regular node care about responding to
SPV nodes quickly?
For fast startup you would be better served with dedicated nodes that
are backed by fast hardware and high bandwidth internet connections.
You can discourage non-SPV use by refusing to relay full blocks.
You can have trusted individuals vouch for these special servers with
SSL certificates so you run less of a risk of connecting to a malicious
one trying to limit what information you see. For the initial
implementation, maybe just make a quick SSL accessible service with HTTP
GET so you don't have to integrate SSL into the network protocol and
have a couple of these HTTP GETable servers running. (IE, the trust is
actually that the SPV seed is honest)
Security will be no worse than before - if any one server/seed is honest
you're ok - and hopefully better due to the accountability. Obviously
you can use the existing bootstrap method in parallel at the same time.
What's good about partitioning between SPV and full node bootstrapping,
is the regular DNS seeds can optimize the other way: accept that some
nodes may turn out to be evil, and limit the damage by returning peers
from the widest pool possible even if some of those peers may be a bit
slow and unreliable. An attacker can't dominate the results by running a
small number of fast reliable nodes because the results returned comes
from a huge pool, so they are stuck with getting access to lots of IP
addresses, and maybe in the future we'll have even better methods of
resisting sybil attacks, and we will be able to implement those methods
even if they mean initial bootstrapping is slower.
> Subject change to reflect that this is off-topic for the old thread.
>
> Eventually, I think it makes sense to move to a system where you get seeds
> > from
> > a DNS (or other mechanism), connect to one or a few of the results, do a
> > getaddr,
> > fill your peer IP database with it, and disconnect from the DNS seeded
> > peer.
>
>
> This obviously makes no difference from a security perspective. If a DNS
> seed is compromised it can feed you nodes that just connect you back to the
> sybil. If you seed from DNS then that's your root of trust.
>
> The problem with moving away from DNS seeding for bitcoinj clients at least
> is that SPV clients are very sensitive to startup time. It isn't OK to
> spend two minutes trying to connect to lots of long-dead IP addresses if
> you're wanting to pay your bill in a restaurant. That means either you have
> to spin up a lot of TCP connections in parallel, which I know from bitter
> experience can cause problems with some crappy wifi routers (they think
> it's a synflood), or you get a known fresh source of IPs like a DNS seed
> response and then later on bring up connections to the P2P network from
> that.
>
> Implementing the latter is complicated - you have to partition your nodes
> so the seed peers are separated from the peers you found via addr
> broadcasts and seeded peers can't pollute your addr-found peers unless it's
> your first run.
>
> I've actually not experimented with this for a while. I'm hoping that by
> the time this gets to the top of my todo list, network nodes will be stable
> enough that actually you can always obtain at least one or two connections
> if you try (say) 30 at once. But I have no idea if we're at that stage yet.
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
'peter'[:-1]@petertodd.org
000000000000002a871dc011fe28fd8fbffe577c02b91d2de09aeca8216644ef
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-05-06 16:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 14:58 Mike Hearn
2013-05-06 16:12 ` Peter Todd [this message]
2013-05-06 16:20 ` Jeff Garzik
2013-05-06 16:34 ` Mike Hearn
2013-05-06 16:37 ` Peter Todd
2013-05-06 16:47 ` Mike Hearn
2013-05-06 17:19 ` Peter Todd
2013-05-06 17:25 ` Jeff Garzik
2013-05-06 17:42 ` Gregory Maxwell
2013-05-06 17:53 ` Peter Todd
2013-05-06 18:01 ` Gregory Maxwell
2013-05-06 18:19 ` Peter Todd
2013-05-06 18:32 ` Adam Back
2013-05-06 19:08 ` Peter Todd
2013-05-06 19:50 ` Adam Back
2013-05-06 20:43 ` Peter Todd
2013-05-06 23:44 ` Peter Todd
2013-05-07 9:00 ` Mike Hearn
2013-05-09 0:57 ` John Dillon
2013-05-06 18:04 ` Adam Back
2013-05-06 18:25 ` Gregory Maxwell
2013-05-06 22:51 ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Adam Back
2013-05-06 23:13 ` Gregory Maxwell
2013-05-07 4:48 ` Petr Praus
2013-05-07 21:07 ` Matt Corallo
2013-05-07 9:17 ` Mike Hearn
2013-05-07 11:07 ` Adam Back
2013-05-07 12:04 ` Mike Hearn
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=20130506161216.GA5193@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