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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <simon@superduper.net>) id 1UcGD7-0005xs-CY
for bitcoin-development@lists.sourceforge.net;
Tue, 14 May 2013 14:28:13 +0000
X-ACL-Warn:
Received: from masada.superduper.net ([85.119.82.91])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1UcGD2-0004AF-Ba
for bitcoin-development@lists.sourceforge.net;
Tue, 14 May 2013 14:28:13 +0000
Received: from 199-83-222-6.public.monkeybrains.net ([199.83.222.6]
helo=[192.168.0.13]) by masada.superduper.net with esmtpsa
(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
(envelope-from <simon@superduper.net>)
id 1UcGCu-00075K-AP; Tue, 14 May 2013 15:28:01 +0100
Message-ID: <519249EE.5050001@superduper.net>
Date: Tue, 14 May 2013 07:27:58 -0700
From: Simon Barber <simon@superduper.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Adam Back <adam@cypherspace.org>
References: <20130514115151.GA21600@netbook.cypherspace.org>
<20130514140902.GA22447@netbook.cypherspace.org>
In-Reply-To: <20130514140902.GA22447@netbook.cypherspace.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.9 (--)
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1UcGD2-0004AF-Ba
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>,
Xavier Boyen <xb@cs.stanford.edu>
Subject: Re: [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:28:13 -0000
Adam,
Take a look at this privacy enhancing solution based on fair exchange
implemented by bitcoin contracts and cut-and-choose. It would require a
public pool of users willing to exchange in common denominations at
moments in time together to ensure unlinkability. It also leave a trace
of exchange activity in the chain. This could all be added to wallet
software to become automatic.
http://robotics.stanford.edu/~xb/fc12/index.html
Simon
On 05/14/2013 07:09 AM, Adam Back wrote:
> 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
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
