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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1UcFup-0005OA-4i
for bitcoin-development@lists.sourceforge.net;
Tue, 14 May 2013 14:09:19 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.50 as permitted sender)
client-ip=74.125.83.50; envelope-from=adam.back@gmail.com;
helo=mail-ee0-f50.google.com;
Received: from mail-ee0-f50.google.com ([74.125.83.50])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UcFul-0007RH-GQ
for bitcoin-development@lists.sourceforge.net;
Tue, 14 May 2013 14:09:19 +0000
Received: by mail-ee0-f50.google.com with SMTP id c41so375018eek.23
for <bitcoin-development@lists.sourceforge.net>;
Tue, 14 May 2013 07:09:09 -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;
bh=Q7GEiSM82+oWKHNlif+Zalp6DNl3aAgdYo3xs0cmQY0=;
b=UkuC8A5GyiXwizNvltYtIEkI/PF5lrxdfqf7hAgh8LoTPgNuxq+HwtlLr/H+g7jJw8
6sjVV5QCu6RbJmAH+eKVr58iR7xJzaj4VuPHI2BHh0ysfIy4AOjtkAjUZD58tEpDg4WE
GFFrhXCrdFigyGPIB5rumxyC5aMwz9uILufYWxD0NblSOd22TzSYGwnf3jflq+q30AIu
A8EnpqAxO+ZibqMCr+u6w1bu5uy1Y7h88i9ttBIieVyOh3ooUirv5H3cKTqptLxjFQP5
uNacMU8TDMpE/+eo1+Qpt0uQSUAtutH+y3deci08RLQQ+Vwm+8NDDzrR0J3AlROB1h/0
2ZTg==
X-Received: by 10.15.108.6 with SMTP id cc6mr31326470eeb.28.1368540549113;
Tue, 14 May 2013 07:09:09 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id n7sm29757296eeo.0.2013.05.14.07.09.06
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 14 May 2013 07:09:07 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id 7EDC12E05AB; Tue, 14 May 2013 16:09:05 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Tue, 14 May 2013 16:09:03 +0200
Date: Tue, 14 May 2013 16:09:02 +0200
From: Adam Back <adam@cypherspace.org>
To: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20130514140902.GA22447@netbook.cypherspace.org>
References: <20130514115151.GA21600@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20130514115151.GA21600@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130514:bitcoin-development@lists.sourceforge.net::cMQYUkDs7F13A
3ao:000000000000000000005uXr
X-Hashcash: 1:20:130514:adam@cypherspace.org::MNFw7mLwUAzQ1iF4:00000000000000000
000000000000000000000000BRR/
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: 1UcFul-0007RH-GQ
Subject: [Bitcoin-development] bitcoin taint & unilateral revocability (Re:
ecash and 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: Tue, 14 May 2013 14:09:19 -0000
On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote:
> Adam Back in Sep 1999, cypherpunks list:
>>I wouldn't say ecash has to use blinding, but I would argue it would be a
>>misuse of the word "ecash", if something which was revocable were dubbed
>>ecash.
So I still think that is an important point. "Ecash should not be
revocable". I think bitcoin currently has a partial problem because of
taint.
Now blinding based unlinkability, in a distributed cryptographic payer/payee
anonymous system like Sander & Ta Shma [1] and zerocoin has so far been
based on ZKP of set membership. Of course that is somewhat expensive,
though zerocoin improved the ZKP with an relatively efficient (but still
cut-and-choose) proof.
Bitcoins relative lack of privacy creates a problem with tainted coins
risking becoming unspendable, or spendable only with some users, or at a
discount. So while the policy coded says all coins are equally acceptable,
the information exists so people can unilaterally reject them, depending on
what the taint is. So far revocability hasnt reared it's head that I heard,
nor taint inspection too much? However people have the choice and technical
means to check the taint and send the bitcoins back.
Another aspect is that bitcoin, like systemics sox/digigold, makes a
different privacy tradeoff. Somewhat private, but not very much.
But it creates the question: could the taint issue be fixed efficiently (eg
even without blinding or ZKP of set membership?)
One related concept is commitments. I think its relatively easy to commit
to a payment and lock a coin without identifying yourself, until the
commitment is released. You might do the commitment, wait 6-blocks for
confirmation, then reveal the commitment. Then that is like a self-issued
green coin with no need for trust, that can be immediately cleared. The
recipient has to be committed to at the same time to prevent double
spending.
So just commit = H( input-pub ) H( transaction ) and put it in the block
chain. Where transaction the is usual ( input signature, output-pub,
script). (Fee for the commit would have to come from an unlinked coin or
the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction
(free because fee was already paid). Validators check input-pub hash
against committed coins by hash, check the transaction hash, and the usual
ransaction validations = sum inputs, otherwise reject. The user better pay
change if any to a different public key, as the inputs public keys are one
use - are after the reveal they are DoS lockable by other people reposting
H( input-pub ).
The input-pub coin is locked as normal transactions have their public key hash
validate as not being locked.
Adam
[1] Sander & Ta Shma "Auditable, Anonymous Electronic Cash"
http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf
|
