From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4320B907 for ; Fri, 4 Nov 2016 14:45:37 +0000 (UTC) X-Greylist: delayed 00:09:37 by SQLgrey-1.7.6 Received: from hera.mpi-klsb.mpg.de (hera.mpi-klsb.mpg.de [139.19.1.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E484136 for ; Fri, 4 Nov 2016 14:45:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mmci.uni-saarland.de; s=mail200803; h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID; bh=EevN4zwv4vXXx7tWDTR6a+R+xE+YB3tiLXixzGSafaM=; b=MDwqaVm8YiClaRWdwAH7cuNzyS3NMjs19uj79o4eqYM2HS3G0znDb/7gSGuJFPo5tWCXQD6YFb525DdSYHNK4kbufwI3pCgGy46X9rcoLNQXfXmG7vN43fkNjdIm5fn6TWvWfPw0//1YdZRXqhnznWFyvmOl/MbpL7ssjSwukvM=; Received: from vrt-00-414.mpi-klsb.mpg.de ([139.19.1.27]:51906 helo=tentacle.mpi-klsb.mpg.de) by hera.mpi-klsb.mpg.de (envelope-from ) with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) id 1c2fay-0000rr-7v for bitcoin-dev@lists.linuxfoundation.org; Fri, 04 Nov 2016 15:35:55 +0100 Received: from mbpc39.cs.uni-saarland.de ([134.96.225.150]:34820) by tentacle.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) id 1c2fay-0005Wv-08 for bitcoin-dev@lists.linuxfoundation.org; Fri, 04 Nov 2016 15:35:52 +0100 Message-ID: <1478270151.1662.6.camel@mmci.uni-saarland.de> From: Tim Ruffing To: bitcoin-dev@lists.linuxfoundation.org Date: Fri, 04 Nov 2016 15:35:51 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MPI-Local-Sender: true X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 04 Nov 2016 14:48:28 +0000 Subject: Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 14:45:37 -0000 Not a covenant but interesting nevertheless: _One_ of OP_CAT and OP_CHECKSIGFROMSTACKVERIFY alone is enough to implement "opt-in miner takes double-spend" [1]: You can create an output, which is spendable by everybody if you ever double-spend the output with two different transactions. Then the next miner will probably take your money (double-spending against your two or more contradicting transactions again). If you spend such an output, then the recipient may be willing to accept a zero-conf transaction, because he knows that you'll lose the money when you attempt double-spending (unless you are the lucky miner). See the discussion in [1] for details. The implementation using OP_CHECKSIGFROMSTACKVERIFY is straight- forward. You add a case to the script which allows spending if two valid signatures on different message under the public key of the output are given. What is less known I think: The same functionality can be achieved in a simpler way just using OP_CAT, because it's possible to turn Bitcoin's ECDSA to an "opt-in one-time signature scheme". With OP_CAT, you can create an output that is only spendable using a signature (r,s) with a specific already fixed first part r=x_coord(kG). Basically, the creator of this output commits on r (and k) already when creating the output. Now, signing two different transaction with the same r allows everybody to extract the secret key from the two signatures. The drawbacks of the implementation with OP_CAT is that it's not possible to make a distinction between legitimate or illegitimate double-spends (yet to be defined) but just every double-spend is penalized. Also, it's somewhat hackish and the signer must store k (or create it deterministically but that's a good idea anyway). [1] https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07122.html Best, Tim On Thu, 2016-11-03 at 07:37 +0000, Daniel Robinson via bitcoin-dev wrote: > Really cool! > > How about "poison transactions," the other covenants use case > proposed by Möser, Eyal, and Sirer? (I think > OP_CHECKSIGFROMSTACKVERIFY will also make it easier to check fraud > proofs, the other prerequisite for poison transactions.) > > Seems a little wasteful to do those two "unnecessary" signature > checks, and to have to construct the entire transaction data > structure, just to verify a single output in the transaction. Any > plans to add more flexible introspection opcodes to Elements, such as > OP_CHECKOUTPUTVERIFY? > > Really minor nit: "Notice that we have appended 0x83 to the end of > the transaction data"—should this say "to the end of the signature"? > > On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev coin-dev@lists.linuxfoundation.org> wrote: > > Right.  There are minor trade-offs to be made with regards to that > > design point of OP_CHECKSIGFROMSTACKVERIFY.  Fortunately this > > covenant construction isn't sensitive to that choice and can be > > made to work with either implementation of > > OP_CHECKSIGFROMSTACKVERIFY. > > > > On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau wrote: > > > Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a > > > different way from the Elements. Instead of hashing the data on > > > stack, I directly put the 32 byte hash to the stack. This should > > > be more flexible as not every system are using double-SHA256 > > > > > > https://github.com/jl2012/bitcoin/commits/mast_v3_master > > > > > > > > > > > > > On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev > > > oin-dev@lists.linuxfoundation.org> wrote: > > > > > > > > Hi all, > > > > > > > > It is possible to implement covenants using two script > > > > extensions: OP_CAT and OP_CHECKSIGFROMSTACKVERIFY.  Both of > > > > these op codes are already available in the Elements Alpha > > > > sidechain, so it is possible to construct covenants in Elements > > > > Alpha today.  I have detailed how the construction works in a > > > > blog post at > > > lements-alpha.html>.  As an example, I've constructed scripts > > > > for the Moeser-Eyal-Sirer vault. > > > > > > > > I'm interested in collecting and implementing other useful > > > > covenants, so if people have ideas, please post them. > > > > > > > > If there are any questions, I'd be happy to answer.   > > > > > > > > --  > > > > Russell O'Connor > > > > _______________________________________________ > > > > bitcoin-dev mailing list > > > > bitcoin-dev@lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev