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; 
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)
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
Precedence: list


--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--