path: root/1c/afc0a385c8fcb868fd80cfceb013e36b100b6e

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 01AA3C0039
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 22:16:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id D1A2A60804
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 22:16:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XvKRALSI4M9B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 22:16:22 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 2DAFC61002
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 22:16:21 +0000 (UTC)
Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com
 [209.85.208.172]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20QMGIDY026445
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 26 Jan 2022 17:16:19 -0500
Received: by mail-lj1-f172.google.com with SMTP id e9so1601868ljq.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Jan 2022 14:16:19 -0800 (PST)
X-Gm-Message-State: AOAM5317x8sTlsEnkDihF+Z3dTDmCjYPhFUzhx0nja9MbUs96RSxpEjA
 JkbjLKVisjECYAOXzE90OsPafch1Oj1oHaV+nGU=
X-Google-Smtp-Source: ABdhPJwqwFNsy8hS27yRvuRewdJ48P4J8fhMOqrnGYrrI/fikTlK4/Y9avjfqGar0I1hKDSGS2STCgEG1RfBsi+zIfs=
X-Received: by 2002:a2e:a811:: with SMTP id l17mr817465ljq.81.1643235377824;
 Wed, 26 Jan 2022 14:16:17 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
In-Reply-To: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 26 Jan 2022 14:16:06 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhwqJ_AETAb3p_zUZmRX-Dzh8J9G984zwEs=KFsGN8aNQ@mail.gmail.com>
Message-ID: <CAD5xwhhwqJ_AETAb3p_zUZmRX-Dzh8J9G984zwEs=KFsGN8aNQ@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000fa4c3905d6838cba"
Subject: Re: [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 22:16:25 -0000

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

Hi Russell,

Thanks for this email, it's great to see this approach described.

A few preliminary notes of feedback:

1) a Verify approach can be made to work for OP_TXHASH (even with CTV
as-is) E.g., suppose a semantic added for a single byte stack[-1] sighash
flag to read the hash at stack[-2], then the hash can be passed in instead
of put on the stack. This has the disadvantage of larger witnesses, but the
advantage of allowing undefined sighash flags to pass for any hash type.
2) using the internal key for APO covenants is not an option because it
makes transaction construction interactive and precludes contracts with a
NUMS point taproot key. Instead, if you want similar savings, you should
advocate an OP_GENERATOR which puts G on the stack. Further, an untagged
APO variant which has split R and S values would permit something like
<sig> OP_GENERATOR OP_GENERATOR CHECKSIGAPO, which would be only 2 more
bytes than CTV.
3) I count something like 20 different flags in your proposal. As long as
flags are under 40 bytes (and 32 assuming we want it to be easy) without
upgrading math this should be feasible to manipulate on the stack
programmatically. This is ignoring some of the more flexible additions you
mention about picking which outputs/inputs are included. However, 20 flags
means that for testing we would want comprehensive tests and understanding
for ~1 million different flag combos and the behaviors they expose. I think
this necessitates a formal model of scripting and transaction validity
properties. Are there any combinations that might be undesirable?
4) Just hashing or not hashing isn't actually that flexible, because it
doesn't natively let you do things like (for example) TLUV. You really do
need tx operations for directly manipulating the data on the stack to
construct the hash if you want more flexible covenants. This happens to be
compatible with either a Verify or Push approach, since you either
destructure a pushed hash or build up a hash for a verify.
5) Flexible hashing has the potential for quadratic hashing bugs. The
fields you propose seem to be within similar range to work you could cause
with a regular OP_HASH256, although you'd want to be careful with some of
the proposed extensions that you don't create risk of quadratic hashing,
which seems possible with an output selecting opcode unless you cache
properly (which might be tricky to do). Overall for the fields explicitly
mentioned, seems safe, the "possibles" seem to have some more complex
interactions. E.g., CTV with the ability to pick a subset of outputs would
be exposed to quadratic hashing.
6) Missing field: covering the annex or some sub-range of the annex
(quadratic hashing issues on the latter)
7) It seems simpler to, for many of these fields, push values directly (as
in OP_PUSHTXDATA from Johnson Lau) because the combo of flags to push the
hash of a single output's amount to emulate OP_AMOUNT looks 'general but
annoying'. It may make more sense to do the OP_PUSHTXDATA style opcode
instead. This also makes it simpler to think about the combinations of
flags, since it's really N independent multi-byte opcodes.


Ultimately if we had OP_TXHASH available "tomorrow", I would be able to
build out the use cases I care about for CTV (and more). So I don't have an
opposition on it with regards to lack of function.

However, if one finds the TXHASH approach acceptable, then you should also
be relatively fine doing APO, CTV, CSFS, TXHASH acceptable in any order
(whenever "ready"), unless you are particularly sensitive to "technical
debt" and "soft fork processes". The only costs of doing something for CTV
or APO given an eventual TXHASH is perhaps a wasted key version or the 32
byte argument of a NOP opcode and some code to maintain.

Are there other costs I am missing?

However, as it pertains to actual rollout:

- OP_TXHASH+CSFSV doesn't seem to be the "full" set of things needed (we
still need e.g. OP_CAT, Upgraded >=64 bit Math, TLUV or OP_TWEAK
OP_TAPBRANCH OP_MANIPULATETAPTREE, and more) to full realize covenanting
power it intends to introduce.
- What sort of timeline would it take to ready something like TXHASH (and
desired friends) given greater scope of testing and analysis (standalone +
compared to CTV)?
- Is there opposition from the community to this degree of
general/recursive covenants?
- Does it make "more sense" to invest the research and development effort
that would go into proving TXHASH safe, for example, into Simplicity
instead?

Overall, *my opinion *is that:

- TXHASH is an acceptable theoretical approach, and I am happy to put more
thought into it and maybe draft a prototype of it.
- I prefer CTV as a first step for pragmatic engineering and availability
timeline reasons.
- If TXHASH were to take, optimistically, 2 years to develop and review,
and then 1 year to activate, the "path dependence of software" would put
Bitcoin in a much better place were we to have CTV within 1 year and
applications (that are to be a subset of TXHASH later) being built over the
next few years enhanced in the future by TXHASH's availability.
- There is an element of expediency meritted for something like CTV insofar
as it provides primitives to tackle time sensitive issues around privacy,
scalability, self custody, and decentralization. The aforementioned
properties may be difficult to reclaim once given away (with the exception
of perhaps scalability).
- Bringing CTV to an implemented state of near-unanimous "we could do this,
technically" is good for concretely driving the process of review for any
covenant proposals forward, irrespective of if we ultimately activate.
(I.e., if there were a reason we could not do CTV safely, it would likely
have implications for any other future covenant)

Concretely, I'm not going to stop advocating for CTV based on the above,
but I'm very happy to have something new in the mix to consider!

Best,

Jeremy


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Wed, Jan 26, 2022 at 9:23 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Hi Russell,</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Thanks =
for this email, it&#39;s great to see this approach described.</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">A few =
preliminary notes of feedback:</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">1) a Verify approach can be made to wo=
rk for OP_TXHASH (even with CTV as-is) E.g., suppose a semantic added for a=
 single byte stack[-1] sighash flag to read the hash at stack[-2], then the=
 hash can be passed in instead of put on the stack. This has the disadvanta=
ge of larger witnesses, but the advantage=C2=A0of allowing undefined sighas=
h flags to pass for any hash type.</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">2=
) using the internal key for APO covenants is not an option because it make=
s transaction construction interactive and precludes contracts with a NUMS =
point taproot key. Instead, if you want similar savings, you should advocat=
e an OP_GENERATOR which puts G on the stack. Further, an untagged APO varia=
nt which has split R and S values would permit something like &lt;sig&gt; O=
P_GENERATOR OP_GENERATOR CHECKSIGAPO, which would be only 2 more bytes than=
 CTV.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:#000000">3) I count something like 20 di=
fferent flags in your proposal. As long as flags are under 40 bytes (and 32=
 assuming we want it to be easy) without upgrading math this should be feas=
ible to manipulate on the stack programmatically. This is ignoring some of =
the more flexible additions you mention about picking which outputs/inputs =
are included. However, 20 flags means that for testing we would want compre=
hensive tests and understanding for ~1 million different flag combos and th=
e behaviors they expose. I think this necessitates a formal model of script=
ing and transaction validity properties. Are there any combinations that mi=
ght be undesirable?</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000">4) Just hashing o=
r not hashing isn&#39;t actually that flexible, because it doesn&#39;t nati=
vely let you do things like (for example) TLUV. You really do need tx opera=
tions for directly manipulating the data on the stack to construct the hash=
 if you want more flexible covenants. This happens to be compatible with ei=
ther a Verify or Push approach, since you either destructure a pushed hash =
or build up a hash for a verify.</div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">5) F=
lexible hashing has the potential for quadratic hashing bugs. The fields yo=
u propose seem to be within similar range to work you could cause with a re=
gular OP_HASH256, although you&#39;d want to be careful with some of the pr=
oposed extensions that you don&#39;t create risk of quadratic hashing, whic=
h seems possible with an output selecting opcode unless you cache properly =
(which might be tricky to do). Overall for the fields explicitly mentioned,=
 seems safe, the &quot;possibles&quot; seem to have some more complex inter=
actions. E.g., CTV with the ability to pick a subset of outputs would be ex=
posed to quadratic hashing.</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">6) Missin=
g field: covering the annex or some sub-range of the annex (quadratic hashi=
ng issues on the latter)</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000">7) It seems =
simpler to, for many of these fields, push values directly (as in OP_PUSHTX=
DATA from Johnson Lau) because the combo of flags to push the hash of a sin=
gle output&#39;s amount to emulate OP_AMOUNT looks &#39;general but annoyin=
g&#39;. It may make more sense to do the OP_PUSHTXDATA=C2=A0style opcode in=
stead. This also makes it simpler to think about the combinations of flags,=
 since it&#39;s really N independent multi-byte opcodes.</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000">Ultimately if we had OP_TXHASH available &qu=
ot;tomorrow&quot;, I would be able to build out the use cases I care about =
for CTV (and more). So I don&#39;t have an opposition on it with regards to=
 lack of function.</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><div class=3D"gmail_default">However, if one finds=
 the TXHASH approach acceptable, then you should also be relatively fine do=
ing APO, CTV, CSFS, TXHASH acceptable in any order (whenever &quot;ready&qu=
ot;), unless you are particularly sensitive to &quot;technical debt&quot; a=
nd &quot;soft fork=C2=A0processes&quot;. The only costs of doing something =
for CTV or APO given an eventual TXHASH=C2=A0is perhaps a wasted key versio=
n or the 32 byte argument of a NOP opcode and some code to maintain.</div><=
div class=3D"gmail_default"><br></div><div class=3D"gmail_default">Are ther=
e other costs I am missing?</div><div class=3D"gmail_default"></div></div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
However, as it pertains to actual rollout:</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">- OP_TXHASH+CSFSV doesn&#3=
9;t seem to be the &quot;full&quot; set of things needed (we still need e.g=
. OP_CAT, Upgraded &gt;=3D64 bit Math, TLUV or OP_TWEAK OP_TAPBRANCH OP_MAN=
IPULATETAPTREE, and more) to full realize covenanting power it intends to i=
ntroduce.=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000">- What sort of timeli=
ne would it take to ready something like TXHASH=C2=A0(and desired friends) =
given greater scope of testing and analysis (standalone=C2=A0+ compared to =
CTV)?</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:#000000">- Is there opposition from the =
community to this degree of general/recursive covenants?</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000">- Does it make &quot;more sense&quot; to invest the res=
earch and development effort that would go into proving=C2=A0TXHASH safe, f=
or example, into Simplicity instead?</div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000">Overall, <i>my opinion </i>is th=
at:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000">- TXHASH=C2=A0is an acceptable theoretical approach, and I am hap=
py to put more thought into it and maybe draft a prototype of it.</div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000">- I prefer CTV as a first step for pragmatic e=
ngineering and availability timeline reasons.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000">- If TXHASH were to take, optimistically, 2 years to develop and r=
eview, and then 1 year to activate, the &quot;path dependence of software&q=
uot; would put Bitcoin in a much better place were we to have CTV within 1 =
year and applications (that are to be a subset of TXHASH=C2=A0later) being =
built over the next few years enhanced in the future by TXHASH&#39;s availa=
bility.=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000">- There is an element o=
f expediency meritted for something like CTV insofar as it provides primiti=
ves to tackle time sensitive issues around privacy, scalability, self custo=
dy, and decentralization. The aforementioned properties may be difficult to=
 reclaim once given away (with the exception of perhaps scalability).</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000">- Bringing CTV to an implemented state of =
near-unanimous &quot;we could do this, technically&quot; is good for concre=
tely driving the process of review for any covenant proposals forward, irre=
spective of if we ultimately activate. (I.e., if there were a reason we cou=
ld not do CTV safely, it would likely have implications for any other futur=
e covenant)</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">Concretely, I&#39;m not going to stop advocating for CTV =
based on the above, but I&#39;m very happy to have something new in the mix=
 to consider!</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000">Best,</div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:#000000">Jeremy</div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:#000000"><br></div><div><div dir=3D"ltr=
" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"=
ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@J=
eremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"=
></a></div></div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Wed, Jan 26, 2022 at 9:23 AM Russell O&#39;Co=
nnor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding=
-left:1ex"><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 sign=
ificant amount of overlap in the applications that are enabled by the CTV a=
nd ANYPREVOUT proposals despite the fact that their primary applications (c=
ongestion control for CTV and eltoo lightning channels for ANYPREVOUT) are =
quite distinct.</div><div>In particular, ANYPREVOUT can enable most of the =
applications of CTV, albeit with a higher cost.=C2=A0 The primary functiona=
lity of CTV is to allow a scriptPubKey to make a commitment to its spending=
 transaction&#39;s hash with the input&#39;s TXID excluded from the hash.=
=C2=A0 This exclusion is necessary because the scriptPubKey is hashed into =
the input&#39;s TXID, and including the TXID would cause a cycle of hash co=
mmitments, which is impossible to construct.=C2=A0 On the other hand, ANYPR=
EVOUT defines a signature hash mode that similarly excludes the inputs TXID=
 for its purpose of rebindable signatures.</div><div><br></div><div>This me=
ans that ANYPREVOUT can mimic most of the properties of CTV by committing b=
oth 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 du=
e to this cycle between scriptPubKeys and the TXIDs that occur in all the s=
ighash modes.<br></div><div><br></div><div>The major differences between si=
mulating CTV via ANYPREVOUT and the actual CTV proposal is: (1) The cost of=
 simulating CTV.=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 signature, and 32 bytes for some public key, plus a few more bytes fo=
r various flags.=C2=A0 Some of that cost could be reduced by using the inne=
r public key (1 byte representation) and, if we had CAT, maybe by assemblin=
g the signature from reusable pieces (i.e. setting the nonce of the commite=
d signature equal to the public key).<br></div><div><br></div><div>The othe=
r major difference is: (2) CTV&#39;s transaction hash covers values such as=
 the number of inputs in the transaction and their sequence numbers, which =
ANYPREVOUT does 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 co=
mmitted to being 1, once the scriptpubkey&#39;s transaction id is known and=
 committed to the blockchain, the TXID of its spending transaction is deduc=
ible.=C2=A0 And if that transaction has outputs that have CTV commitments i=
n them, you can deduce their spending TXIDs in turn.=C2=A0 While this is a =
pretty neat feature, something that ANYPREVOUT cannot mimic, the main appli=
cation for it is listed as using congestion control to fund lightning chann=
els, fixing their TXIDs in advance of them being placed on chain.=C2=A0 How=
ever, if ANYPREVOUT were used to mimic CTV, then likely it would be eltoo c=
hannels that would be funded, and it isn&#39;t necessary to know the TXIDs =
of eltoo channels in advance in order to use them.</div><div><br></div><div=
><br></div><div><br></div><div>An Alternative Proposal::<br></div><div><br>=
</div><div>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.=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 an=
d compute a (tagged) txhash in accordance with that flag, and push the resu=
lting hash onto the stack.<br></div><div>OP_CHECKSIGFROMSTACKVERIFY would p=
op a pubkey, message, and signature from the stack and fail if the signatur=
e does not verify on that message.</div><div><br></div><div>CTV and TXHASH =
have roughly equivalent functionality.=C2=A0 &#39;CTV DROP&#39; can be simu=
lated by &#39;&lt;ctv_style_flag&gt; TXHASH EQUALVERIFY&#39;.=C2=A0 The rev=
erse is also true where &#39;&lt;ctv_style_flag&gt; TXHASH&#39; can be simu=
lated by CTV by &#39;&lt;ctv-result-from-witness-stack&gt; CTV&#39;, howeve=
r, as you can see, simulating TXHASH from CTV is much more expensive than t=
he other way around, because the resulting 32-byte hash result must be incl=
uded as part of the witness stack.</div><div><br></div><div>&#39;&lt;anypre=
vout-pubkey&gt; CHECKSIGVERIFY can be simulated by &#39;&lt;apo_style_flag&=
gt; TXHASH &lt;pubkey&gt; CHECKSIGFROMSTACKVERIFY&#39;.=C2=A0 Here we see t=
he advantage of pushing the hash value onto the stack.=C2=A0 APO can be sim=
ulated without 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 ANYP=
REVOUT applications, 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 piece=
s.=C2=A0 By giving users the ability to program their own use cases from co=
mponents, we get more applications out of fewer op codes!</div><div><br></d=
iv><div><br></div><div><br></div><div>Caveats::</div><div><br></div><div>Fi=
rst, I acknowledge that replicating the behaviour of CTV and ANYPREVOUT doe=
s cost a few more bytes than using the custom purpose built proposals thems=
elves.=C2=A0 That is the price to be paid when we choose the ability to pro=
gram solutions from pieces.=C2=A0 But we get to reap the advantages of bein=
g able to build more applications from these pieces.<br></div><div><br></di=
v><div>Unlike CTV, TXHASH is not NOP-compatable and can only be implemented=
 within tapscript.=C2=A0 In particular, bare CTV isn&#39;t possible with th=
is proposal.=C2=A0 However, this proposal doesn&#39;t preclude the possibil=
ity of having CTV added to legacy script in while having TXHASH added to ta=
pscript.</div><div><br></div><div>For similar reasons, TXHASH is not amenab=
le to extending the set of txflags at a later date.=C2=A0 In theory, one co=
uld have TXHASH abort-with-success when encountering an unknown set of flag=
s.=C2=A0 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 ord=
er incorrect would be catastrophic.=C2=A0 This behavior is manifestly diffe=
rent from the current batch of OP_SUCCESS opcodes that abort-with-success j=
ust by their mere presence, whether they would be executed or not.</div><di=
v><br></div><div>I believe the difficulties with upgrading TXHASH can be mi=
tigated by designing a robust set of TXHASH flags from the start.=C2=A0 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 cover=
ed; (5) input amounts are covered; (6) input scriptpubkeys are covered; (7)=
 number of inputs is covered; (8) output amounts are covered; (9) output sc=
riptpubkeys are covered; (10) number of outputs is covered; (11) the tapbra=
nch 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 cove=
red; (17) whether the one output position is covered; (18) whether the sigh=
ash flags are covered or not (note: whether or not the sighash flags are or=
 are not covered must itself be covered).=C2=A0 Possibly specifying which i=
nput or output position is covered in the single case and whether the posit=
ion is relative to the input&#39;s position or is an absolute position.</di=
v><div><br></div><div>That all said, even if other txhash flag modes are ne=
eded in the future, adding TXHASH2 always remains an option.<br></div><div>=
<br></div><div><br></div><div><br></div><div>Interactions with potential fu=
ture opcodes::<br></div><div><div><br></div><div>We should give some consid=
eration on how these opcodes may interact with future opcodes such as CAT, =
rolling SHA256 opcodes, or how it might interface with other covenant opcod=
es that may do things like, directly push input or output amounts onto the =
stack for computation purposes, opcodes which have been added to the Elemen=
ts project.</div><div><br></div><div>With CAT and/or rolling SHA256 opcodes=
 and/or existing SHA256 opcodes, the CHECKSIGFROMSTACKVERIFY could verify s=
ignatures on programmatically assembled messages.=C2=A0 Also, in combinatio=
n with multiple calls to TXHASH, could be used to create signatures that co=
mmit to complex subsets of transaction data.</div><div><br></div><div>If ne=
w opcodes are added to push parts of the transaction data direction onto th=
e stack, e.g. OP_INSPECTOUTPUTVALUE, there is perhaps concern that they wou=
ld obsolete TXHASH, since, in the presence of rolling SHA256 opcodes, TXHAS=
H could be simulated.=C2=A0 However, given that TXHASH can compactly create=
 a hash of large portions of transaction data, it seems unlikely that TXHAS=
H would fall into disuse.=C2=A0 Also, a combination of TXHASH and transacti=
on introspection opcodes can be used to build &quot;<i>subtractive covenant=
s</i>&quot;.</div><div><br></div><div>The usual way of building a covenant,=
 which we will call &quot;<i>additive </i><i>covenants</i>&quot;, is to pus=
h all the parts of the transaction data you would like to fix onto the stac=
k, hash it all together, and verify the resulting hash matches a fixed valu=
e.=C2=A0 Another way of building covenants, which we will call &quot;<i>sub=
tractive covenants</i>&quot;, is to push all the parts of the transaction d=
ata you would like to remain free onto the stack.=C2=A0 Then use rolling SH=
A256 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, the resulting hash value is verified to match a value returned by=
 TXHASH.=C2=A0 The ability to nicely build subtractive covenants depends on=
 the details of how the TXHASH hash value is constructed, something that I&=
#39;m told CTV has given consideration to.<br></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000fa4c3905d6838cba--