Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

[Peter Todd <pete@petertodd.org>]

[-- 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 --]