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 ) 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 To: Tamas Blummer 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> <20141211120916.E912EE22B92@quidecco.de> <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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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