[bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

Bob McElrath bob at mcelrath.org
Wed Nov 28 00:54:16 UTC 2018

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
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 

More information about the bitcoin-dev mailing list