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 70E671B7F for ; Thu, 4 Apr 2019 07:07:21 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 764757C3 for ; Thu, 4 Apr 2019 07:07:20 +0000 (UTC) Date: Thu, 04 Apr 2019 07:07:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1554361638; bh=MIhZ+4HL6PkOg/lHi3ZStKAmvEUqURsB368LDbXdhDU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=cI+Y5FFZRjyWk+a9EV4CL128RWAzXuz3GoyIaGAE2OOIRRBC3H0cBPgtCxVun0vmP TV++CfqLnN9ocCtKj2VUZ/ik3zbPDqSfsDGbADIbssGvD+o7Xxd49unorZ8c9ovOyo gzcM7N2Zq/run8CwfHZoALQhcpN7/vK0utAq85sA= To: Ariel Lorenzo-Luaces From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <77b8f255-8f70-431e-839c-b99361d1dac7@gmail.com> References: <77b8f255-8f70-431e-839c-b99361d1dac7@gmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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: Thu, 04 Apr 2019 10:10:24 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Smart Contracts Unchained 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: Thu, 04 Apr 2019 07:07:21 -0000 Good morning Ariel, > However, consider the situation where a group of participants are playing= poker. One participant loses all their funds and decides to present to the= escrow the contract+an old contract state+a signed message following the c= ontract rules (eg. an independently signed cashing out message). How would = the escrow know that the contract state is old and the operation is disallo= wed, without using a consensus mechanism like a blockchain? One might point to the various channel mechanisms (Poon-Dryja, Decker-Watte= nhofer, Decker-Russell-Osuntokun) as counterarguments. Though they require a blockchain as backing, old states are invalidated (Po= on-Dryja) or replaceable (Decker-*), without necessarily requiring a blockc= hain to keep track of all the states. Suppose our purported smart contract platform supports some kind of covenan= t system. This means, that it is possible to make a branch of the contract require th= at the fund go to a specific address template in the transaction that spend= s it. Suppose we use this mechanism to require that the Bitcoin-level transaction= pay again to a contract in the same contract platform. It then becomes possible to make a covenant that requires spending the tran= saction to the same covenant. This can allow us to enforce creating an offchain sequence of transactions = T1...Tn, such that T2 spends T1, T3 spends T2, etc. Then the final transaction Tn completes the sequence and pays out according= to the rules of Poker, or whatever. This sequence is anchored on an onchain transaction T0 which enters the fun= ds into the smart contract. The smart contract platform just signs "blindly" without particularly carin= g whether the signature went onchain, or even whether the UTXO being spent = exists onchain --- all it cares, is that the smart contract can be given wi= tnesses correctly. Now upon reaching Tn, the winner(s) can just publish the sequence of transa= ctions T1...Tn. Alternately, they can present the sequence of transactions T1...Tn to all p= articipants, and offer to give back part of the money allocated to fees for= all the transactions T1...Tn in exchange for a single transaction that sho= rtcuts all of that and spends to however Tn splits out. Basically, consider that the Decker-Russell-Osuntokun mechanism starts with= a mechanism very much like the above (a sequence of update transactions) a= nd then does some optimizations to allow the final transaction Tn to spend = any transaction Ti where i < n. But the basic concept that the sequence is at all possible, and can be kept= offchain, implies this state does not require to be stored onchain at all. Regards, ZmnSCPxj