From: Anthony Towns <aj@erisian•com.au>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot proposal
Date: Wed, 8 May 2019 14:49:28 +1000 [thread overview]
Message-ID: <20190508044928.z52oaxevwcppkvna@erisian.com.au> (raw)
In-Reply-To: <201905062017.11396.luke@dashjr.org>
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
next prev parent reply other threads:[~2019-05-08 4:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 17:57 Pieter Wuille
2019-05-06 20:17 ` Luke Dashjr
2019-05-07 20:42 ` Sjors Provoost
2019-05-08 4:37 ` ZmnSCPxj
2019-05-08 5:16 ` ZmnSCPxj
2019-05-08 23:06 ` Pieter Wuille
2019-05-18 17:51 ` ZmnSCPxj
2019-05-08 3:44 ` ZmnSCPxj
2019-05-09 16:56 ` Johnson Lau
2019-05-10 5:38 ` ZmnSCPxj
2019-05-08 4:49 ` Anthony Towns [this message]
2019-05-08 13:10 ` Luke Dashjr
2019-05-21 17:20 ` Russell O'Connor
2019-05-23 2:06 ` Pieter Wuille
2019-05-23 2:32 ` Russell O'Connor
2019-05-22 14:14 ` John Newbery
2019-09-16 16:18 ` Greg Sanders
2019-09-17 4:09 ` ZmnSCPxj
2019-09-18 21:21 ` Pieter Wuille
2019-06-27 0:08 ` Russell O'Connor
2019-06-28 9:49 ` Anthony Towns
2019-06-28 11:16 ` Russell O'Connor
2019-08-09 14:58 Elichai Turkel
2019-08-09 18:29 ` Pieter Wuille
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=20190508044928.z52oaxevwcppkvna@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)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