summaryrefslogtreecommitdiff
path: root/03/606acf65f97c8456c57cb78411c10724165e3e
blob: 14aef892f703154175e4a17cff374207e3f3093c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1UZPbg-0004IY-L2
	for bitcoin-development@lists.sourceforge.net;
	Mon, 06 May 2013 17:53:48 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.82 as permitted sender)
	client-ip=62.13.149.82; envelope-from=pete@petertodd.org;
	helo=outmail149082.authsmtp.co.uk; 
Received: from outmail149082.authsmtp.co.uk ([62.13.149.82])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UZPbf-0008UR-Ax for bitcoin-development@lists.sourceforge.net;
	Mon, 06 May 2013 17:53:48 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt14.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r46Hrerj008686;
	Mon, 6 May 2013 17:53:40 GMT
Received: from petertodd.org (petertodd.org [174.129.28.249])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r46HrVxn081173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 6 May 2013 18:53:34 +0100 (BST)
Date: Mon, 6 May 2013 13:53:31 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb"
Content-Disposition: inline
In-Reply-To: <CAAS2fgQDa463Xb=D64LDenGn=mX+OXvD_bG=jXGYLnhFbgknsw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: df37036b-b675-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdgQUFVQNAgsB AmUbWlxeVV57Wmc7 ag1VcwRfa1RMVxto
	VEFWR1pVCwQmQxgH flx4GkdyfwRHf30+ ZEJiW3IVCBJ5ckZ+
	RBxJR2sBYHphaTUd TRJZd1FJcANIexZF aVN4USYPLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMj8n TBccEC8+WkQJSz97
	NxUtKVMABw5RLUwp YxMaVEgGMhQfQgdf A1ovSCFePREZXTct
	AA8SW0kSHSYcKQAA 
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1UZPbf-0008UR-Ax
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
 for pruned nodes)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2013 17:53:48 -0000


--mxv5cy4qt+RJ9ypb
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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?
>=20
> 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=E2=80=94 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.

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

--mxv5cy4qt+RJ9ypb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlGH7hsACgkQpEFN739thoyRcwCfctytT/KH+KknfgJUY1uHc3Ey
1wYAmQG169jI9wMTu0iRqFEBMNtAVG1O
=0pZX
-----END PGP SIGNATURE-----

--mxv5cy4qt+RJ9ypb--