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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1UyWfW-0006Lp-Mc
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jul 2013 00:29:34 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.107 as permitted sender)
client-ip=62.13.148.107; envelope-from=pete@petertodd.org;
helo=outmail148107.authsmtp.com;
Received: from outmail148107.authsmtp.com ([62.13.148.107])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UyWfV-0007UG-GH for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jul 2013 00:29:34 +0000
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt12.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r6F0TQwR070774; Mon, 15 Jul 2013 01:29:26 +0100 (BST)
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6F0TK9G010739
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 15 Jul 2013 01:29:23 +0100 (BST)
Date: Sun, 14 Jul 2013 20:29:20 -0400
From: Peter Todd <pete@petertodd.org>
To: John Dillon <john.dillon892@googlemail.com>
Message-ID: <20130715002920.GB18773@savin>
References: <20130705140140.GA23949@netbook.cypherspace.org>
<20130712131815.GA18716@petertodd.org>
<CAC1+kJOerE75+rtMHiy27aDLwWC9juAYva4u_iMVihnePTOYig@mail.gmail.com>
<20130713184227.GA5902@netbook.cypherspace.org>
<CAC1+kJMyvKnUKm8xTjzUK_5iq_VZM=iX17aCCd9vqe7jsYUJfQ@mail.gmail.com>
<CAPaL=UVmr1zng6QtngkY-Y+fP+E67NST7MYRpkSHfjtwZ7PFNw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2"
Content-Disposition: inline
In-Reply-To: <CAPaL=UVmr1zng6QtngkY-Y+fP+E67NST7MYRpkSHfjtwZ7PFNw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 99855573-ece5-11e2-b10b-0025903375e2
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwcUEkAYAgsB AmUbW1VeUlR7W2c7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqB2oB YmUXJRlzdwJFcTBx YEdrXD5SVUx/cEN6
QVMBRjgDeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4PHzQu SgoFFjIuGwUfSiE+
JgcrJhpUA0YYLg07 O1w8RRoRUVcABxdZ FEZMBmpeIV0QDyMv
EUZRWk8YWCJcXScU Dxw0IhJSRztIEi9Z AkpDRHkA
X-Authentic-SMTP: 61633532353630.1019:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/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: 1UyWfV-0007UG-GH
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: Mon, 15 Jul 2013 00:29:34 -0000
--7ZAtKRhVyVSsbBD2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jul 14, 2013 at 07:22:10PM +0000, John Dillon wrote:
> Peter: I'm a bit confused by this concept of "bi-directional sacrifice" t=
hough,
> I assume there exists only a sacrifice in one direction right? Wouldn't s=
elling
> a zerocoin be just a matter of giving zerocoin a rule so that the zerocoi=
n tx
> moving it to the new owner only happens if a specific form of bitcoin tx
> happens too?
Exactly.
Basically you have one way of creating a Zerocoin: prove you sacrificed
a Bitcoin in a specific way. (spend to unspendable, or spend to mining
fees far into the future)
Now when you sell a Zerocoin what you do is create a Zerocoin
transaction with a txout that can only be spent if you can prove that a
Bitcoin transaction exists with specific conditions with sufficient
confirmations. The specific condition would most likely be it has a
txout of a specific value and scriptPubKey. Basically you'd have a
two-part scriptPubKey:
if <check bitcoin txout existance proof> <check zerocoin buyers signature
is correct> else <check zerocoin sellers signature is correct> <check n
blocks have passed>
Note how if the buyer screws up there is a fallback so the seller can
retrieve their funds after some reasonable amount of time.
Of course if the Bitcoin chain is re-orged Bad Things Happen(TM), but
just set the required number of confirms to something reasonable and
you're good to go. It does mean Zerocoin needs to have consensus on the
Bitcoin blockchain, but that's required to verify sacrifice proofs
anyway.
Economically the idea works because Zerocoins are gradually consumed by
the proof-of-sacrifice required to make Zerocoin transactions. If the
process by which Bitcoins are sacrificed is to fees, rather than
permanently, the overall affect is just a minor decrease in the Bitcoin
money supply. If they are sacrificed permanently, it'll result in
long-term Bitcoin deflation - potentially an issue as the blockreward
decreases.
--=20
'peter'[:-1]@petertodd.org
--7ZAtKRhVyVSsbBD2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJR40JfAAoJECSBQD2l8JH7lzIIAKAOHn8vC4nfAOylW434FBuo
x/Y90jIMuXbLv9R6Q4czCI28NSaF2lrR1z3hYZXpVKKTT0RjULS0Tue2FunF7n3I
GQ1VSSTS4Gmdx6o+T1nD8f2Uyzee8NP634Y1CayTyCxP4YMj72dW//fj7NHv5byT
ken3IVXMn09o3JEoiOeYPQYXWRv9UBaTNbIptgUPKsUWx1rnkfo4oL+B4F6SMb7z
X4qc4RIXOAI7u4Jbqv7Caf4JDCtHYuVN03YbJyi5wyfMhLs11ec6fRbnuSZOM/js
ReENHEVGo2D/2HBq+aMXOksbv6abLzVcGHT1CRt/x+HDADGu81AyqicK8EFJENo=
=XbAN
-----END PGP SIGNATURE-----
--7ZAtKRhVyVSsbBD2--
|
