From mboxrd@z Thu Jan  1 00:00:00 1970
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