From: Peter Todd <pete@petertodd.org>
To: John Dillon <john.dillon892@googlemail.com>
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
Date: Sun, 14 Jul 2013 20:29:20 -0400 [thread overview]
Message-ID: <20130715002920.GB18773@savin> (raw)
In-Reply-To: <CAPaL=UVmr1zng6QtngkY-Y+fP+E67NST7MYRpkSHfjtwZ7PFNw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]
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" though,
> I assume there exists only a sacrifice in one direction right? Wouldn't selling
> a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin 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.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2013-07-15 0:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 14:01 [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining Adam Back
2013-07-12 13:18 ` Peter Todd
2013-07-13 9:51 ` Jorge Timón
2013-07-13 9:53 ` Jorge Timón
2013-07-13 18:32 ` Peter Vessenes
2013-07-15 9:51 ` Peter Todd
2013-07-15 13:05 ` Jorge Timón
2013-07-15 20:29 ` Peter Todd
2013-07-16 3:54 ` Peter Vessenes
2013-07-13 18:42 ` Adam Back
2013-07-14 11:18 ` Jorge Timón
2013-07-14 19:22 ` John Dillon
2013-07-14 19:33 ` Luke-Jr
2013-07-14 19:42 ` Pieter Wuille
2013-07-14 19:52 ` John Dillon
2013-07-14 20:16 ` Luke-Jr
2013-07-15 0:12 ` Peter Todd
2013-07-15 1:51 ` Luke-Jr
2013-07-15 1:59 ` Peter Todd
2013-07-14 19:48 ` John Dillon
2013-07-15 0:14 ` Adam Back
2013-07-15 0:29 ` Peter Todd [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130715002920.GB18773@savin \
--to=pete@petertodd.org \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=john.dillon892@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox