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 23CE4B12 for ; Wed, 28 Nov 2018 00:59:29 +0000 (UTC) X-Greylist: delayed 00:05:10 by SQLgrey-1.7.6 Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD0C563D for ; Wed, 28 Nov 2018 00:59:28 +0000 (UTC) Received: from mcelrath.org (localhost [127.0.0.1]) by mcelrath.org (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id wAS0sGQP022745 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Nov 2018 00:54:16 GMT Received: (from mcelrath@localhost) by mcelrath.org (8.14.4/8.14.4/Submit) id wAS0sGZk022744; Wed, 28 Nov 2018 00:54:16 GMT X-Authentication-Warning: mcelrath.org: mcelrath set sender to bob@mcelrath.org using -f Date: Wed, 28 Nov 2018 00:54:16 +0000 From: Bob McElrath To: Bitcoin Protocol Discussion Message-ID: <20181128005416.GB22873@mcelrath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,FAKE_REPLY_C 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: Wed, 28 Nov 2018 01:14:55 +0000 Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT 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, 28 Nov 2018 00:59:29 -0000 I have been working on an experimental wallet that implements Bitcoin Covenants/Vaults following a blog post I wrote about 2 years ago, using "Pay-to-Timelock Signed Transaction" (P2TST). (Also mentioned recently by kanzure in a talk somewheres...) The idea is that you deposit to an address for which you don't know the private key. Instead you construct a second transaction sending that to a timelocked staging address for which you DO have the privkey (it also has an IF/ELSE condition with a second spending condition for use in case of theft attempt). In order to do this you either have to delete the privkey of the deposit address (a difficult proposition to know it's actually been deleted), but instead one can construct a signature directly using a RNG, and use the SIGHASH to compute the corresponding pubkey via ECDSA recover, from which you compute the corresponding address. In this way your wallet is a set of P2TST transactions and a corresponding privkey, with a (set of) emergency keys. This interacts with NOINPUT in the following way: if the input to the transaction commits to the pubkey in any way, you have a circular dependency on the pubkey that could only be satisfied by breaking a hash function. This occurs with standard sighash's which commit to the txid, which in turn commit to the address, which commits to the pubkey, so this construction of covenants/vaults requires NOINPUT. AFAICT sipa's proposal is compatible with the above vaulted construction by using SIGHASH_NOINPUT | SIGHASH_SCRIPTMASK to remove the scriptPubKey/redeemScript from the sighash. Putting the scriptPubKey/redeemScript in the sighash introduces the same circular dependency, but SIGHASH_SCRIPTMASK removes it. One would probably want to provide the fee from a separate wallet so as to be able to account for fluctuating fee pressures when the unvaulting occurs a long time after vaulting. Thus you'd want to use SIGHASH_SINGLE so that a fee-wallet can add fees (or for composability of P2TSTs), and SIGHASH_NOFEE as well. P.S. Also very excited to combine the above idea with Taproot/Graftroot/g'Root. -- Cheers, Bob McElrath "For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken