From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 011F2C000D for ; Mon, 20 Sep 2021 14:52:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E1AD481B71 for ; Mon, 20 Sep 2021 14:52:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dPgdp4eGsrw for ; Mon, 20 Sep 2021 14:52:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.osuosl.org (Postfix) with ESMTPS id 3B089819D2 for ; Mon, 20 Sep 2021 14:52:53 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1mSKf3-0004U7-92; Tue, 21 Sep 2021 00:52:50 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Tue, 21 Sep 2021 00:52:46 +1000 Date: Tue, 21 Sep 2021 00:52:46 +1000 From: Anthony Towns To: Antoine Riard Message-ID: <20210920145246.GB21263@erisian.com.au> References: <20210909064138.GA22496@erisian.com.au> <20210911032644.GB23578@erisian.com.au> <20210915065051.GA26119@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] TAPLEAF_UPDATE_VERIFY covenant opcode X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 14:52:54 -0000 On Sat, Sep 18, 2021 at 10:11:10AM -0400, Antoine Riard wrote: > I think one design advantage of combining scope-minimal opcodes like MERKLESUB > with sighash malleability is the ability to update a subset of the off-chain > contract transactions fields after the funding phase. Note that it's not "update" so much as "add to"; and I mostly think graftroot (and friends), or just updating the utxo onchain, are a better general purpose way of doing that. It's definitely a tradeoff though. > Yes this is a different contract policy that I would like to set up. > Let's say you would like to express the following set of capabilities. > C0="Split the 4 BTC funds between Alice/Bob and Caroll/Dave" > C1="Alice can withdraw 1 BTC after 2 weeks" > C2="Bob can withdraw 1 BTC after 2 weeks" > C3="Caroll can withdraw 1 BTC after 2 weeks" > C4="Dave can withdraw 1 BTC after 2 weeks" > C5="If USDT price=X, Alice can withdraw 2 BTC or Caroll can withdraw 2 BTC" Hmm, I'm reading C5 as "If an oracle says X, and Alice and Carol agree, they can distribute all the remaining funds as they see fit". > If C4 is exercised, to avoid trust in the remaining counterparty, both Alice or > Caroll should be able to conserve the C5 option, without relying on the updated > key path. > As you're saying, as we know the group in advance, one way to setup the tree > could be: >        (A, (((((B, C), BC), D), BCD), ((((E, F), EF), G), EFG))) Make it: (((AB, (A,B)), (CD, (C,D))), ACO) AB = DROP DUP 0 6 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 2BTC LESSTHAN CD = same but for carol+dave A = DUP 10 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 1BTC LESSTHAN B' = DUP 0 2 TLUV CHECKSIGVERIFY IN_OUT_AMOUNT SUB 1BTC LESSTHAN B,C,D = same as A but for bob, etc A',C',D' = same as B' but for alice, etc ACO = CHECKSIGVERIFY CHECKSIG Probably AB, CD, A..D, A'..D' all want a CLTV delay in there as well. (Relative timelocks would probably be annoying for everyone who wasn't the first to exit the pool) > Note, this solution isn't really satisfying as the G path isn't neutralized on > the Caroll/Dave fork and could be replayed by Alice or Bob... I think the above fixes that -- when AB is spent it deletes itself and the (A,B) pair; when A is spent, it deletes (A, B and AB) and replaces them with B'; when B' is spent it just deletes itself. Cheers, aj