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 CF806C000B for ; Thu, 10 Mar 2022 06:47:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id A13EE8430E for ; Thu, 10 Mar 2022 06:47:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 c9FDHkINoc39 for ; Thu, 10 Mar 2022 06:47:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp1.osuosl.org (Postfix) with ESMTPS id A5FAC8430C for ; Thu, 10 Mar 2022 06:47:25 +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 1nSCa1-00080g-AH; Thu, 10 Mar 2022 16:47:23 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 10 Mar 2022 16:47:17 +1000 Date: Thu, 10 Mar 2022 16:47:17 +1000 From: Anthony Towns To: Bram Cohen , Bitcoin Protocol Discussion Message-ID: <20220310064717.GA7597@erisian.com.au> References: <20220308012719.GA6992@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] bitcoin scripting and lisp 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: Thu, 10 Mar 2022 06:47:26 -0000 On Tue, Mar 08, 2022 at 06:54:56PM -0800, Bram Cohen via bitcoin-dev wrote: > On Mon, Mar 7, 2022 at 5:27 PM Anthony Towns wrote: > > One way to match the way bitcoin do things, you could have the "list of > > extra conditions" encoded explicitly in the transaction via the annex, > > and then check the extra conditions when the script is executed. > The conditions are already basically what's in transactions. I think the > only thing missing is the assertion about one's own id, which could be > added in by, in addition to passing the scriptpubkey the transaction it's > part of, also passing in the index of inputs which it itself is. To redo the singleton pattern in bitcoin's context, I think you'd have to pass in both the full tx you're spending (to be able to get the txid of its parent) and the full tx of its parent (to be able to get the scriptPubKey that your utxo spent) which seems klunky but at least possible (you'd be able to drop the witness data at least; without that every tx would be including the entire history of the singleton). > > > A nice side benefit of sticking with the UTXO model is that the soft fork > > > hook can be that all unknown opcodes make the entire thing automatically > > > pass. > > I don't think that works well if you want to allow the spender (the > > puzzle solution) to be able to use opcodes introduced in a soft-fork > > (eg, for graftroot-like behaviour)? > This is already the approach to soft forking in Bitcoin script and I don't > see anything wrong with it. It's fine in Bitcoin script, because the scriptPubKey already commits to all the opcodes that can possibly be used for any particular output. With a lisp approach, however, you could pass in additional code fragments to execute. For example, where you currently say: script: [pubkey] CHECKSIG witness: [64B signature][0x83] (where 0x83 is SINGLE|ANYONECANPAY) you might translate that to: script: (checksig pubkey (bip342-txmsg 3) 2) witness: signature 0x83 where "3" grabs the sighash byte, and "2" grabs the signature. But you could also translate it to: script: (checksig pubkey (sha256 3 (a 3)) 2) witness: signature (bip342-txmsg 0x83) where "a 3" takes "(bip342-txmsg 0x83)" then evaluates it, and (sha256 3 (a 3)) makes sure you've signed off on both how the message was constructed as well as what the message was. The advantage there is that the spender can then create their own signature hashes however they like; even ones that hadn't been thought of when the output was created. But what if we later softfork in a bip118-txmsg for quick and easy ANYPREVOUT style-signatures, and want to use that instead of custom lisp code? You can't just stick (softfork C (bip118-txmsg 0xc3)) into the witness, because it will evaluate to nil and you won't be signing anything. But you *could* change the script to something like: script: (softfork C (q checksigverify pubkey (a 3) 2)) witness: signature (bip118-txmsg 0xc3) But what happens if the witness instead has: script: (softfork C (q checksigverify pubkey (a 3) 2)) witness: fake-signature (fakeopcode 0xff) If softfork is just doing a best effort for whatever opcodes it knows about, and otherwise succeeding, then it has to succeed, and your script/output has become anyone-can-spend. On the other hand, if you could tell the softfork op that you only wanted ops up-to-and-including the 118 softfork, then it could reject fakeopcode and fail the script, which I think gives the desirable behaviour. Cheers, aj