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 801BD9D for ; Wed, 8 May 2019 04:49:43 +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 01DC01FB for ; Wed, 8 May 2019 04:49:42 +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 1hOEWQ-0003QG-3s; Wed, 08 May 2019 14:49:39 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Wed, 08 May 2019 14:49:28 +1000 Date: Wed, 8 May 2019 14:49:28 +1000 From: Anthony Towns To: Luke Dashjr , Bitcoin Protocol Discussion Message-ID: <20190508044928.z52oaxevwcppkvna@erisian.com.au> References: <201905062017.11396.luke@dashjr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201905062017.11396.luke@dashjr.org> 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: Thu, 09 May 2019 14:48:33 +0000 Subject: Re: [bitcoin-dev] Taproot proposal 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: Wed, 08 May 2019 04:49:43 -0000 On Mon, May 06, 2019 at 08:17:09PM +0000, Luke Dashjr via bitcoin-dev wrote: > Some way to sign an additional script (not committed to by the witness > program) seems like it could be a trivial addition. Aside: if you want to commit to something extra *with* the witness program, you could use either an unsolvable tapleaf branch (eg, one that uses OP_RETURN and also pushes the data you want to commit to), or a p2c construction like: Taproot: Q = P + H_TapTweak(P || S)*G P2C: P = R + H_"myp2c"(R || Contract)*G If you don't have any scripts for S, you could set S=["OP_RETURN"] to ensure there are no scripts. Having either the TapTweak formula or the H_myp2c hash should be enough to ensure that your contract can't get maliciously reinterpreted as a valid tapscript, having both is just belts and suspenders. But to address your question: if you want to commit to something extra at spending/signing time rather than when creating the address, then that's what the annex should be useful for. eg as a simple example, your annex might be: 0x50 [flag] 0x25 [entry size] 0x77 [annex entry id] 0x0008c618 [block height == 575000] 0x00000000000000000007df59824a0c86d1cc21b90eb25259dd2dba5170cea5f5 [block hash for block at 575000] which would allow you to commit to a particular block hash, and there could be a soft fork that added the restriction that such a commitment invalidates the transaction if the block at the given height doesn't match the provided hash. You still need to the soft-fork to do the enforcing, but once you have that, *every* existing taproot address automatically gets "upgraded" to allow you to make the commitment, including via key path spends, which seems pretty nice. (That construction (ie size,id,data) lets you have multiple entries in the annex reasonably efficiently) Cheers, aj