From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: John Dillon Message-ID: <20130715002920.GB18773@savin> References: <20130705140140.GA23949@netbook.cypherspace.org> <20130712131815.GA18716@petertodd.org> <20130713184227.GA5902@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline In-Reply-To: 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 else 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--