1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 801BD9D
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <aj@erisian.com.au>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190508044928.z52oaxevwcppkvna@erisian.com.au>
References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
<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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
