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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1UxdF3-0003Qg-QP
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Jul 2013 13:18:33 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.80 as permitted sender)
client-ip=62.13.149.80; envelope-from=pete@petertodd.org;
helo=outmail149080.authsmtp.com;
Received: from outmail149080.authsmtp.com ([62.13.149.80])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UxdF1-0002xH-OZ for bitcoin-development@lists.sourceforge.net;
Fri, 12 Jul 2013 13:18:33 +0000
Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226])
by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r6CDILvf081859; Fri, 12 Jul 2013 14:18:21 +0100 (BST)
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6CDIGGY059450
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 12 Jul 2013 14:18:18 +0100 (BST)
Date: Fri, 12 Jul 2013 09:18:15 -0400
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20130712131815.GA18716@petertodd.org>
References: <20130705140140.GA23949@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk"
Content-Disposition: inline
In-Reply-To: <20130705140140.GA23949@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 84d1bd1c-eaf5-11e2-98a9-0025907ec6c5
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwAUEkAYAgsB AmUbWlBeUVV7WGo7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxpy cmdpJXBycgxCfX4+ ZE9nV3AVVEAudBQp
Qx1JQDxQYHphaTUd TUlQJgpJcANIexZF bQUsUiAILwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDGj82 VR0YGj4oHEtNXSg3
IhU9J1JYVFkRO1l6 OFEmRE5QOn1aGABE GEpKASkcIF8FVmIi
CR8fVkkfFnVCQDtc ShApPh9FGHlVQGJd BU1ETR5n
X-Authentic-SMTP: 61633532353630.1020:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1UxdF1-0002xH-OZ
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] libzerocoin released,
what about a zerocoin-only alt-coin with either-or mining
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: Fri, 12 Jul 2013 13:18:34 -0000
--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 05, 2013 at 04:01:40PM +0200, Adam Back wrote:
> Do people think that should work? It seems to me it should with minimal,
> bitcoin changes. I think the rule for either-or mining should be as simp=
le
> as skipping the value / double-spend validation of the blocks that are
> zerocoin mining blocks. Obviously zerocoin blocks can themselves end up =
on
> forks, that get resolved, but that fork resolution can perhaps be shared?=
=20
> (Because the fork resolution is simply to accept the longest fork).
Yeah, there's been a lot of doom and gloom about zerocoin that is
frankly unwarrented. For instance people seem to think it's impossible
to make a blockchain with zerocoin due to the long time it takes to
verify transactions, about 1.5 seconds, and never realize that
verification can be parallelized.
Anyway the way to do it is to get out of the model of large blocks and
think about individual transactions. Make each transaction into its own
block, and have each transaction refer to the previous one in history.
(zerocoin is inherently linear due to the anonymity)
Verification does *not* need to be done by every node on every
transaction. Make the act of creating a transaction cost something and
include the previous state of the accumulator as part of a transaction.
Participants verify some subset of all transactions, and should they
find fraud they broadcast a proof. Optionally, but highly recomended,
make it profitable to find fraud, being careful to ensure that it's
never profitable to create fraud then find it yourself.
Anyway Bitcoin is limited to 7tx/s average so even without probabalistic
verification it'd be perfectly acceptable to just limit transactions to
one every few seconds provided you keep your "blocksize" down to one
transaction so the rate isn't bursty. You're going to want to be
cautious about bandwidth requirements anyway to make sure participants
can stay anonymous.
As you suggest creating zerocoins from provably sacrificing bitcoins is
the correct approach. The consensus algorithm should be that you
sacrifice zerocoins (specifically fractions there-of - note how I'm
assuming support for non-single-zerocoin amounts) and whatever chain has
the highest total sacrifice wins. One way to think about
proof-of-sacrifice is it's really proof-of-work, transferred. It also
has the *big* advantage that to double-spend, or for that matter 51% the
chain, you have to outspend everyone with a stake in the viability of
the blockchain: they can sacrifice their zerocoins to combat you. In the
case of a double-spend to rip off an online merchant the total amount
you could profit is the same as the total amount they would rationally
spend to stop you, and soon there will be collateral damage too
increasing the amount third-parties are willing to sacrifice to stop
you. You can't win.
Of course, this does mean that even unsuccesful sacrifices need to be
costly. You can make this acceptable to users by allowing a sacrifice to
be reused, but only for the exact same transaction it was originally
committed to.
Sacrifices in this manner are *not* proof of stake. You really are
giving up something by publishing the information that proves you made
the sacrifice as that information can always be included in the
consensus thereby taking away a limited resource. (your zerocoins) It's
more heavily dependent on jam-free networks, and doesn't play nice with
SPV, but zero-knowledge proofs will may help the latter. (you've got
Bitcoin itself to act as a random beacon remember)
Speaking of, another similar approach is to take advantage of how a
Bitcoin sacrifice can be made publicly visible. Create a txout of some
value like the following:
OP_RETURN <prev-ztc-blockhash> <blockhash> <ztc-created>
Now even if you fail to publish your blocks, at least the whole world
knows how much they need to outspend to be sure you can't 51% attack the
network. This approach and not-btc sacrifices can go hand in hand too,
especially if nodes follow rules where they consider btc txout
sacrifices as "fixed" and only subject to change by the bitcoin
blockchain re-organizing. Advantages and disadvantages to both
approaches. (remember that visible tx's can be censored by miners)
Sacrifice to mining fees may be acceptable in the future too, but only
if OP_DEPTH is implemented so as to not give Bitcoin miners bad
incentives. (the sacrificed coins should go to fees *months* or even
*years* after they have been sacrificed)
Turning zerocoins back into Bitcoins is just supply and demand: sell
them. You'll always lose a bit given by definition the maximum exchange
rate is 1:1, but anonymity may be worth it. Others have written about
cross-chain trading protocols, and I'll point out they are easier to
implement if one chain has full visibility into what's happening on the
other; zerocoin is most likely to be implemented as an extension to the
bitcoin client itself.
Finally if the transaction rate is too slow there's nothing wrong with
running multiple parallel zerocoin blockchains, although given the
usecase of moving your funds through zerocoin for anonymity, and using
the clean coins that come out the other side, there's no reason to think
the zerocoin chain transaction rate needs to be especially high anyway.
--=20
'peter'[:-1]@petertodd.org
0000000000000013b2f7ee77027f583b765ad9811dfe3d0adc801e295fd9acdf
--UugvWAfsgieZRqgk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEUEARECAAYFAlHgAhcACgkQpEFN739thoy9KwCY82NEZkksUXqm/fZ7HTD0vDV9
SQCdF83ByUuEVAD9bi4qagLEAjcmDX0=
=etSs
-----END PGP SIGNATURE-----
--UugvWAfsgieZRqgk--
|
