From: Peter Todd <pete@petertodd•org>
To: Gregory Maxwell <gmaxwell@gmail•com>
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 14:19:59 -0400 [thread overview]
Message-ID: <20130506181959.GC22505@petertodd.org> (raw)
In-Reply-To: <CAAS2fgQWnZ_yPA7G4LNwk655CxTD9WZf0f-cb5xd3TFzpBB2_g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3459 bytes --]
On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote:
> On Mon, May 6, 2013 at 10:53 AM, Peter Todd <pete@petertodd•org> wrote:
> > We don't have non-repudiation now, why make that a requirement for the
> > first version? Adding non-repudiation is something that has to happen at
> > the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure
> > you're connection isn't being tampered with and is encrypted.
>
> Because if you just want bitcoin p2p over SSL... just start up stunnel
> on another port. Done. You've still solved nothing about the problem
> of discovery issue.
stunnel only works if both sides support it.
re: discovery, the whole reason I brought up SSL was the idea that a
seed whome you have a secure connection to, like HTTPS or SSL, can
include the peer pubkey along with the peer's IP address, allowing you
to be sure you've connected to the peer the seed is giving you rather
than some other imposter.
Equally it'll let you be sure you've connected to the correct peer the
second time.
For applications where you *don't* need non-repudiation SSL is already
implemented and solves the secure peer communication issue, including
encryption, in an efficient way without requiring a lot of code
complexity to implement.
SSL could be implemented as a Google Summar of Code project by an
average developer, and importantly re-implemented by all the alt-clients
out there with relatively little work.
It may even be the case that some usage scenarios do find the CA system
useful. I might want to do -addnode ssl://petertodd.org on my Android
wallet to be sure I've connected to my Bitcoin node rather than some
MITM ISP imposter. I already have a SSL cert from a CA for petertodd.org
that I can use and my Android phone already has a list of CA's I can put
a reasonable amount of trust in.
> > 1) Non-repudiation is only useful with fraud proofs, and they will have
> > to be thought out for everything the node might claim.
>
> That isn't so. If a node is reliably rogue I can go manually gather
> evidence and people can manually take action against it. Consider the
> DNSseeds, right now fraud proofs really wouldn't matter— the limited
> amount of trust put in those things is based not on "oh no, nodes will
> ignore you in the future if you're bad", it's based on the ability of
> misconduct to sully the operator's reputation.
Sure, but how will non-repudiation be implemented? By having the node
sign the messages they send with their pubkey, and as Mike suggests
likely doing so in some sort of chained hash or preferably merkle
mountain range to allow for constructing proofs over multiple messages.
That has nothing to do with encrypting the transport, and will always be
a lot slower than SSL's symmetric cipher for when you don't need
non-repudiation but do want to be sure you've connected to the right
node.
> > Anyway, the concept of a per-node identity keypair is the first step
> > towards non-repudiation, and implementing SSL transport.
>
> Yea, indeed, per-node keys are useful for a bunch of things. Care is
> needed to avoid problems like deanonymizing use over tor with them.
Per-node keys really need to be per listening address by default. In
fact, I'd argue for creating new keys on startup by default.
--
'peter'[:-1]@petertodd.org
000000000000015ef6fc2fc45adc1de0c344e99a59453bb09ac470a1d02b787d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-05-06 18:20 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
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 [this message]
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=20130506181959.GC22505@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/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