From: Bob McElrath <bob@mcelrath•org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Wed, 28 Nov 2018 00:54:16 +0000 [thread overview]
Message-ID: <20181128005416.GB22873@mcelrath.org> (raw)
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
next reply other threads:[~2018-11-28 0:59 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-28 0:54 Bob McElrath [this message]
2018-11-28 8:40 ` Johnson Lau
2018-11-28 14:04 ` Bob McElrath
-- strict thread matches above, loose matches on Subject: below --
2018-11-19 22:37 Pieter Wuille
2018-11-20 20:29 ` Anthony Towns
2018-11-21 11:20 ` Christian Decker
2018-11-21 17:55 ` Johnson Lau
2018-11-21 11:15 ` Christian Decker
2018-11-23 6:04 ` Anthony Towns
2018-11-23 9:40 ` Christian Decker
2018-11-24 8:13 ` Johnson Lau
2018-11-21 17:07 ` Russell O'Connor
2018-11-22 14:28 ` Johnson Lau
2018-11-22 16:23 ` Russell O'Connor
2018-11-22 20:52 ` Johnson Lau
2018-11-22 22:10 ` Russell O'Connor
2018-11-23 10:47 ` Johnson Lau
2018-11-23 5:03 ` Anthony Towns
2018-11-23 20:18 ` Russell O'Connor
2018-11-28 3:41 ` Pieter Wuille
2018-11-28 8:31 ` Johnson Lau
2018-11-29 17:00 ` Christian Decker
2018-11-29 18:29 ` Christian Decker
2018-12-06 16:57 ` Russell O'Connor
2018-12-09 19:13 ` Johnson Lau
2018-12-11 22:50 ` Russell O'Connor
2018-12-12 19:53 ` Johnson Lau
2018-12-13 16:50 ` Russell O'Connor
2018-12-13 0:05 ` Anthony Towns
2018-12-13 16:21 ` Russell O'Connor
2018-12-14 0:47 ` Anthony Towns
[not found] ` <CAAS2fgRma+Pw-rHJSOKRVBqoxqJ3AxHO9d696fWoa-sb17JEOQ@mail.gmail.com>
2018-12-13 16:34 ` Russell O'Connor
2018-12-09 22:41 ` David A. Harding
2018-12-11 15:36 ` Russell O'Connor
2018-12-11 17:47 ` David A. Harding
2018-12-12 9:42 ` Rusty Russell
2018-12-12 20:00 ` Johnson Lau
2018-12-12 23:49 ` Rusty Russell
2018-12-13 0:37 ` Rusty Russell
2018-12-14 9:30 ` Anthony Towns
2018-12-14 13:55 ` Johnson Lau
2018-12-17 3:10 ` Rusty Russell
2018-12-20 19:34 ` Johnson Lau
2018-12-20 23:17 ` Rusty Russell
2018-12-21 18:54 ` Johnson Lau
2018-12-23 4:26 ` Anthony Towns
2018-12-23 16:33 ` Johnson Lau
2018-12-24 12:01 ` ZmnSCPxj
2018-12-24 21:23 ` Johnson Lau
2018-12-16 6:55 ` Rusty Russell
2018-12-17 19:08 ` Johnson Lau
2018-12-18 4:22 ` Peter Todd
2018-12-19 0:39 ` Rusty Russell
2019-02-09 0:39 ` Pieter Wuille
2018-12-13 0:24 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181128005416.GB22873@mcelrath.org \
--to=bob@mcelrath$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox