public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 13:53:31 -0400	[thread overview]
Message-ID: <20130506175331.GB22505@petertodd.org> (raw)
In-Reply-To: <CAAS2fgQDa463Xb=D64LDenGn=mX+OXvD_bG=jXGYLnhFbgknsw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

On Mon, May 06, 2013 at 10:42:19AM -0700, Gregory Maxwell wrote:
> On Mon, May 6, 2013 at 10:19 AM, Peter Todd <pete@petertodd•org> wrote:
> >> running hash of all messages sent on a connection so far. Add a new
> >> protocol message that asks the node to sign the current accumulated
> >> hash.
> > We already depend on OpenSSL, why not just use standard SSL?
> 
> SSL doesn't actually provide non-repudiation. We actually want
> non-repudiation. I want to be able to prove to others that some node
> deceived me.

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.

1) Non-repudiation is only useful with fraud proofs, and they will have
to be thought out for everything the node might claim.

> (there are a number of other arguments I could make against SSL, but
> that one is probably sufficient— or rather, it's an argument that we
> should have some way of cheaply getting non-reputable signatures
> regardless of the transport)

Exactly. Implement an SSL-protected transport, and leave non-repudiation
and broader issues of node identity as a later, long-term project. Many
client won't even want to support all that complexity, but they'll still
want to cheaply get the advantages SSL has with regard to MITM
resistance and privacy with little effort.

Anyway, the concept of a per-node identity keypair is the first step
towards non-repudiation, and implementing SSL transport.

> couple attempts it can be minutes before it gets a connection. We're
> short on onion peers and I sometimes get inbound connections before I

I run a fast node on EC2 that only accepts inbound connections over Tor
and I regularly have about ~50 inbound peers.

-- 
'peter'[:-1]@petertodd.org
0000000000000042d8b5bc3ca04847f711b82b66f08b7360a565ebd0b131621c

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2013-05-06 17:53 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 [this message]
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=20130506175331.GB22505@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