From: Adam Back <adam@cypherspace•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: Mon, 15 Jul 2013 02:14:37 +0200 [thread overview]
Message-ID: <20130715001437.GA21991@netbook.cypherspace.org> (raw)
In-Reply-To: <CAPaL=UVmr1zng6QtngkY-Y+fP+E67NST7MYRpkSHfjtwZ7PFNw@mail.gmail.com>
I think bi-directional sacrifice is probably not needed to assure a close to
1:1 bi-directional peg.
(Bi-directional sacrifice meaning also to convert a zerocoin to a bitcoin
you sacrifice a zerocoin and bitcoin would be modified to accept a zerocoin
sacrifice as a way to replace a previously sacrificed bitcoin).
I say that because if users who want zerocoins can obtain them at 1:1
exchange via sacrifice (a mathematical peg), it is of no additional cost to
them to instead buy them from someone who previously obtained them via
sacrifice for bitcoin (rather than sacrificing a new bitcoin). So
presumably for goodwill, or nominal fee (a small discount), people would buy
rather than sacrifice where there is availability.
Adam
On Sun, Jul 14, 2013 at 07:22:10PM +0000, John Dillon wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón <jtimon@monetize•io> wrote:
>> All the arguments in favor of this pegging use zerocoin's point of
>> view. Sure it would be much better for it, but are additional costs to
>> the bitcoin network and you cannot do it with every chain.
>
>Seems that Peter is describing a system that requires no changes at all to the
>Bitcoin codebase and thus there are no costs whatsoever.
>
>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?
>
>> Merged mining is not mining the coin for free. The total reward (ie
>> btc + frc + nmc + dvc) should tend to equal the mining costs. But the
>> value comes from demand, not costs. So if people demand it more it
>> price will rise no matter how is mined. And if the price rises it will
>> make sense to spend more on mining.
>> "Bitcoins are worth because it costs to mine them" is a Marxian labor
>> thory of value argument.
>> It's the other way arround as Menger taught us.
>
>Merge mining is very much mining a coin for free. Ask not what the total reward
>is, ask that the marginal cost of merge mining an additional coin is. The issue
>is that unless there is a cost to mining a *invalid* block the merge mined coin
>has little protection from miners who mine invalid blocks, either maliciously
>or through negligence. If the coin isn't worth much, either because it's market
>value is low or the worth is negative to the malicious miner, your theories of
>value have nothing to do with the issue.
>
>Gregory Maxwell has written about this issue before on the #bitcoin-dev IRC
>channel and on bitcointalk as well if memory serves. I advise you to look up
>his description of the problem, almost everything he writes on the topic of
>crypto-coin theory is spot-on correct.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.11 (GNU/Linux)
>
>iQEcBAEBCAAGBQJR4vpGAAoJEEWCsU4mNhiPwu0IAMrzkVfI0CQuNJRCR+jwhNts
>juEerApSSpBes6CjLBJJYZWDdMReSl6izqNDancnJygYc+Q5/IkwBispyZyeIVqY
>HbV+jyAFQeVaJBZp8N+ZUDfN9/35SkPb4Y30dkq6V76hBfl+59bWq4qG0dhiO915
>SBWAUPLspb5GOyu494GJUr4SPzgs9mAKfNGeQR2anOLj8Qam8Khfa4Zm5T5dX8WQ
>vBunUCLykPvWBC3nuTDBU5gQu4TGW9ivGB4p6yLr7MyaPQYZEnYGqgU/yIfAhnBj
>MfIfs6njPwhGMwteNmwLoS0VLRBFjWZDflquJ0NK6mNLR3c9yjOFMFPTTZFVinQ=
>=b40P
>-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-07-15 0:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 14:01 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 [this message]
2013-07-15 0:29 ` Peter Todd
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=20130715001437.GA21991@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=john.dillon892@googlemail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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