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
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <calebdelisle@lavabit.com>) id 1Ucg1D-0004mK-PE
for bitcoin-development@lists.sourceforge.net;
Wed, 15 May 2013 18:01:39 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of lavabit.com
designates 72.249.41.33 as permitted sender)
client-ip=72.249.41.33; envelope-from=calebdelisle@lavabit.com;
helo=karen.lavabit.com;
Received: from karen.lavabit.com ([72.249.41.33])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Ucg1C-0000if-Mg for bitcoin-development@lists.sourceforge.net;
Wed, 15 May 2013 18:01:39 +0000
Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10])
by karen.lavabit.com (Postfix) with ESMTP id 53E9E11C271
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 May 2013 13:01:33 -0500 (CDT)
Received: from 192.168.1.3 (c-174-62-136-247.hsd1.ct.comcast.net
[174.62.136.247]) by lavabit.com with ESMTP id P3KFT4A9SLYN
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 May 2013 13:01:33 -0500
Message-ID: <5193CD7B.4000102@lavabit.com>
Date: Wed, 15 May 2013 14:01:31 -0400
From: Caleb James DeLisle <calebdelisle@lavabit.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130404 Thunderbird/17.0.5
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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>
<20130515162129.GB6156@netbook.cypherspace.org>
In-Reply-To: <20130515162129.GB6156@netbook.cypherspace.org>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [72.249.41.33 listed in list.dnswl.org]
2.1 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Ucg1C-0000if-Mg
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 18:01:40 -0000
On 05/15/2013 12:21 PM, Adam Back wrote:
> 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 ) ).
Ahh thanks for clearing that up, although it would limit the possibilities
of scripting it is silly of me not to think of it.
>
> 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.
That is indeed interesting. If I understand this properly Alice commits coins
to pay to Bob and gives Bob the transaction, Bob then commits to pay to Charlie
and gives him the related transaction. If Charlie wants to collect the bitcoin
he then reveals Alice's transaction and Bob's.
I think what you're trying to do is *almost* possible now (ab)using BIP-0016
In the output of the previous tx you put:
OP_HASH160 [20-byte-hash-value] OP_EQUAL
and in the next tx you use a new type of input which specifies it's value but
not the output which is spent. In the input script you place:
OP_DUP OP_1ADD OP_HASH160 [20-byte-hash-value] OP_EQUALVERIFY
Then a serialized script containing the normal stuff as well as the last
transaction hash and output index would be passed around out of band and the
validating nodes would execute each script with a shared stack, beginning with
the out of band one, then the input one (the OP_EQUALVERIFY) then the output.
When the serialized sigscript reaches the bottom of the stack, having been
verified twice, it will now be evaluated as per the rules of P2SH.
None of this probably works in the real world since I'm not familiar with the
actual implementation of P2SH and it probably has quite a number of things
which will break if used this way but it is interesting to see that in theory
it is possible with little change to the protocol (just a new input format).
Thanks,
Caleb
>
> 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
>
|
