From: "Luke-Jr" <luke@dashjr•org>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net, Jorge@vps7135•xlshosting.net
Subject: Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining
Date: Sun, 14 Jul 2013 20:16:41 +0000 [thread overview]
Message-ID: <201307142016.48605.luke@dashjr.org> (raw)
In-Reply-To: <20130714194205.GA27202@vps7135.xlshosting.net>
[-- Attachment #1: Type: Text/Plain, Size: 1969 bytes --]
On Sunday, July 14, 2013 7:42:06 PM Pieter Wuille wrote:
> On Sun, Jul 14, 2013 at 07:33:06PM +0000, Luke-Jr wrote:
> > > 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.
> >
> > Invalid blocks are rejected by validating clients in all circumstances.
>
> I don't think that's what John means.
>
> If you have hash power for the parent chain, mining invalid blocks for the
> merge-mined chain costs you nothing. Yes, they will be invalid, but you've
> lost nothing.
Nor gained anything. So the "lesser" chain maybe can't trust SPV.
But trusting SPV was already a bad idea anyway.
Note that the parent chain is not in any privileged position here either: a
merged-mined chain could provide the value to the miner he is interested in,
while he sees nothing of the parent chain. In short, merged mining is pretty
much unavoidable in any case.
> The basic assumption underlying mining security is that it is more
> profitable to collaborate with mining a chain (and profit from the block
> payout) than to attack it. In the case of merged mining, this assumption
> is not valid.
The basic assumption of SPV is that more people will be assisting rather than
making invalid blocks. That motive doesn't necessarily need to be economic,
nor do proper validating clients rely on it. The only real assumption behind
mining is that the majority will not be aiming to reverse transactions with
valid blocks.
P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as
(rewarded) Prime POW; maybe with no subsidy halving, to try a new economic
idea as well ;)
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 1530 bytes --]
next prev parent reply other threads:[~2013-07-14 20:17 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 [this message]
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
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=201307142016.48605.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=Jorge@vps7135$(echo .)xlshosting.net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(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