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 C94F0C00 for ; Thu, 20 Jun 2019 22:06:05 +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 417D6E6 for ; Thu, 20 Jun 2019 22:06:05 +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 1he5Bt-00052c-Kl; Fri, 21 Jun 2019 08:05:59 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 21 Jun 2019 08:05:52 +1000 Date: Fri, 21 Jun 2019 08:05:52 +1000 From: Anthony Towns To: Russell O'Connor Message-ID: <20190620220552.metrqaul3iporwma@erisian.com.au> References: <20190605093039.xfo7lcylqkhsfncv@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Fri, 21 Jun 2019 17:31:27 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY) 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, 20 Jun 2019 22:06:05 -0000 On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote: > So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason to > complicate the spec to ensure the digest is precommitted as part of the > opcode." Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT (NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if it's been spelled out anywhere); ie instead of constructing X = Hash_BagHash( version, locktime, [outputs], [sequences], num_in ) and having the script be " OP_SECURETHEBAG" you calculate an ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL: Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0, amount, sequence) and calculate a signature sig = Schnorr(P,m) for some pubkey P, and make your script be "

CHECKSIG". That loses the ability to commit to the number of inputs or restrict the nsequence of other inputs, and requires a bigger script (sig and P are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much the same as far as I can tell. Both scripts are automatically satisfied when revealed (with the correct set of outputs), and don't need any additional witness data. If you wanted to construct "X" via script instead of hardcoding a value because it got you generalised covenants or whatever; I think you could get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much the same way you construct X, but you'd then need to turn that into a signature. You could do so by using pubkey P=G and nonce R=G, which means you need to calculate s=1+hash(G,G,Y)*1 -- calculating the hash part is easy, multiplying it by 1 is easy, and to add 1 you can probably do something along the lines of: OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT (ie, take the last 4 bytes, increment it using 4-byte arithmetic, then cat the first 28 bytes and the result. There's overflow issues, but I think they can be worked around either by allowing you to choose different locktimes, or by more complicated script) Cheers, aj