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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <cryptocurrencies@quidecco.de>) id 1YJ0Pr-0000Cr-F0
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Feb 2015 13:54:51 +0000
X-ACL-Warn:
Received: from quidecco.de ([81.169.136.15])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YJ0Pp-0007ep-SQ
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Feb 2015 13:54:51 +0000
Received: from localhost (localhost [127.0.0.1])
by quidecco.de (Postfix) with SMTP id 2907FE2DCAD;
Wed, 4 Feb 2015 14:54:43 +0100 (CET)
From: Isidor Zeuner <cryptocurrencies@quidecco.de>
To: Tamas Blummer <tamas@bitsofproof.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252; format=flowed
References: <709AAA00-A40A-42EF-A17D-9B3E07FE902A@bitsofproof.com>
<417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com>
<CA+s+GJAe9MeO+Sr0+2BRwu3q-Be5JQt_s_xdnBBEcquXqOyxcA@mail.gmail.com>
<20141211120916.E912EE22B92@quidecco.de>
<B8D7AE7E-567E-4656-9231-17EEAD6ED603@bitsofproof.com>
<AEDF060A-17E7-4519-950A-30974D1520E3@bitsofproof.com>
<20141215123942.GA28381@savin.petertodd.org>
In-Reply-To: <709AAA00-A40A-42EF-A17D-9B3E07FE902A@bitsofproof.com>
Message-Id: <20150204135443.2907FE2DCAD@quidecco.de>
Date: Wed, 4 Feb 2015 14:54:43 +0100 (CET)
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
X-Headers-End: 1YJ0Pp-0007ep-SQ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof
of burn on parent chain
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: Wed, 04 Feb 2015 13:54:51 -0000
Hi there,
comments in-line:
> > I later wrote up the idea in the context of adding Zerocoin to
> > Bitcoin:
> >
> > http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
> >
For the sake of maximum clarity with respect to modelling the value of
a Bitcoin, I don't think that approaches which change the number
of coins that can possibly be circulated should be encouraged.
So, I like the idea of having the "sacrificed" coins appearing in the
mining fees in a future block. But what is meant with OP_DEPTH in this
context? From what I read, this operation just manipulates the stack
size when evaluating the script, so I don't see how it would
affect miner incentives.
Best regards,
Isidor
|
