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
174
175
176
177
178
|
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 <adam.back@gmail.com>) id 1UZQDG-0003zv-Ol
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 18:32:38 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.177 as permitted sender)
client-ip=209.85.215.177; envelope-from=adam.back@gmail.com;
helo=mail-ea0-f177.google.com;
Received: from mail-ea0-f177.google.com ([209.85.215.177])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UZQDE-0003Lr-Sj
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 18:32:38 +0000
Received: by mail-ea0-f177.google.com with SMTP id o10so1844750eaj.22
for <bitcoin-development@lists.sourceforge.net>;
Mon, 06 May 2013 11:32:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-received:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition
:content-transfer-encoding:in-reply-to:user-agent:x-hashcash
:x-hashcash:x-hashcash:x-hashcash;
bh=Gqjra9io9loEdnwwDs7r7gQ3bKal07pkPYynDik9rl4=;
b=pOCq41nITgcdL3Wm/fkxLa/VQg1RXunMIyssXYEuZ7YOyAM8KN+fzlNWUDuHbLHxOK
w3Yqa/MTL0vxipLVBMvsCdeRjxG2gkylwkKzI57Xm4YOAW17PrpGlopMCj3rYsMy+lLd
eki1BbzmXDDF+2RkmXP+D+3JaVZTUwURCVCu4g30X12nELvNvT+LqM79NZHy6ZIJbhi+
v+x7Jdfprnoe/PFO2+J2zr6NBKcq5UrMfM6CqsgL9twnaVm6pZ4zW1xg6IrryXI7dTOn
yAPXxtcTlF5glrHLSv2UTj4Hr3vfjB2XgIVsfGMIM6HJJn6JTpk7FdUUOptVHBSd+9aC
eLMw==
X-Received: by 10.14.22.7 with SMTP id s7mr63429817ees.32.1367865150490;
Mon, 06 May 2013 11:32:30 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id
e50sm34902127eev.13.2013.05.06.11.32.28 for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 06 May 2013 11:32:29 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id 66EF82E064D; Mon, 6 May 2013 20:32:25 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Mon, 6 May 2013 20:32:22 +0200
Date: Mon, 6 May 2013 20:32:22 +0200
From: Adam Back <adam@cypherspace.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20130506183222.GB3797@netbook.cypherspace.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: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAS2fgQWnZ_yPA7G4LNwk655CxTD9WZf0f-cb5xd3TFzpBB2_g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130506:gmaxwell@gmail.com::ruK3tBDPeMacaiRX:0000000000000000000
0000000000000000000000001ybA
X-Hashcash: 1:20:130506:pete@petertodd.org::jjBEuJH0OfLIRsSl:0000000000000000000
0000000000000000000000009lZD
X-Hashcash: 1:20:130506:bitcoin-development@lists.sourceforge.net::7q2dJO4aYDap9
hn2:000000000000000000002X9l
X-Hashcash: 1:20:130506:adam@cypherspace.org::ja5UjgkUaU9WBkgo:00000000000000000
0000000000000000000000005D2D
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1UZQDE-0003Lr-Sj
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:32:38 -0000
btw with nodes for transport security you might use self-certifying keys.
Referring to Zooko's triangle, then the key is the node identity. Similar
to a bitcion address. So then just another ECDSA key and use emphemeral
ECDH for transport authenticated with the nodes key.
Maybe there can be some value to reputation to a node - eg it can charge a
higher micropayment for its p2p network services, a node with a good
reptuation could charge a higher micropayment for relaying (though bitcoin
itself probably doesnt like micropayments as bloating the transaction log).
Another ZKS era idea I had was to have a gossip protocol for users to find
out what other people think about the trustworthiness and reliability of
nodes. If that info is distributed via gossip over multiple channels and
network connections over time, and kept in something like a gnutella host
cache (just a cache of random info with some eg random replacement policy)
it becomes very hard for a dishonest node to censor evidence of its low
reputation.
It is best as Gregory said to be able to directly prove, and punish by
block-chain validation, because that is more smart-contract like. Bisbehave
and nodes wont connect to you or lose somehow.
But what exactly could you prove about a node? You dont really know if a
node is an originator for a double spend, it could be relay. And for
privacy and security you cant expect the node to use its coin address
private key.
Hmm: maybe one could use a Brands private credential with offline double
spend detection, with the reputation but not coin address of the node
disclosed, and the nodes coin address embedded in the proof. Each node
could be is own CA, providing a ZKP. If the node ever double spends a coin,
it loses its reputation as the coin address is revealed.
btw another old idea was to require proof of the existance of the private
key of a high value coin in the double-spend revealed information. Then
basically to get a higher good-behaviour bond, the node ties up more coins,
and if a node cheats, the first person to discover this collects the
forfeited good behaviour bond.
Adam
ps I have an opensource openSSL based Brands (& Chaum) credential library at
http://www.cypherspace.org/credlb/ I didnt actually implement the ECDL
version, just the DL version, but that is not so hard, and its on my todo
list. (There is also a strong RSA assumption version, also not
implemented).
On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote:
>> 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— the limited
>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— I'd argue that non-repudiation is always useful when there is
>trust. It's things like fidelity bonds— a trust generator that depend
>on automatic enforcement— 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.
>
>------------------------------------------------------------------------------
>Learn Graph Databases - Download FREE O'Reilly Book
>"Graph Databases" is the definitive new guide to graph databases and
>their applications. This 200-page book is written by three acclaimed
>leaders in the field. The early access version is available now.
>Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
