summaryrefslogtreecommitdiff
path: root/7d/80278238fde4c0250c76044c28989ed325c4dc
blob: f9000aba425444c8862ddf2012f9dd708ff5efa3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <john.dillon892@googlemail.com>) id 1UyRs9-0004ay-Ud
	for bitcoin-development@lists.sourceforge.net;
	Sun, 14 Jul 2013 19:22:18 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of googlemail.com
	designates 209.85.215.173 as permitted sender)
	client-ip=209.85.215.173;
	envelope-from=john.dillon892@googlemail.com;
	helo=mail-ea0-f173.google.com; 
Received: from mail-ea0-f173.google.com ([209.85.215.173])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UyRs9-0005SC-45
	for bitcoin-development@lists.sourceforge.net;
	Sun, 14 Jul 2013 19:22:17 +0000
Received: by mail-ea0-f173.google.com with SMTP id g15so7383024eak.18
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 14 Jul 2013 12:22:10 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.14.38.14 with SMTP id z14mr56251688eea.49.1373829730783;
	Sun, 14 Jul 2013 12:22:10 -0700 (PDT)
Received: by 10.223.12.131 with HTTP; Sun, 14 Jul 2013 12:22:10 -0700 (PDT)
In-Reply-To: <CAC1+kJMyvKnUKm8xTjzUK_5iq_VZM=iX17aCCd9vqe7jsYUJfQ@mail.gmail.com>
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>
Date: Sun, 14 Jul 2013 19:22:10 +0000
Message-ID: <CAPaL=UVmr1zng6QtngkY-Y+fP+E67NST7MYRpkSHfjtwZ7PFNw@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.4 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(john.dillon892[at]googlemail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (john.dillon892[at]googlemail.com)
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UyRs9-0005SC-45
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
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 14 Jul 2013 19:22:18 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Jul 14, 2013 at 11:18 AM, Jorge Tim=F3n <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" tho=
ugh,
I assume there exists only a sacrifice in one direction right? Wouldn't sel=
ling
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 re=
ward
is, ask that the marginal cost of merge mining an additional coin is. The i=
ssue
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 malicious=
ly
or through negligence. If the coin isn't worth much, either because it's ma=
rket
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 u=
p
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=3D
=3Db40P
-----END PGP SIGNATURE-----