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
|
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 <adam.back@gmail.com>) id 1UceSU-000445-0J
for bitcoin-development@lists.sourceforge.net;
Wed, 15 May 2013 16:21:42 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.41 as permitted sender)
client-ip=74.125.83.41; envelope-from=adam.back@gmail.com;
helo=mail-ee0-f41.google.com;
Received: from mail-ee0-f41.google.com ([74.125.83.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UceSS-0001Qj-Si
for bitcoin-development@lists.sourceforge.net;
Wed, 15 May 2013 16:21:41 +0000
Received: by mail-ee0-f41.google.com with SMTP id d4so1166262eek.14
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 May 2013 09:21:34 -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:in-reply-to
:user-agent:x-hashcash:x-hashcash:x-hashcash;
bh=uMOdF69yCDNEYMF/tTH2UyOx4baJlfvZlEEyAQUT+dM=;
b=XVVYvEtc1g96aDfyMGTqi1le4Bw94khE7os35DYoKh8tyAOctD/KF4Sa9qCvwWIikZ
H+EaK/fJgVTYheJhen5zREOtL4NB0BRCnWsYXQeCEIbPbCXOGpZWQvnNtLYHuErDzNrq
ngB5DM2w/AGjPbE4tknL5OYCUwz7HGU87qb9VPW2KkxB0x15Uhc1t8vYTJ13R22wARO7
C43/IkGExjX41V1xC4Ia4l1/aHmeVFVCU4Q3MtPShAg2gddQAtyGYAtaWnPTL3EuZ9Za
dt7jx/wa1bpiJko2WtwI2066paGXT2O7+CvFYaogqZGeRr8sTRnZfvWfQboxrVhutNUM
DKRA==
X-Received: by 10.15.24.136 with SMTP id j8mr104322806eeu.39.1368634894516;
Wed, 15 May 2013 09:21:34 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id l6sm4941927eem.9.2013.05.15.09.21.32
for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 15 May 2013 09:21:33 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id A118E2E04CB; Wed, 15 May 2013 18:21:30 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Wed, 15 May 2013 18:21:29 +0200
Date: Wed, 15 May 2013 18:21:29 +0200
From: Adam Back <adam@cypherspace.org>
To: Caleb James DeLisle <calebdelisle@lavabit.com>
Message-ID: <20130515162129.GB6156@netbook.cypherspace.org>
References: <20130514115151.GA21600@netbook.cypherspace.org>
<20130514140902.GA22447@netbook.cypherspace.org>
<20130515102509.GA3401@netbook.cypherspace.org>
<20130515111906.GA26020@savin>
<20130515114956.GA5863@netbook.cypherspace.org>
<5193825B.20909@lavabit.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <5193825B.20909@lavabit.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130515:calebdelisle@lavabit.com::6x94A6DxufNk8P2d:0000000000000
0000000000000000000000000au2
X-Hashcash: 1:20:130515:bitcoin-development@lists.sourceforge.net::BTRZJO8xiI4XE
Fa2:000000000000000000002tyB
X-Hashcash: 1:20:130515:adam@cypherspace.org::5+0e1QkpyJlO56dt:00000000000000000
0000000000000000000000000DNK
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: 1UceSS-0001Qj-Si
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] blind symmetric commitment for stronger
byzantine voting resilience (Re: bitcoin taint & unilateral revocability)
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: Wed, 15 May 2013 16:21:42 -0000
On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote:
>If the commitment is opaque at the time of inclusion in the block then
>I will create multiple commitments and then after revealing the
>commitment and spend to you I will reveal the earlier commitment which
>commits the coins to an address I control.
Bit-commitments are based on deterministic one-way functions eg like SHA1(
SHA256( public key ) ) Obviously it has to be a different one-way function
to the coin address calculation which is RIPEMD( SHA256( public key ) ) as
that is already public. Alternatively it can be a different serialization
using the same hash eg RIPEMD( SHA256( 1 || public key ) ).
There is only one commitment possible per public key - so you can only
create one commitment that would validate to a receiver, or to the network.
The network checks that there are no non-blind double spends of committed
coins which it can do as spends require disclosure of the public key, which
allows existing commitments to be verified, and it similarly qchecks that
there are no blind double-commitments.
Each committed coin would be:
one-spend-commit = Com( spender pub ), Com( transaction )
where Com is implemented as the above hash. The network just places the
commitments in order as with conventional transactions.
The committed coins are not linkable to your non-blind coin because you did
not reveal your public key in the (largely passive) act of receiving to a
coin address.
>On the topic of reversibility, I suspect in the long term the lack of
>chargebacks will create issues as criminals learn that for the first
>time in history, kidnap & ransom is effective.
The temporary unlinkability (until commitment reveal) is a necessary side
effect, not a cryptographic anonymity feature like zerocoin. The
transactions are identical to bitcoins once revealed. How long the
committed transaction chains can be between reveals is an implementation
choice could be 1 hop, or as long as you like. (Actually it appears to be
up to the individual users how long the maximum chain they accept is - the
network itself, though ordering the committed spends (if there are multiple
spends on the same key) cant even tell how long the commitment payment
chains are).
Obviously the first coins in the network ordered committed coins on the same
key up to the coin value are spends as verified by the recipient, the rest
are double-spend and ignored. If someone wants to waste fees by sending
more spends than there inputs thats up to them.
Probably the typical user doesnt care about long committed chains other
than their wallet will bloat if the chains are too long, so probably they
would periodically compact it by revealing the long chains. Committed coins
are probably a bit less SPV client friendly, though with correct formatting
in the merkle trees between blocks, probably a committed coin holder can
provide enough proof to an SPV client to verify even multi-spend committed
coins directly (without a network feed).
About privacy, up to the entire commitment chain can be opened at any time
(to other people or to the bitcoin network in general) with the cooperation
of any user on the chain (up to the point they saw it), so while the blind
commitment protocol is not vulnerable to a > 50% power quorum unilaterally
imposed policy (without even needing client updates), it is fully dependent
on the good will of the recipients for its temporary unlinkability. Thats
the point: it puts policy control in the users hands not in the > 50% power
quorum.
If you want cryptographic anonymity its better to look to zerocoin. You may
have noticed zero coin talked about optional fraud tracing. Its usually
trivial to add tracing to an otherwise privay preserving protocol.
The blind commitment if implemented as described (and its not obvious how to
get more privacy from it) offers somewhat like community policing. Users on
the chain can still themselves do fraud tracing, or any policy they choose,
on any blind committed coins that they receive. If they dont like the
colour of them they can refund them. The point is to enforce that this is a
free uncoerced community choice, by individual end users, not a > 50% cpu
power quorum choice surreptitiously imposed.
Adam
|
