summaryrefslogtreecommitdiff
path: root/b1/d116e4064895a799e30b81a5f9b4920adb7a91
blob: 8e7dc4ac170deaec8afcfa71a37dfd03d1340789 (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
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1UZQml-000866-JH
	for bitcoin-development@lists.sourceforge.net;
	Mon, 06 May 2013 19:09:19 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.55 as permitted sender)
	client-ip=62.13.149.55; envelope-from=pete@petertodd.org;
	helo=outmail149055.authsmtp.co.uk; 
Received: from outmail149055.authsmtp.co.uk ([62.13.149.55])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UZQmh-00073M-61 for bitcoin-development@lists.sourceforge.net;
	Mon, 06 May 2013 19:09:19 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
	r46J9398087604; Mon, 6 May 2013 20:09: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 r46J8vQD051882
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 6 May 2013 20:08:59 +0100 (BST)
Date: Mon, 6 May 2013 15:08:57 -0400
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20130506190857.GA23095@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>
	<20130506183222.GB3797@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline
In-Reply-To: <20130506183222.GB3797@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 68a202be-b680-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdgQUFVQNAgsB AmUbWVReUFR7WWM7 ag1VcwRfa1RMVxto
	VEFWR1pVCwQmQxgH fBZYM21ycgROcHw+ ZE9hV3YVWkwrd0Z/
	EBtJR2sOZXphaTUd 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: 1UZQmh-00073M-61
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 19:09:19 -0000


--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 06, 2013 at 08:32:22PM +0200, Adam Back wrote:
> 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.

re: double-spends - punishing relay nodes and miners for them is a very
bad idea. Ultimately it is the blockchain by which Bitcoin comes to
consensus about what transactions belong in the blockchain - to punish
double-spends implies a second consensus mechanism. Anyway it's
unnecessary: you can hold the actual spender accountable for
double-spends and punish them directly rather than adding a lot of
complexity and dangerous assumptions about propagation to the Bitcoin
core network.


Some useful things you can hold relay nodes accountable for without a
lot of complexity:

1) Having a reasonably correct view of the best block. Make the node
sign a statement including a block hash sequence (the last 3-6 blocks)
and what it believes the current time is.

2) Accurate knowledge of the blockchain. Sign a statement claiming that
what block hash is for a given chain height. Note that due to reg-orgs
this is actually a different statement than #1 and nodes should be
careful what they are claiming.

3) Accurate knowledge of the UTXO set. Sign a statement claiming that
a given txid:vout for the current best block hash is in or not in the
UTXO set.

4) Accurate bloom filtering; same idea as #3

5) Make the node identity expensive to obtain. For instance, construct
PoW's including the node pubkey somehow, or purchase fidelity bonds for
the node's identity. Makes sybil attacks more difficult, among other
things.

5) Provide useful propagation/mining services. Sign a txid and
timestamp/blockhash-sequence, and hold the node accountable for how long
it takes the txid to make it into the blockchain. Useful especially for
miners offering the service of mining your transaction.


> 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 co=
in,
> it loses its reputation as the coin address is revealed.

Be careful not to mix up the concept of a relay node with someone
posessing Bitcoins. Node's don't spend coins, people/wallets do.

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

That stuff is cool, but we should focus first on simple efforts, like
SSL transport, that do not require complex cryptography to obtain an
improvement in security.

Of course, not to say long-term research is bad, but that's just not
going into the Bitcoin reference client in the near future.

--=20
'peter'[:-1]@petertodd.org
0000000000000124d42390b0db4c125f6be87835c49dc88f1bdeba527b77abc2

--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iEYEARECAAYFAlGH/8kACgkQpEFN739thoy0RgCfXD28ySqfhKT4V1ge851h6nPr
ZRkAn1vv5TMLkyvl5uETgqxmUVz4qxgn
=CfHQ
-----END PGP SIGNATURE-----

--PEIAKu/WMn1b1Hv9--