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
|
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 <gmaxwell@gmail.com>) id 1UcoCM-0005V4-0S
for bitcoin-development@lists.sourceforge.net;
Thu, 16 May 2013 02:45:42 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.45 as permitted sender)
client-ip=209.85.215.45; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f45.google.com;
Received: from mail-la0-f45.google.com ([209.85.215.45])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UcoCK-0002xS-Tw
for bitcoin-development@lists.sourceforge.net;
Thu, 16 May 2013 02:45:41 +0000
Received: by mail-la0-f45.google.com with SMTP id ec20so2192497lab.18
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 May 2013 19:45:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.26.225 with SMTP id o1mr19444566lag.43.1368672334135;
Wed, 15 May 2013 19:45:34 -0700 (PDT)
Received: by 10.112.71.97 with HTTP; Wed, 15 May 2013 19:45:34 -0700 (PDT)
In-Reply-To: <CANEZrP2dFi-3nZhYpaA9RfJ8N2e-GQ_YQtKMdnFfPx-9YLU6MA@mail.gmail.com>
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>
<20130515234030.GA17920@netbook.cypherspace.org>
<BF1C6C71-9EE5-4A2F-8B73-3E8F934A7CAE@gmail.com>
<CAAS2fgQP6mFb0izQxZcBwqBWdxKUiAy1sG23ScAZ+tEMvGU0WQ@mail.gmail.com>
<CANEZrP2dFi-3nZhYpaA9RfJ8N2e-GQ_YQtKMdnFfPx-9YLU6MA@mail.gmail.com>
Date: Wed, 15 May 2013 19:45:34 -0700
Message-ID: <CAAS2fgQQk0Lhmon4FxK7NATDVkaY13DBmJgQk4riJLE1h_Ak0w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1UcoCK-0002xS-Tw
Cc: "bitcoin-development@lists.sourceforge.net"
<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: Thu, 16 May 2013 02:45:42 -0000
On Wed, May 15, 2013 at 7:22 PM, Mike Hearn <mike@plan99.net> wrote:
> Conceptually it sounds a lot like ZeroCoin (not in implementation)?
Zerocoin conceals the connection from everyone forever, assuming the
underlying trapdoor problem is computational infeasible, but at great
cost.
Adamcoin, depending on how its done, at most conceals the transactions
from people who aren't a party to them... though as time goes on
eventually everyone becomes a party to a sufficiently old coin, and
avoiding publication creates quadratic costs in evaluating a private
clique's claims.... so instead an implementation would make the
identities public but only once they're burred a bit.
Perhaps an extreme version of the idea is easier to understand. Ignore
DOS attacks for a moment and pretend there is never any address reuse:
Everyone creates txouts paying a P2SH addresses that have a OP_PUSH
nonce in them and tell you recipient the nonce out of band.
When the recipients spend those coins they provide the script but not the nonce.
The recipient knows what coins he's spending, but the public does not.
The public can tell there is no double spend though, because they'd
see the same script twice. The person he's paying may be skeptical
that he actually has any coin and didn't just mine some gibberish, but
our spender tells that their receiver the nonce, and that person can
see the coin available for spending in the chain and also see that
there are no double spends.
This could actually go on forever with no ambiguity over who owns
what, but the out of band proofs that you have to give people when you
spend coins would grow with the history of the coins.
Since there wouldn't be much privacy once a transaction was
sufficiently split up in any case, you instead just publish the
unblindings once transactions are sufficiently buried. Thus bounding
the growth of the proofs. The reason I say I need to internalize
this more is mostly that I need to think about attacks on the
publication for 'tained' transactions being more or less isomorphic
to just refusing to allow spending of the 'tainted' coins in any case.
|
