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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1UZPj7-0001kV-IX
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 18:01:29 +0000
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;
Received: from mail-lb0-f182.google.com ([209.85.217.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UZPj6-0004lZ-Py
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 18:01:29 +0000
Received: by mail-lb0-f182.google.com with SMTP id r11so3686342lbv.27
for <bitcoin-development@lists.sourceforge.net>;
Mon, 06 May 2013 11:01:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.37.196 with SMTP id a4mr8436765lak.55.1367863282120;
Mon, 06 May 2013 11:01:22 -0700 (PDT)
Received: by 10.112.35.43 with HTTP; Mon, 6 May 2013 11:01:22 -0700 (PDT)
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
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UZPj6-0004lZ-Py
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:01:29 -0000
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.
|
