path: root/fd/9bd886ee209b0064ce248330ed5f91cc38abd2

Return-Path: <roconnor@blockstream.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A92B2C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 17:20:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 90EF8404F5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 17:20:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level: 
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id cEdSa0-B2LNe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 17:20:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com
 [IPv6:2607:f8b0:4864:20::f31])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6CE42401F2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 17:20:23 +0000 (UTC)
Received: by mail-qv1-xf31.google.com with SMTP id b12so430020qvz.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 09:20:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=AbjalyAqlnm2Pv42rW/5QKvlhpJdtGt5zuIW8HU5gwM=;
 b=yOVRliSYV+kDns5w+2XuCUbvBOtpP4HA3hHpVzQHIM6VcvIWGU8IsvikoWUzAT5c2D
 nqOGMZBWLbuFsWZ5D/cdeTSkXjnXvq0YIDqkMlD/faZcRVqPDOPLKnMD/m5kgMvsp3Ra
 9K1LfK5xTT+A1oB7b0CAHIE5ywRR6h8W1k5yFPYCElmKpVQU8v+eTitKd0Hs+mbR5Ef8
 zXq76Q0YGrRTxHlwvt5jwhQaP2Ue2lnqf01lwv2wSmSPu3jyBsnLi0ghhZ+PBjf+Fget
 bwOlEA7rlrav5SSeihmN7Akp7ADv3yauzRrtoPJBIXjhpwCNOj0Qw+we2ht0AAKq0epq
 XWCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=AbjalyAqlnm2Pv42rW/5QKvlhpJdtGt5zuIW8HU5gwM=;
 b=3u24ryjI7HDQycW6ssnPNv8qmrSElPxrkaxOUEhFt4HT1JvpelSCcqMoFXWSuXLY5Y
 rRUSjtIkPtWHsnUSZMxn/Tjba8ChToOhCaqdPl2G/HT01d0WXwv9p+M0y/HwBO8CRxD+
 Kt0Q6JU9aDLLVObeNpT98OYhdUoCmCZVBhbcbIR2xS3hPe43ijEim99uzfbFbDZpDyYy
 8LKe8RQXh+Zfcml3hTSqrSSut4/NQVpviocihWLy10g1K1iK2Pdap1Nq3XMhIp1nXZMv
 pQslKn/pfTVSKkbQGa70ne1Lm6pzxSkPCsEg24AD+h2aKB5tkBNyNG6PBjAqMuKN34do
 IwiQ==
X-Gm-Message-State: AOAM530P+NMlNlbFMibGwAQcnz76nx1VyWgT59r3xhaD2uKFZDbRThog
 Iqj0m7BN9K7suuPmTWn32L3zxlzLnhpizI5mkolaqS7zg3ECDA==
X-Google-Smtp-Source: ABdhPJwAzHGqa2srA2WXU6DhZ76pr1hwP6d9Vq4VLNW/4f0d0qrBjZ/0fEoncYz1Hq3wuP/t3BFniPaDXymUex8XSq0=
X-Received: by 2002:a05:6214:250d:: with SMTP id
 gf13mr9713886qvb.63.1643217621730; 
 Wed, 26 Jan 2022 09:20:21 -0800 (PST)
MIME-Version: 1.0
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Wed, 26 Jan 2022 12:20:10 -0500
Message-ID: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a1d97005d67f6ada"
Subject: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and
	ANYPREVOUT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 26 Jan 2022 17:20:25 -0000

--000000000000a1d97005d67f6ada
Content-Type: text/plain; charset="UTF-8"

Recapping the relationship between CTV and ANYPREVOUT::

It is known that there is a significant amount of overlap in the
applications that are enabled by the CTV and ANYPREVOUT proposals despite
the fact that their primary applications (congestion control for CTV and
eltoo lightning channels for ANYPREVOUT) are quite distinct.
In particular, ANYPREVOUT can enable most of the applications of CTV,
albeit with a higher cost.  The primary functionality of CTV is to allow a
scriptPubKey to make a commitment to its spending transaction's hash with
the input's TXID excluded from the hash.  This exclusion is necessary
because the scriptPubKey is hashed into the input's TXID, and including the
TXID would cause a cycle of hash commitments, which is impossible to
construct.  On the other hand, ANYPREVOUT defines a signature hash mode
that similarly excludes the inputs TXID for its purpose of rebindable
signatures.

This means that ANYPREVOUT can mimic most of the properties of CTV by
committing both a public key along with an ANYPREVOUT signature inside
scriptPubKey.  In fact, the only reason Bitcoin doesn't have covenants
today is due to this cycle between scriptPubKeys and the TXIDs that occur
in all the sighash modes.

The major differences between simulating CTV via ANYPREVOUT and the actual
CTV proposal is: (1) The cost of simulating CTV.  With CTV the spending
transaction is committed using a hash of 32 bytes, while simulating it with
ANYPREVOUT requires 64 bytes for a signature, and 32 bytes for some public
key, plus a few more bytes for various flags.  Some of that cost could be
reduced by using the inner public key (1 byte representation) and, if we
had CAT, maybe by assembling the signature from reusable pieces (i.e.
setting the nonce of the commited signature equal to the public key).

The other major difference is: (2) CTV's transaction hash covers values
such as the number of inputs in the transaction and their sequence numbers,
which ANYPREVOUT does not cover.  CTV's hash contains enough information so
that when combined with the missing TXIDs, you can compute the TXID of the
spending transaction.  In particular if the number of inputs is committed
to being 1, once the scriptpubkey's transaction id is known and committed
to the blockchain, the TXID of its spending transaction is deducible.  And
if that transaction has outputs that have CTV commitments in them, you can
deduce their spending TXIDs in turn.  While this is a pretty neat feature,
something that ANYPREVOUT cannot mimic, the main application for it is
listed as using congestion control to fund lightning channels, fixing their
TXIDs in advance of them being placed on chain.  However, if ANYPREVOUT
were used to mimic CTV, then likely it would be eltoo channels that would
be funded, and it isn't necessary to know the TXIDs of eltoo channels in
advance in order to use them.



An Alternative Proposal::

Given the overlap in functionality between CTV and ANYPREVOUT, I think it
makes sense to decompose their operations into their constituent pieces and
reassemble their behaviour programmatically.  To this end, I'd like to
instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.

OP_TXHASH would pop a txhash flag from the stack and compute a (tagged)
txhash in accordance with that flag, and push the resulting hash onto the
stack.
OP_CHECKSIGFROMSTACKVERIFY would pop a pubkey, message, and signature from
the stack and fail if the signature does not verify on that message.

CTV and TXHASH have roughly equivalent functionality.  'CTV DROP' can be
simulated by '<ctv_style_flag> TXHASH EQUALVERIFY'.  The reverse is also
true where '<ctv_style_flag> TXHASH' can be simulated by CTV by
'<ctv-result-from-witness-stack> CTV', however, as you can see, simulating
TXHASH from CTV is much more expensive than the other way around, because
the resulting 32-byte hash result must be included as part of the witness
stack.

'<anyprevout-pubkey> CHECKSIGVERIFY can be simulated by '<apo_style_flag>
TXHASH <pubkey> CHECKSIGFROMSTACKVERIFY'.  Here we see the advantage of
pushing the hash value onto the stack.  APO can be simulated without
needing to include a copy of the resulting txhash inside the witness data.

In addition to the CTV and ANYPREVOUT applications, with
CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages
signed by oracles for oracle applications.  This is where we see the
benefit of decomposing operations into primitive pieces.  By giving users
the ability to program their own use cases from components, we get more
applications out of fewer op codes!



Caveats::

First, I acknowledge that replicating the behaviour of CTV and ANYPREVOUT
does cost a few more bytes than using the custom purpose built proposals
themselves.  That is the price to be paid when we choose the ability to
program solutions from pieces.  But we get to reap the advantages of being
able to build more applications from these pieces.

Unlike CTV, TXHASH is not NOP-compatable and can only be implemented within
tapscript.  In particular, bare CTV isn't possible with this proposal.
However, this proposal doesn't preclude the possibility of having CTV added
to legacy script in while having TXHASH added to tapscript.

For similar reasons, TXHASH is not amenable to extending the set of txflags
at a later date.  In theory, one could have TXHASH abort-with-success when
encountering an unknown set of flags.  However, this would make analyzing
tapscript much more difficult. Tapscripts would then be able to abort with
success or failure depending on the order script fragments are assembled
and executed, and getting the order incorrect would be catastrophic.  This
behavior is manifestly different from the current batch of OP_SUCCESS
opcodes that abort-with-success just by their mere presence, whether they
would be executed or not.

I believe the difficulties with upgrading TXHASH can be mitigated by
designing a robust set of TXHASH flags from the start.  For example having
bits to control whether (1) the version is covered; (2) the locktime is
covered; (3) txids are covered; (4) sequence numbers are covered; (5) input
amounts are covered; (6) input scriptpubkeys are covered; (7) number of
inputs is covered; (8) output amounts are covered; (9) output scriptpubkeys
are covered; (10) number of outputs is covered; (11) the tapbranch is
covered; (12) the tapleaf is covered; (13) the opseparator value is
covered; (14) whether all, one, or no inputs are covered; (15) whether all,
one or no outputs are covered; (16) whether the one input position is
covered; (17) whether the one output position is covered; (18) whether the
sighash flags are covered or not (note: whether or not the sighash flags
are or are not covered must itself be covered).  Possibly specifying which
input or output position is covered in the single case and whether the
position is relative to the input's position or is an absolute position.

That all said, even if other txhash flag modes are needed in the future,
adding TXHASH2 always remains an option.



Interactions with potential future opcodes::

We should give some consideration on how these opcodes may interact with
future opcodes such as CAT, rolling SHA256 opcodes, or how it might
interface with other covenant opcodes that may do things like, directly
push input or output amounts onto the stack for computation purposes,
opcodes which have been added to the Elements project.

With CAT and/or rolling SHA256 opcodes and/or existing SHA256 opcodes, the
CHECKSIGFROMSTACKVERIFY could verify signatures on programmatically
assembled messages.  Also, in combination with multiple calls to TXHASH,
could be used to create signatures that commit to complex subsets of
transaction data.

If new opcodes are added to push parts of the transaction data direction
onto the stack, e.g. OP_INSPECTOUTPUTVALUE, there is perhaps concern that
they would obsolete TXHASH, since, in the presence of rolling SHA256
opcodes, TXHASH could be simulated.  However, given that TXHASH can
compactly create a hash of large portions of transaction data, it seems
unlikely that TXHASH would fall into disuse.  Also, a combination of TXHASH
and transaction introspection opcodes can be used to build "*subtractive
covenants*".

The usual way of building a covenant, which we will call "*additive *
*covenants*", is to push all the parts of the transaction data you would
like to fix onto the stack, hash it all together, and verify the resulting
hash matches a fixed value.  Another way of building covenants, which we
will call "*subtractive covenants*", is to push all the parts of the
transaction data you would like to remain free onto the stack.  Then use
rolling SHA256 opcodes starting from a fixed midstate that commits to a
prefix of the transaction hash data. The free parts are hashed into that
midstate.  Finally, the resulting hash value is verified to match a value
returned by TXHASH.  The ability to nicely build subtractive covenants
depends on the details of how the TXHASH hash value is constructed,
something that I'm told CTV has given consideration to.

--000000000000a1d97005d67f6ada
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Recapping the relationship between CTV and ANYPREVOUT=
::<br></div><div><br></div><div>It is known that there is a significant amo=
unt of overlap in the applications that are enabled by the CTV and ANYPREVO=
UT proposals despite the fact that their primary applications (congestion c=
ontrol for CTV and eltoo lightning channels for ANYPREVOUT) are quite disti=
nct.</div><div>In particular, ANYPREVOUT can enable most of the application=
s of CTV, albeit with a higher cost.=C2=A0 The primary functionality of CTV=
 is to allow a scriptPubKey to make a commitment to its spending transactio=
n&#39;s hash with the input&#39;s TXID excluded from the hash.=C2=A0 This e=
xclusion is necessary because the scriptPubKey is hashed into the input&#39=
;s TXID, and including the TXID would cause a cycle of hash commitments, wh=
ich is impossible to construct.=C2=A0 On the other hand, ANYPREVOUT defines=
 a signature hash mode that similarly excludes the inputs TXID for its purp=
ose of rebindable signatures.</div><div><br></div><div>This means that ANYP=
REVOUT can mimic most of the properties of CTV by committing both a public =
key along with an ANYPREVOUT signature inside scriptPubKey.=C2=A0 In fact, =
the only reason Bitcoin doesn&#39;t have covenants today is due to this cyc=
le between scriptPubKeys and the TXIDs that occur in all the sighash modes.=
<br></div><div><br></div><div>The major differences between simulating CTV =
via ANYPREVOUT and the actual CTV proposal is: (1) The cost of simulating C=
TV.=C2=A0 With CTV the spending transaction is committed using a hash of 32=
 bytes, while simulating it with ANYPREVOUT requires 64 bytes for a signatu=
re, and 32 bytes for some public key, plus a few more bytes for various fla=
gs.=C2=A0 Some of that cost could be reduced by using the inner public key =
(1 byte representation) and, if we had CAT, maybe by assembling the signatu=
re from reusable pieces (i.e. setting the nonce of the commited signature e=
qual to the public key).<br></div><div><br></div><div>The other major diffe=
rence is: (2) CTV&#39;s transaction hash covers values such as the number o=
f inputs in the transaction and their sequence numbers, which ANYPREVOUT do=
es not cover.=C2=A0 CTV&#39;s hash contains enough information so that when=
 combined with the missing TXIDs, you can compute the TXID of the spending =
transaction.=C2=A0 In particular if the number of inputs is committed to be=
ing 1, once the scriptpubkey&#39;s transaction id is known and committed to=
 the blockchain, the TXID of its spending transaction is deducible.=C2=A0 A=
nd if that transaction has outputs that have CTV commitments in them, you c=
an deduce their spending TXIDs in turn.=C2=A0 While this is a pretty neat f=
eature, something that ANYPREVOUT cannot mimic, the main application for it=
 is listed as using congestion control to fund lightning channels, fixing t=
heir TXIDs in advance of them being placed on chain.=C2=A0 However, if ANYP=
REVOUT were used to mimic CTV, then likely it would be eltoo channels that =
would be funded, and it isn&#39;t necessary to know the TXIDs of eltoo chan=
nels in advance in order to use them.</div><div><br></div><div><br></div><d=
iv><br></div><div>An Alternative Proposal::<br></div><div><br></div><div>Gi=
ven the overlap in functionality between CTV and ANYPREVOUT, I think it mak=
es sense to decompose their operations into their constituent pieces and re=
assemble their behaviour programmatically.=C2=A0 To this end, I&#39;d like =
to instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.</div><div><br>=
</div><div>OP_TXHASH would pop a txhash flag from the stack and compute a (=
tagged) txhash in accordance with that flag, and push the resulting hash on=
to the stack.<br></div><div>OP_CHECKSIGFROMSTACKVERIFY would pop a pubkey, =
message, and signature from the stack and fail if the signature does not ve=
rify on that message.</div><div><br></div><div>CTV and TXHASH have roughly =
equivalent functionality.=C2=A0 &#39;CTV DROP&#39; can be simulated by &#39=
;&lt;ctv_style_flag&gt; TXHASH EQUALVERIFY&#39;.=C2=A0 The reverse is also =
true where &#39;&lt;ctv_style_flag&gt; TXHASH&#39; can be simulated by CTV =
by &#39;&lt;ctv-result-from-witness-stack&gt; CTV&#39;, however, as you can=
 see, simulating TXHASH from CTV is much more expensive than the other way =
around, because the resulting 32-byte hash result must be included as part =
of the witness stack.</div><div><br></div><div>&#39;&lt;anyprevout-pubkey&g=
t; CHECKSIGVERIFY can be simulated by &#39;&lt;apo_style_flag&gt; TXHASH &l=
t;pubkey&gt; CHECKSIGFROMSTACKVERIFY&#39;.=C2=A0 Here we see the advantage =
of pushing the hash value onto the stack.=C2=A0 APO can be simulated withou=
t needing to include a copy of the resulting txhash inside the witness data=
.<br></div><div><br></div><div>In addition to the CTV and ANYPREVOUT applic=
ations, with CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary =
messages signed by oracles for oracle applications.=C2=A0 This is where we =
see the benefit of decomposing operations into primitive pieces.=C2=A0 By g=
iving users the ability to program their own use cases from components, we =
get more applications out of fewer op codes!</div><div><br></div><div><br><=
/div><div><br></div><div>Caveats::</div><div><br></div><div>First, I acknow=
ledge that replicating the behaviour of CTV and ANYPREVOUT does cost a few =
more bytes than using the custom purpose built proposals themselves.=C2=A0 =
That is the price to be paid when we choose the ability to program solution=
s from pieces.=C2=A0 But we get to reap the advantages of being able to bui=
ld more applications from these pieces.<br></div><div><br></div><div>Unlike=
 CTV, TXHASH is not NOP-compatable and can only be implemented within tapsc=
ript.=C2=A0 In particular, bare CTV isn&#39;t possible with this proposal.=
=C2=A0 However, this proposal doesn&#39;t preclude the possibility of havin=
g CTV added to legacy script in while having TXHASH added to tapscript.</di=
v><div><br></div><div>For similar reasons, TXHASH is not amenable to extend=
ing the set of txflags at a later date.=C2=A0 In theory, one could have TXH=
ASH abort-with-success when encountering an unknown set of flags.=C2=A0 How=
ever, this would make analyzing tapscript much more difficult. Tapscripts w=
ould then be able to abort with success or failure depending on the order s=
cript fragments are assembled and executed, and getting the order incorrect=
 would be catastrophic.=C2=A0 This behavior is manifestly different from th=
e current batch of OP_SUCCESS opcodes that abort-with-success just by their=
 mere presence, whether they would be executed or not.</div><div><br></div>=
<div>I believe the difficulties with upgrading TXHASH can be mitigated by d=
esigning a robust set of TXHASH flags from the start.=C2=A0 For example hav=
ing bits to control whether (1) the version is covered; (2) the locktime is=
 covered; (3) txids are covered; (4) sequence numbers are covered; (5) inpu=
t amounts are covered; (6) input scriptpubkeys are covered; (7) number of i=
nputs is covered; (8) output amounts are covered; (9) output scriptpubkeys =
are covered; (10) number of outputs is covered; (11) the tapbranch is cover=
ed; (12) the tapleaf is covered; (13) the opseparator value is covered; (14=
) whether all, one, or no inputs are covered; (15) whether all, one or no o=
utputs are covered; (16) whether the one input position is covered; (17) wh=
ether the one output position is covered; (18) whether the sighash flags ar=
e covered or not (note: whether or not the sighash flags are or are not cov=
ered must itself be covered).=C2=A0 Possibly specifying which input or outp=
ut position is covered in the single case and whether the position is relat=
ive to the input&#39;s position or is an absolute position.</div><div><br><=
/div><div>That all said, even if other txhash flag modes are needed in the =
future, adding TXHASH2 always remains an option.<br></div><div><br></div><d=
iv><br></div><div><br></div><div>Interactions with potential future opcodes=
::<br></div><div><div><br></div><div>We should give some consideration on h=
ow these opcodes may interact with future opcodes such as CAT, rolling SHA2=
56 opcodes, or how it might interface with other covenant opcodes that may =
do things like, directly push input or output amounts onto the stack for co=
mputation purposes, opcodes which have been added to the Elements project.<=
/div><div><br></div><div>With CAT and/or rolling SHA256 opcodes and/or exis=
ting SHA256 opcodes, the CHECKSIGFROMSTACKVERIFY could verify signatures on=
 programmatically assembled messages.=C2=A0 Also, in combination with multi=
ple calls to TXHASH, could be used to create signatures that commit to comp=
lex subsets of transaction data.</div><div><br></div><div>If new opcodes ar=
e added to push parts of the transaction data direction onto the stack, e.g=
. OP_INSPECTOUTPUTVALUE, there is perhaps concern that they would obsolete =
TXHASH, since, in the presence of rolling SHA256 opcodes, TXHASH could be s=
imulated.=C2=A0 However, given that TXHASH can compactly create a hash of l=
arge portions of transaction data, it seems unlikely that TXHASH would fall=
 into disuse.=C2=A0 Also, a combination of TXHASH and transaction introspec=
tion opcodes can be used to build &quot;<i>subtractive covenants</i>&quot;.=
</div><div><br></div><div>The usual way of building a covenant, which we wi=
ll call &quot;<i>additive </i><i>covenants</i>&quot;, is to push all the pa=
rts of the transaction data you would like to fix onto the stack, hash it a=
ll together, and verify the resulting hash matches a fixed value.=C2=A0 Ano=
ther way of building covenants, which we will call &quot;<i>subtractive cov=
enants</i>&quot;, is to push all the parts of the transaction data you woul=
d like to remain free onto the stack.=C2=A0 Then use rolling SHA256 opcodes=
 starting from a fixed midstate that commits to a prefix of the transaction=
 hash data. The free parts are hashed into that midstate.=C2=A0 Finally, th=
e resulting hash value is verified to match a value returned by TXHASH.=C2=
=A0 The ability to nicely build subtractive covenants depends on the detail=
s of how the TXHASH hash value is constructed, something that I&#39;m told =
CTV has given consideration to.<br></div></div></div>

--000000000000a1d97005d67f6ada--