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 7EF9214B2 for ; Mon, 27 May 2019 07:21:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 902C4A9 for ; Mon, 27 May 2019 07:21:36 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1hV9wp-0005vw-Ow; Mon, 27 May 2019 17:21:33 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 27 May 2019 17:21:28 +1000 Date: Mon, 27 May 2019 17:21:28 +1000 From: Anthony Towns To: Russell O'Connor , Bitcoin Protocol Discussion Message-ID: <20190527072128.lbzeo6h23qgxvhsy@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 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: Mon, 27 May 2019 14:25:27 +0000 Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK 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: Mon, 27 May 2019 07:21:37 -0000 On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-dev wrote: > Bitcoin Script appears designed to be a flexible programmable system that > provides generic features to be composed to achieve various purposes. Counterpoint: haven't the flexibly designed parts of script mostly been a failure -- requiring opcodes to be disabled due to DoS vectors or consensus bugs, and mostly not being useful in practice where they're still enabled in BTC or on other chains where they have been re-enabled (eg, Liquid and BCH)? > Instead, I propose that, for the time being, we simply implement OP_CAT and > OP_CHECKSIGFROMSTACKVERIFY. FWIW, I'd like to see CAT enabled, though I'm less convinced about a CHECKSIG that takes the message from the stack. I think CAT's plausibly useful in practice, but a sig against data from the stack seems more useful in theory than in practice. Has it actually seen use on BCH or Liquid, eg? (Also, I think BCH's name for that opcode makes more sense than Elements' -- all the CHECKSIG opcodes pull a sig from the stack, after all) > * Transaction introspection including: > + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the > nature of the construction. I think simulating an ANYPREVOUT sig with a data signature means checking: S1 P CHECKSIG -- to check S1 is a signature for the tx S1 H_TapSighash(XAB) P CHECKDATASIG -- to pull out the tx data "X", "A", "B") S2 H_TapSighash(XCB) Q CHECKDATASIG -- for the ANYPREVOUT sig, with A changed to C to avoid committing to prevout info X SIZE 42 EQUALVERIFY B SIZE 47 EQUALVERIFY -- to make sure only C is replaced from "XCB" So to get all those conditions checked, I think you could do: P 2DUP TOALT TOALT CHECKSIGVERIFY SIZE 42 EQUALVERIFY "TapSighash" SHA256 DUP CAT SWAP CAT TOALT SIZE 47 EQUALVERIFY TUCK CAT FROMALT TUCK SWAP CAT SHA256 FROMALT SWAP FROMALT CHECKDATASIGVERIFY SWAP TOALT SWAP CAT FROMALT CAT SHA256 Q CHECKDATASIG Where the stack elements are, from top to bottom: S1: (65B) signature by P of tx X: (42B) start of TapSighash spec B: (47B) end of TapSighash spec (amount, nSequence, tapleaf_hash, key_version, codesep_pos) A: (73B) middle of TapSighash spec dropped for ANYPREVOUT (spend_type, scriptPubKey and outpoint) C: (1B) alternate middle (different spend_type) S2: (64B) signature of "XCB" by key Q So 298B for the witness data, and 119B or so for the script (if I've not made mistakes), versus "P CHECKSIGVERIFY Q CHECKSIG" and S2 and S1 on the stack, for 132B of witness data and 70B of script, or half that if the chaperone requirement is removed. I think you'd need to complicate it a bit further to do the ANYPREVOUTANYSCRIPT variant, where you retain the commitment to amount/nseq but drop the commitment to tapleaf_hash. > I feel that this style of generic building blocks truly embodies what is meant > by "programmable money". For practical purposes, this doesn't seem like a great level of abstraction to me. It's certainly better at "permissionless innovation" though. You could make these constructions a little bit simpler by having a "CHECK_SIG_MSG_VERIFY" opcode that accepts [sig msg key], and does "sig key CHECKSIGVERIFY" but also checks the the provided msg was what was passed into bip-schnorr. Cheers, aj