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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1UZQ1D-000360-Co
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 18:20:12 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.98 as permitted sender)
client-ip=62.13.148.98; envelope-from=pete@petertodd.org;
helo=outmail148098.authsmtp.com;
Received: from outmail148098.authsmtp.com ([62.13.148.98])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UZQ1C-0002du-7R for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 18:20:11 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt12.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r46IK3NT061623; Mon, 6 May 2013 19:20:03 +0100 (BST)
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 r46IK0uK006751
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 6 May 2013 19:20:02 +0100 (BST)
Date: Mon, 6 May 2013 14:19:59 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20130506181959.GC22505@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>
<CAAS2fgQWnZ_yPA7G4LNwk655CxTD9WZf0f-cb5xd3TFzpBB2_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="+xNpyl7Qekk2NvDX"
Content-Disposition: inline
In-Reply-To: <CAAS2fgQWnZ_yPA7G4LNwk655CxTD9WZf0f-cb5xd3TFzpBB2_g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 91cc2c49-b679-11e2-b5c5-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgQUFVQNAgsB AmUbWl1eUl17WWE7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxgH f2UeF2JydwNBfX8+ Z0ZjWngVVUUpJkQu
RkdJR2sBbHphaTUd TRJdJAZJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMj8n TBccEC8+WkQJSz97
NxUtKVMABw5RLUwp YxMaVEgGMhQfQgdf A1ovSCFePREZXTct
AA8SW0kSHSYcKQAA
X-Authentic-SMTP: 61633532353630.1023: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: 1UZQ1C-0002du-7R
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 18:20:12 -0000
--+xNpyl7Qekk2NvDX
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
>=20
> 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.
>=20
> 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 limi=
ted
> 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.
>=20
> 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.
--=20
'peter'[:-1]@petertodd.org
000000000000015ef6fc2fc45adc1de0c344e99a59453bb09ac470a1d02b787d
--+xNpyl7Qekk2NvDX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlGH9E8ACgkQpEFN739thoz/qQCdHSpb9whlOM9SuVXhYx6nTI3p
YbwAn2dNCwaNTmz2dfbRQZiDu7JFhDNb
=GhcJ
-----END PGP SIGNATURE-----
--+xNpyl7Qekk2NvDX--
|
