Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.182 as permitted sender)
	client-ip=209.85.217.182; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f182.google.com; 
MIME-Version: 1.0
In-Reply-To: <20130506175331.GB22505@petertodd.org>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
	<20130506161216.GA5193@petertodd.org>
	<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
	<20130506163732.GB5193@petertodd.org>
	<CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
	<20130506171943.GA22505@petertodd.org>
	<CAAS2fgQDa463Xb=D64LDenGn=mX+OXvD_bG=jXGYLnhFbgknsw@mail.gmail.com>
	<20130506175331.GB22505@petertodd.org>
Date: Mon, 6 May 2013 11:01:22 -0700
Message-ID: <CAAS2fgQWnZ_yPA7G4LNwk655CxTD9WZf0f-cb5xd3TFzpBB2_g@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
 for pruned nodes)
Precedence: list

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 su=
re
> 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.

> 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=E2=80=94 the limite=
d
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.

But without non-repudiation the ability to tie reputation to good
behavior is fairly limited especially if they perform targeted
attacks. "Wasn't me"

Instead=E2=80=94 I'd argue that non-repudiation is always useful when there=
 is
trust. It's things like fidelity bonds=E2=80=94 a trust generator that depe=
nd
on automatic enforcement=E2=80=94 that are only useful with fraud proofs.

> 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.