Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Thu, Feb 17, 2022 at 9:27 AM Anthony Towns  wrote:

>
> I guess that's all partly dependent on thinking that, TXHASH isn't
> great for tx introspection (especially without CAT) and, (without tx
> introspection and decent math opcodes), DLCs already provide all the
> interesting oracle behaviour you're really going to get...
>

You left out CSFSV's ability to do pubkey delegation.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Anthony Towns via bitcoin-dev]

On Mon, Feb 07, 2022 at 09:16:10PM -0500, Russell O'Connor via bitcoin-dev 
wrote:
> > > For more complex interactions, I was imagining combining this TXHASH
> > > proposal with CAT and/or rolling SHA256 opcodes.
> Indeed, and we really want something that can be programmed at redemption
> time.

I mean, ideally we'd want something that can be flexibly programmed at
redemption time, in a way that requires very few bytes to express the
common use cases, is very efficient to execute even if used maliciously,
is hard to misuse accidently, and can be cleanly upgraded via soft fork
in the future if needed?

That feels like it's probably got a "fast, cheap, good" paradox buried
in there, but even if it doesn't, it doesn't seem like something you
can really achieve by tweaking around the edges?

> That probably involves something like how the historic MULTISIG worked by
> having list of input / output indexes be passed in along with length
> arguments.
> 
> I don't think there will be problems with quadratic hashing here because as
> more inputs are list, the witness in turns grows larger itself.

If you cache the hash of each input/output, it would mean each byte of
the witness would be hashing at most an extra 32 bytes of data pulled
from that cache, so I think you're right. Three bytes of "script" can
already cause you to rehash an additional ~500 bytes (DUP SHA256 DROP),
so that should be within the existing computation-vs-weight relationship.

If you add the ability to hash a chosen output (as Rusty suggests, and
which would allow you to simulate SIGHASH_GROUP), your probably have to
increase your cache to cover each outputs' scriptPubKey simultaneously,
which might be annoying, but doesn't seem fatal.

> That said, your SIGHASH_GROUP proposal suggests that some sort of
> intra-input communication is really needed, and that is something I would
> need to think about.

I think the way to look at it is that it trades off spending an extra
witness byte or three per output (your way, give or take) vs only being
able to combine transactions in limited ways (sighash_group), but being
able to be more optimised than the more manual approach.

That's a fine tradeoff to make for something that's common -- you
save onchain data, make something easier to use, and can optimise the
implementation so that it handles the common case more efficiently.

(That's a bit of a "premature optimisation" thing though -- we can't
currently do SIGHASH_GROUP style things, so how can you sensibly justify
optimising it because it's common, when it's not only currently not
common, but also not possible? That seems to me a convincing reason to
make script more expressive)

> While normally I'd be hesitant about this sort of feature creep, when we
> are talking about doing soft-forks, I really think it makes sense to think
> through these sorts of issues (as we are doing here).

+1

I guess I especially appreciate your goodwill here, because this has
sure turned out to be a pretty long message as I think some of these
things through out loud :)

> > "CAT" and "CHECKSIGFROMSTACK" are both things that have been available in
> > elements for a while; has anyone managed to build anything interesting
> > with them in practice, or are they only useful for thought experiments
> > and blog posts? To me, that suggests that while they're useful for
> > theoretical discussion, they don't turn out to be a good design in
> > practice.
> Perhaps the lesson to be drawn is that languages should support multiplying
> two numbers together.

Well, then you get to the question of whether that's enough, or if
you need to be able to multiply bignums together, etc? 

I was looking at uniswap-like things on liquid, and wanted to do constant
product for multiple assets -- but you already get the problem that "x*y
< k" might overflow if the output values x and y are ~50 bits each, and
that gets worse with three assets and wanting to calculate "x*y*z < k",
etc. And really you'd rather calculate "a*log(x) + b*log(y) + c*log(z)
< k" instead, which then means implementing fixed point log in script...

> Having 2/3rd of the language you need to write interesting programs doesn't
> mean that you get 2/3rd of the interesting programs written.

I guess to abuse that analogy: I think you're saying something like
we've currently got 67% of an ideal programming language, and CTV
would give us 68%, but that would only take us from 10% to 11% of the
interesting programs. I agree txhash might bump that up to, say, 69%
(nice) but I'm not super convinced that even moves us from 11% to 12%
of interesting programs, let alone a qualitative leap to 50% or 70%
of interesting programs.

It's *possible* that the ideal combination of opcodes will turn out to
be CAT, TXHASH, CHECKSIGFROMSTACK, MUL64LE, etc, but it feels like it'd
be better working something out that fits together well, rather than
adding things piecemeal and hoping we don't spend all that effort to
end up in a local optimum 

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell 
wrote:

> Jeremy Rubin  writes:
> > Hi Rusty,
> >
> > Please see my post in the other email thread
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
> >
> > The differences in this regard are several, and worth understanding
> beyond
> > "you can iterate CTV". I'd note a few clear examples for showing that
> "CTV
> > is just as powerful" is not a valid claim:
> >
> > 1) CTV requires the contract to be fully enumerated and is non-recursive.
> > For example, a simple contract that allows n participants to take an
> action
> > in any order requires factorially many pre-computations, not just linear
> or
> > constant. For reference, 24! is about 2**80. Whereas for a more
> > interpretive covenant -- which is often introduced with the features for
> > recursion -- you can compute the programs for these addresses in constant
> > time.
> > 2) CTV requires the contract to be fully enumerated: For example, a
> simple
> > contract one could write is "Output 0 script matches Output 1", and the
> set
> > of outcomes is again unbounded a-priori. With CTV you need to know the
> set
> > of pairs you'd like to be able to expand to a-priori
> > 3) Combining 1 and 2, you could imagine recursing on an open-ended thing
> > like creating many identical outputs over time but not constraining what
> > those outputs are. E.g., Output 0 matches Input 0, Output 1 matches
> Output
> > 2.
>
> Oh agreed.  It was distinction of "recursive" vs "not recursive" which
> was less useful in this context.
>
> "limited to complete enumeration" is the more useful distinction: it's a
> bright line between CTV and TXHASH IMHO.
>

If TXHASH is limited to requiring the flags be included in the hash (as is
done with sighash) I believe TXHASH has the same "up front" nature that CTV
has.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Rusty Russell via bitcoin-dev]

Jeremy Rubin  writes:
> Hi Rusty,
>
> Please see my post in the other email thread
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
>
> The differences in this regard are several, and worth understanding beyond
> "you can iterate CTV". I'd note a few clear examples for showing that "CTV
> is just as powerful" is not a valid claim:
>
> 1) CTV requires the contract to be fully enumerated and is non-recursive.
> For example, a simple contract that allows n participants to take an action
> in any order requires factorially many pre-computations, not just linear or
> constant. For reference, 24! is about 2**80. Whereas for a more
> interpretive covenant -- which is often introduced with the features for
> recursion -- you can compute the programs for these addresses in constant
> time.
> 2) CTV requires the contract to be fully enumerated: For example, a simple
> contract one could write is "Output 0 script matches Output 1", and the set
> of outcomes is again unbounded a-priori. With CTV you need to know the set
> of pairs you'd like to be able to expand to a-priori
> 3) Combining 1 and 2, you could imagine recursing on an open-ended thing
> like creating many identical outputs over time but not constraining what
> those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Output
> 2.

Oh agreed.  It was distinction of "recursive" vs "not recursive" which
was less useful in this context.

"limited to complete enumeration" is the more useful distinction: it's a
bright line between CTV and TXHASH IMHO.

> I'll close by repeating : Whether that [the recursive/open ended
> properties] is an issue or not precluding this sort of design or not, I
> defer to others.

Yeah.  There's been some feeling that complex scripting is bad, because
people can lose money (see the various attempts to defang
SIGHASH_NOINPUT).  I reject that; since script exists, we've crossed the
Rubicon, so let's make the tools as clean and clear as we can.

Cheers!
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Tue, Feb 15, 2022 at 1:57 PM Jeremy Rubin 
wrote:

> Hi Rusty,
>
> Please see my post in the other email thread
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
>
> The differences in this regard are several, and worth understanding beyond
> "you can iterate CTV". I'd note a few clear examples for showing that "CTV
> is just as powerful" is not a valid claim:
>
> 1) CTV requires the contract to be fully enumerated and is non-recursive.
> For example, a simple contract that allows n participants to take an action
> in any order requires factorially many pre-computations, not just linear or
> constant. For reference, 24! is about 2**80. Whereas for a more
> interpretive covenant -- which is often introduced with the features for
> recursion -- you can compute the programs for these addresses in constant
> time.
> 2) CTV requires the contract to be fully enumerated: For example, a simple
> contract one could write is "Output 0 script matches Output 1", and the set
> of outcomes is again unbounded a-priori. With CTV you need to know the set
> of pairs you'd like to be able to expand to a-priori
> 3) Combining 1 and 2, you could imagine recursing on an open-ended thing
> like creating many identical outputs over time but not constraining what
> those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Output
> 2.
>
> I think for your point the inverse seems to hold: for the limited
> situations we might want to set up, CTV often ends up being sufficient
> because usually we can enumerate all the possible outcomes we'd like (or at
> least find a mapping onto such a construction). CTV is indeed very
> powerful, but as I demonstrated above, not powerful in the same way
> ("Complexity Class") that OP_TX or TXHASH might be.
>

Just to be clear, if OP_TXHASH is restricted to including the flags for the
values to be hashed (at least for OP_TXHASH0), we don't appear to enter
recursive covenant territory, as long as we remain without OP_CAT.


> At the very least we should clearly understand *what* and *why* we are
> advocating for more sophisticated designs and have a thorough understanding
> of the protocol complexity we are motivated to introduce the expanded
> functionality. Further, if one advocates for TX/TXHASH on a featureful
> basis, it's at least a technical ACK on the functionality CTV is
> introducing (as it is a subset) and perhaps a disagreement on project
> management, which I think is worth noting. There is a very wide gap between
> "X is unsafe" and "I prefer Y which X is a subset of ''.
>

I'm certainly of the opinion we should have some feature to enable the
commitment of outputs.  It seems quite useful in various protocols.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Jeremy Rubin via bitcoin-dev]

Hi Rusty,

Please see my post in the other email thread
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html

The differences in this regard are several, and worth understanding beyond
"you can iterate CTV". I'd note a few clear examples for showing that "CTV
is just as powerful" is not a valid claim:

1) CTV requires the contract to be fully enumerated and is non-recursive.
For example, a simple contract that allows n participants to take an action
in any order requires factorially many pre-computations, not just linear or
constant. For reference, 24! is about 2**80. Whereas for a more
interpretive covenant -- which is often introduced with the features for
recursion -- you can compute the programs for these addresses in constant
time.
2) CTV requires the contract to be fully enumerated: For example, a simple
contract one could write is "Output 0 script matches Output 1", and the set
of outcomes is again unbounded a-priori. With CTV you need to know the set
of pairs you'd like to be able to expand to a-priori
3) Combining 1 and 2, you could imagine recursing on an open-ended thing
like creating many identical outputs over time but not constraining what
those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Output
2.

I think for your point the inverse seems to hold: for the limited
situations we might want to set up, CTV often ends up being sufficient
because usually we can enumerate all the possible outcomes we'd like (or at
least find a mapping onto such a construction). CTV is indeed very
powerful, but as I demonstrated above, not powerful in the same way
("Complexity Class") that OP_TX or TXHASH might be.

At the very least we should clearly understand *what* and *why* we are
advocating for more sophisticated designs and have a thorough understanding
of the protocol complexity we are motivated to introduce the expanded
functionality. Further, if one advocates for TX/TXHASH on a featureful
basis, it's at least a technical ACK on the functionality CTV is
introducing (as it is a subset) and perhaps a disagreement on project
management, which I think is worth noting. There is a very wide gap between
"X is unsafe" and "I prefer Y which X is a subset of ''.

I'll close by repeating : Whether that [the recursive/open ended
properties] is an issue or not precluding this sort of design or not, I
defer to others.

Best,

Jeremy




Best,

Jeremy
--
@JeremyRubin 


On Tue, Feb 15, 2022 at 12:46 AM Rusty Russell 
wrote:

> Jeremy Rubin  writes:
> > Rusty,
> >
> > Note that this sort of design introduces recursive covenants similarly to
> > how I described above.
> >
> > Whether that is an issue or not precluding this sort of design or not, I
> > defer to others.
>
> Good point!
>
> But I think it's a distinction without meaning: AFAICT iterative
> covenants are possible with OP_CTV and just as powerful, though
> technically finite.  I can constrain the next 100M spends, for
> example: if I insist on those each having incrementing nLocktime,
> that's effectively forever.
>
> Thanks!
> Rusty.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Rusty Russell via bitcoin-dev]

Jeremy Rubin  writes:
> Rusty,
>
> Note that this sort of design introduces recursive covenants similarly to
> how I described above.
>
> Whether that is an issue or not precluding this sort of design or not, I
> defer to others.

Good point!

But I think it's a distinction without meaning: AFAICT iterative
covenants are possible with OP_CTV and just as powerful, though
technically finite.  I can constrain the next 100M spends, for
example: if I insist on those each having incrementing nLocktime,
that's effectively forever.

Thanks!
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Jeremy Rubin via bitcoin-dev]

Rusty,

Note that this sort of design introduces recursive covenants similarly to
how I described above.

Whether that is an issue or not precluding this sort of design or not, I
defer to others.

Best,

Jeremy


On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Russell O'Connor via bitcoin-dev 
> writes:
> > 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.
>
> It may be worth noting that OP_TXHASH can be further decomposed into
> OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256).
>
> OP_TX would place the concatenated selected fields onto the stack
> (rather than hashing them) This is more compact for some tests
> (e.g. testing tx version for 2 is "OP_TX(version) 1 OP_EQUALS" vs
> "OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS"), and also range
> testing (e.g amount less than X or greater than X, or less than 3 inputs).
>
> > 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.
>
> These easily map onto OP_TX, "(1) the version is pushed as u32, (2) the
> locktime is pushed as u32, ...".
>
> We might want to push SHA256() of scripts instead of scripts themselves,
> to reduce possibility of DoS.
>
> I suggest, also, that 14 (and similarly 15) be defined two bits:
> 00 - no inputs
> 01 - all inputs
> 10 - current input
> 11 - pop number from stack, fail if >= number of inputs or no stack elems.
>
> Cheers,
> Rusty.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Rusty Russell via bitcoin-dev]

Russell O'Connor via bitcoin-dev  writes:
> 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.

It may be worth noting that OP_TXHASH can be further decomposed into
OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256).

OP_TX would place the concatenated selected fields onto the stack
(rather than hashing them) This is more compact for some tests
(e.g. testing tx version for 2 is "OP_TX(version) 1 OP_EQUALS" vs
"OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS"), and also range
testing (e.g amount less than X or greater than X, or less than 3 inputs).

> 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.

These easily map onto OP_TX, "(1) the version is pushed as u32, (2) the
locktime is pushed as u32, ...".

We might want to push SHA256() of scripts instead of scripts themselves,
to reduce possibility of DoS.

I suggest, also, that 14 (and similarly 15) be defined two bits:
00 - no inputs
01 - all inputs
10 - current input
11 - pop number from stack, fail if >= number of inputs or no stack elems.

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Mon, Jan 31, 2022 at 8:16 PM Anthony Towns  wrote:

> On Fri, Jan 28, 2022 at 08:56:25AM -0500, Russell O'Connor via bitcoin-dev
> wrote:
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> > For more complex interactions, I was imagining combining this TXHASH
> > proposal with CAT and/or rolling SHA256 opcodes.  If TXHASH ended up
> > supporting relative or absolute input/output indexes then users could
> > assemble the hashes of the particular inputs and outputs they care about
> > into a single signed message.
>
> That's certainly possible, but it sure seems overly complicated and
> error prone...
>

Indeed, and we really want something that can be programmed at redemption
time.
That probably involves something like how the historic MULTISIG worked by
having list of input / output indexes be passed in along with length
arguments.

I don't think there will be problems with quadratic hashing here because as
more inputs are list, the witness in turns grows larger itself.  The amount
of stack elements that can be copied is limited by a constant (3DUP).
Certainly care is needed here, but also keep in mind that an OP_HASH256
does a double hash and costs one weight unit.

That said, your SIGHASH_GROUP proposal suggests that some sort of
intra-input communication is really needed, and that is something I would
need to think about.

While normally I'd be hesitant about this sort of feature creep, when we
are talking about doing soft-forks, I really think it makes sense to think
through these sorts of issues (as we are doing here).


> > I don't think there is much in the way of lessons to be drawn from how we
> > see Bitcoin Script used today with regards to programs built out of
> > reusable components.
>
> I guess I think one conclusion we should draw is some modesty in how
> good we are at creating general reusable components. That is, bitcoin
> script looks a lot like a relatively general expression language,
> that should allow you to write interesting things; but in practice a
> lot of it was buggy (OP_VER hardforks and resource exhaustion issues),
> or not powerful enough to actually be interesting, or too complicated
> to actually get enough use out of [0].
>

> TXHASH + CSFSV won't be enough by itself to allow for very interesting
> > programs Bitcoin Script yet, we still need CAT and friends for that,
>
> "CAT" and "CHECKSIGFROMSTACK" are both things that have been available in
> elements for a while; has anyone managed to build anything interesting
> with them in practice, or are they only useful for thought experiments
> and blog posts? To me, that suggests that while they're useful for
> theoretical discussion, they don't turn out to be a good design in
> practice.
>

Perhaps the lesson to be drawn is that languages should support multiplying
two numbers together.

Having 2/3rd of the language you need to write interesting programs doesn't
mean that you get 2/3rd of the interesting programs written.

But beyond that, there is a lot more to a smart contract than just the
Script.  Dmitry Petukhov has a fleshed out design for Asset based lending
on liquid at https://ruggedbytes.com/articles/ll/, despite the limitations
of (pre-taproot) Elements Script.  But to make it a real thing you need
infrastructure for working with partial transactions, key management, etc.

> but
> > CSFSV is at least a step in that direction.  CSFSV can take arbitrary
> > messages and these messages can be fixed strings, or they can be hashes
> of
> > strings (that need to be revealed), or they can be hashes returned from
> > TXHASH, or they can be locktime values, or they can be values that are
> > added or subtracted from locktime values, or they can be values used for
> > thresholds, or they can be other pubkeys for delegation purposes, or they
> > can be other signatures ... for who knows what purpose.
>
> I mean, if you can't even think of a couple of uses, that doesn't seem
> very interesting to pursue in the near term? CTV has something like half
> a dozen fairly near-term use cases, but obviously those can all be done
> just with TXHASH without a need for CSFS, and likewise all the ANYPREVOUT
> things can obviously be done via CHECKSIG without either TXHASH or CSFS...
>
> To me, the point of having CSFS (as opposed to CHECKSIG) seems to be
> verifying that an oracle asserted something; but for really simply boolean
> decisions, doing that via a DLC seems better in general since that moves
> more of the work off-chain; and for the case where the signature is being
> used to authenticate input into the script rather than just gating a path,
> that feels a bit like a weaker version of graftroot?
>

I didn't really mean this as a list of applications; it was a list of
values that CSFSV composes with. Applications include delegation of pubkeys
and oracles, and, in the presence of CAT and transaction reflection
primitives, presumably many more things.


> I guess I'd still be interested 

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Anthony Towns via bitcoin-dev]

On Thu, Jan 27, 2022 at 07:18:54PM -0500, James O'Beirne via bitcoin-dev wrote:
> > I don't think implementing a CTV opcode that we expect to largely be
> > obsoleted by a TXHASH at a later date is yielding good value from a soft
> > fork process.
> Caching for something
> like TXHASH looks to me like a whole different ballgame relative to CTV,
> which has a single kind of hash.

I don't think caching is a particular problem even for the plethora of
flags Russell described: you cache each value upon use, and reuse that
cached item if it's needed for other signatures within the tx; sharing
with BIP 143, 341 or 342 signatures as appropriate. Once everything's
cached, each signature then only requires hashing about 32*17+4 = ~548
bytes, and you're only hashing each part of the transaction once in
order to satisfy every possible flag.

> Even if we were to adopt something like TXHASH, how long is it going to
> take to develop, test, and release?

I think the work to release something like TXHASH is all in deciding:

 - if TXHASH or CTV or something else is the better "UX"
 - what is a good tx to message algorithm and how it should be
   parametized
 - what's an appropriate upgrade path for the TXHASH/CTV/??? mechanism

BIP 119 provides one answer to each of those, but you still have to do
the work to decide if its a *good* answer to each of them.

> My guess is "a while" - 

If we want to get a good answer to those questions, it might be true
that it takes a while; but even if we want to rush ahead with more of
a "well, we're pretty sure it's not going to be a disaster" attitude,
we can do that with TXHASH (almost) as easily as with CTV.

> The utility of vaulting seems
> underappreciated among consensus devs and it's something I'd like to write
> about soon in a separate post.

I think most of the opposition is just that support for CTV seems to be
taking the form "something must be done; this is something, therefore
it must be done"...

I'd be more comfortable if the support looked more like "here are the
alternatives to CTV, and here's the advantages and drawbacks for each,
here's how they interact with other ideas, and here's why we think,
on balance, we think this approach is the best one". But mostly the
alternatives are dismissed with "this will take too long" or "this enables
recursive covenants which someone (we don't know who) might oppose".

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

The hash would normally also cover the hash flags in use, and would be
different in those two cases.

But yes, it seems at the last minute I did include a suggestion to disable
covering the flag themselves in the hash and appear to have accidentally
allowed for recursive covenants (a common occurrence when designing
opcodes).

On Sat, Jan 29, 2022 at 12:01 PM Jeremy Rubin  wrote:

>
>
>
>> Perhaps there is some misunderstanding.  TXHASH + CSFSV doesn't allow for
>> complex or recursive covenants.  Typically CAT is needed, at minimum, to
>> create those sorts of things.  TXHASH still amounts to deploying a
>> non-recursive covenant construction.
>>
>>
> This seems false to me.
>
>  txhash  scriptpubkey> txhash equalverify
>
> Is that not a recursive covenant? With a little extra work you can also
> control for amounts and stuff.
>
>
>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Jeremy Rubin via bitcoin-dev]

Perhaps there is some misunderstanding.  TXHASH + CSFSV doesn't allow for
complex or recursive covenants.  Typically CAT is needed, at minimum, to
create those sorts of things.  TXHASH still amounts to deploying a
non-recursive covenant construction.


This seems false to me.

 txhash  txhash equalverify

Is that not a recursive covenant? With a little extra work you can also
control for amounts and stuff.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Fri, Jan 28, 2022 at 10:14 AM James O'Beirne 
wrote:

> > Technical debt isn't a measure of weight of transactions.
>
> Sorry, my original sentence was a little unclear. I meant to say that the
> notion that CTV is just a subpar waypoint en route to a more general
> covenant system may not be accurate if it is a more efficient way (in terms
> of chainstate/weight) to express highly useful patterns like vaults. In
> that case, characterizing CTV as technical debt wouldn't be right.
>

It only costs a few more weight units, on the order of 2 or 3, to use
TXHASH in place of CTV.  Notably, the reverse, using CTV in place of
TXHASH, is much more expensive, requiring more than 32 weight units.


> > Our only option here is to be mindful of the long term implications of
> the design choices we are making today.
>
> Your points are well taken - I don't think anyone is arguing against
> thinking hard about consensus changes. But I have yet to see a proposal for
> covenants that is as efficient on-chain and easy to reason about as CTV is.
>
> I also think there's some value in "legging into" covenants by deploying a
> simple, non-recursive construction like CTV that services some very
> important uses, and then taking as much time as necessary to think about
> how to solve more existential problems, like UTXO scalability, that likely
> require a recursive covenant construction.
>
> There doesn't have to be mutual exclusion in the approaches, especially
> when the maintenance burden of CTV seems to be so low. If we end up
> deploying something that requires a wider variety of in-script hashing, it
> seems likely that CTV's hash will be able to "free ride" on whatever more
> general sighash cache structure we come up with.
>

Perhaps there is some misunderstanding.  TXHASH + CSFSV doesn't allow for
complex or recursive covenants.  Typically CAT is needed, at minimum, to
create those sorts of things.  TXHASH still amounts to deploying a
non-recursive covenant construction.

With regards to CTV, in short my primary criticisms are (1) Push semantics
is preferable to verify semantics, because simulating verify semantics from
push is cheap, while simulating push semantics from verify is not
particularly cheap.
And (2) given Push semantics we ought to have parameters to support both
CTV-style hashes and APO-style hashes (which in the presence of CSFSV gives
us APO applications), and, while we are at it, as many other style hashes
as we can reasonably devise so we don't have to go through yet another
soft-fork process every time someone comes up with a new subset of
transaction data they would like to be hashed for their application.

I understand why CTV was designed with verify semantics: it would like to
be NOP compatible.  That certainly made sense pre-tapscript.  I just
haven't (yet) found the use cases for that compatibility to be compelling
in a post-tapscript world.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Jeremy via bitcoin-dev]

I probably need to reset it -- I ran into some issues with the IBD latch
bug IIRC and had difficulty producing new blocks.

I sent funds as a manual faucet to at least one person... not aware of
anyone else finding use for the signet. In part this is due to the fact
that in order to run a signet, you also kind of need to run some kind of
faucet on it, which wasn't readily available when I launched it previously.
I think I can use https://github.com/jsarenik/bitcoin-faucet-shell now
though.

Usually people are using Regtest to play around with CTV less so Signet.
There is value in a signet, but I don't think that "there's not a signet
for it" is a blocking issue v.s. nice to have.
--
@JeremyRubin 



On Fri, Jan 28, 2022 at 6:18 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Jan 28, 2022 at 01:14:07PM +, Michael Folkson via bitcoin-dev
> wrote:
> > There is not even a custom signet with CTV (as far as I know)
>
> https://twitter.com/jeremyrubin/status/1339699281192656897
>
>
> signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
> addnode=50.18.75.225
>
> But I think there's only been a single coinbase consolidation tx, and no
> actual CTV transactions?
>
> Cheers,
> aj
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[James O'Beirne via bitcoin-dev]

> Technical debt isn't a measure of weight of transactions.

Sorry, my original sentence was a little unclear. I meant to say that the
notion that CTV is just a subpar waypoint en route to a more general
covenant system may not be accurate if it is a more efficient way (in terms
of chainstate/weight) to express highly useful patterns like vaults. In
that case, characterizing CTV as technical debt wouldn't be right.

> Our only option here is to be mindful of the long term implications of
the design choices we are making today.

Your points are well taken - I don't think anyone is arguing against
thinking hard about consensus changes. But I have yet to see a proposal for
covenants that is as efficient on-chain and easy to reason about as CTV is.

I also think there's some value in "legging into" covenants by deploying a
simple, non-recursive construction like CTV that services some very
important uses, and then taking as much time as necessary to think about
how to solve more existential problems, like UTXO scalability, that likely
require a recursive covenant construction.

There doesn't have to be mutual exclusion in the approaches, especially
when the maintenance burden of CTV seems to be so low. If we end up
deploying something that requires a wider variety of in-script hashing, it
seems likely that CTV's hash will be able to "free ride" on whatever more
general sighash cache structure we come up with.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Anthony Towns via bitcoin-dev]

On Fri, Jan 28, 2022 at 01:14:07PM +, Michael Folkson via bitcoin-dev wrote:
> There is not even a custom signet with CTV (as far as I know) 

https://twitter.com/jeremyrubin/status/1339699281192656897

signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
addnode=50.18.75.225

But I think there's only been a single coinbase consolidation tx, and no
actual CTV transactions?

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne 
wrote:

> > I don't think implementing a CTV opcode that we expect to largely be
> obsoleted by a TXHASH at a later date is yielding good value from a soft
> fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it).
> You're presenting a novel idea that, as far as I know, hasn't had much time
> to bake in public. Like Jeremy, I'm concerned by the combinatorial growth
> of flags and the implications that has for testing. Caching for something
> like TXHASH looks to me like a whole different ballgame relative to CTV,
> which has a single kind of hash.
>

Let's not overstate the concern around the combinatorics of TXHASH.   It's
not like there is a vast amount of cross-flag interaction we are talking
about here.  There are also a combinatorial number of ways of assembling
opcodes in Bitcoin script, but we aren't required to exhaustively test
every single possible Script program.


> Even if we were to adopt something like TXHASH, how long is it going to
> take to develop, test, and release? My guess is "a while" - in the
> meantime, users of Bitcoin are without a vault strategy that doesn't
> require either presigning transactions with ephemeral keys (operationally
> difficult) or multisig configurations that would make Rube Goldberg blush
> (operationally difficult and precarious). The utility of vaulting seems
> underappreciated among consensus devs and it's something I'd like to write
> about soon in a separate post.
>
> > The strongest argument I can make in favour of CTV would be something
> like: "We definitely want bare CTV and if we are going to add CTV to legacy
> script (since we cannot use TXHASH in legacy script), then it is actually
> easier not to exclude it from tapscript, even if we plan to add TXHASH to
> tapscript as well."
>
> Another argument for CTV (which I find especially persuasive) is its
> simplicity - it's relatively easy to reason about and, at this point,
> pretty well understood. It seems like a low-risk change relative to some of
> the other covenant proposals, nearly all of which elicit a good deal of
> headscratching (at least from me) and seem to require not only larger
> on-chain footprints but sizable code changes.
>


> > I am sensitive to technical debt and soft fork processes
>

> If OP_CTV ends up being the most practical approach for vaulting - among
> other things - in terms of weight (which it seems to be at the moment) I
> don't think "technical debt" is an applicable term.
>

Technical debt isn't a measure of weight of transactions.  It's a measure
of the code complexity needed to implement, in this case, a Bitcoin Script
interpreter.

By itself, adding a single new hash format for CTV isn't that complex, and
it is certainly simpler than this TXHASH proposal.  But then we need to add
another two slightly different hash formats for APO support.  And tomorrow
we will need yet another set of transaction hash formats for the next
thing, and so on, with each instance requiring going through its own
soft-fork process.  It is at that point we end up with something more
complicated and with more deployment risk than if we had just done
something like TXHASH at the very beginning.  But unlike other programming
environments, we cannot refactor our way out of such a situation.  We
cannot make a new script version while deprecating the old one.  Our only
option here is to be mindful of the long term implications of the design
choices we are making today.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns  wrote:

> > An Alternative Proposal::
> >  ...
>
> > For similar reasons, TXHASH is not amenable to extending the set of
> txflags
> > at a later date.
>
> > 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 [...]
>
> I don't think that's really feasible -- eg, what you propose don't cover
> SIGHASH_GROUP:
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
>

For more complex interactions, I was imagining combining this TXHASH
proposal with CAT and/or rolling SHA256 opcodes.  If TXHASH ended up
supporting relative or absolute input/output indexes then users could
assemble the hashes of the particular inputs and outputs they care about
into a single signed message.


> > That all said, even if other txhash flag modes are needed in the future,
> > adding TXHASH2 always remains an option.
>
> I think baking this in from day 0 might be better: make TXHASH be
> a multibyte opcode, so that when you decode "0xBB" on the stack,
> you also decode a serialize.h:VarInt as the version number.


I wouldn't be opposed to this.

> ' CHECKSIGVERIFY can be simulated by '
> TXHASH  CHECKSIGFROMSTACKVERIFY'.
>
> I don't think that's quite right. BIP 118 anyprevout is done by taking
> the pubkey "P", marking it as "APO-capable" (by prefixing it with 0x01),
> and then getting a sighash and sig from the witness. Doing the same
> with TXHASH/CSFSV would just be replacing " CHECKSIGVERIFY" with
> "TXHASH  CSFSV" with the witness providing both the signature and
> txhash flag, just as separate elements rather than concatenated. (The
> "APO-capable" part is implicit in the "TXHASH" opcode)
>

Indeed. The TXHASH variant does require splitting the signature and txhash
flag across two stack items.  So it wouldn't be an operationally identical
drop in replacement.


> > 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!
>
> While I see the appeal of this from a language design perspective;
> I'm not sure it's really the goal we want. When I look at bitcoin's
> existing script, I see a lot of basic opcodes to do simple arithmetic and
> manipulate the stack in various ways, but the opcodes that are actually
> useful are more "do everything at once" things like check(multi)sig or
> sha256. It seems like what's most useful on the blockchain is a higher
> level language, rather than more of blockchain assembly language made
> up of small generic pieces. I guess "program their own use cases from
> components" seems to be coming pretty close to "write your own crypto
> algorithms" here...
>

Which operations in Script are actually composable today?

CHECKSIG composes with nothing else (other than possibly other CHECKSIGs)
as there are no other operations that manipulate pubkey keys or signature
data.

CLTV and CSV in principle can be composed with addition and subtraction and
comparison operations.  But where are you going to get other values to add
and subtract from?  I suppose you could compare the relative and absolute
locktimes to each other.

What do the HASH functions compose with?  Without CAT you cannot construct
messages to hash.  You can hash the result of the arithmetic operations,
but you are limited to hashing 32-bit (or 33-bit if you are generous)
strings, which is too little entropy to have any security properties.  You
can hash a public key or a signature I suppose.

I don't think there is much in the way of lessons to be drawn from how we
see Bitcoin Script used today with regards to programs built out of
reusable components.  User's haven't been composing programs, not because
they don't find composition useful, but rather because the existing
primitives do not lend themselves to being composed at all.

There is one aspect of Bitcoin Script that is composable, which is
(monotone) boolean combinations of the few primitive transaction conditions
that do exist.  The miniscript language captures nearly the entirety of
what is composable in Bitcoin Script today: which amounts to conjunctions,
disjunctions (and thresholds) of signatures, locktimes, and revealing hash
preimages.

TXHASH + CSFSV won't be enough by itself to allow for very interesting
programs Bitcoin Script yet, we still need CAT and friends for that, but
CSFSV is at least a step in that direction.  CSFSV can take arbitrary
messages and these messages can be fixed strings, or they can be hashes of
strings (that need to be revealed), or they can be hashes returned from
TXHASH, or they can be locktime values, or they can 

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Michael Folkson via bitcoin-dev]

> Even if we were to adopt something like TXHASH, how long is it going to take 
> to develop, test, and release? My guess is "a while" - in the meantime, users 
> of Bitcoin are without a vault strategy that doesn't require either 
> presigning transactions with ephemeral keys (operationally difficult) or 
> multisig configurations that would make Rube Goldberg blush (operationally 
> difficult and precarious).

To me this seems to be jumping ahead a number of steps from where we are at the 
current time. If the ecosystem was widely using all the tools available to them 
at the current time (MuSig(2), Taproot trees to embed complex scripts, 
Miniscript etc), was testing out upcoming available tools like threshold key 
aggregation schemes (e.g. FROST) on signets and the final missing piece was a 
covenant opcode to avoid the deleted key requirement then the argument for 
urgency would be stronger. I would still share the concerns I and many others 
have repeated over rushing soft forks and treating mainnet as a testbed for new 
use cases rather than the final destination for changes that will stand the 
test of time. But I would be a lot more sympathetic to that argument.

This isn't a criticism of the ecosystem or individual vault projects like 
Revault, it is clearly still very early. darosior (Revault) is working on 
getting a first version of Miniscript finalized and in Core [0] and I'm 
assuming will be part of the effort to get Taproot support in Miniscript 
assuming that initial effort succeeds. Murch is tracking basic send and receive 
to the P2TR addresses (not complex scripts, multisig, MuSig(2), merely single 
key spends) in the ecosystem [1] and there is still a long way to go there.

There are a bunch of covenant opcodes that have been enabled on Liquid [2] that 
I haven't heard yet of anyone building vault prototypes with. It would be good 
to get others (TLUV, TXHASH) in future. There is not even a custom signet with 
CTV (as far as I know) for those who subscribe to the view that we must rush to 
get CTV activated on mainnet as soon as possible with no thought to what 
opcodes might follow.

When this discussion focuses on the pros and cons of various proposals and how 
they are being tested and used in prototypes on signets, sidechains I think it 
is really productive. But when it gets onto urgency (or worse activation 
speculation) I am just perplexed. That viewpoint seems to completely ignore 
where we are currently with Taproot use and tooling (on which most vault 
designs will presumably build) and even more perplexingly where we are with 
vault prototypes on signets, sidechains.

I am sure at some point in the future we will have various vault prototypes on 
signets, sidechains making use of Taproot, Miniscript, MuSig(2), FROST etc and 
crying out for a covenant opcode or sighash flag to go into production on 
mainnet. But we seem miles away from that at the present time.

[0]: https://github.com/bitcoin/bitcoin/pull/24147
[1]: https://en.bitcoin.it/wiki/Bech32_adoption
[2]: 
https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

‐‐‐ Original Message ‐‐‐
On Friday, January 28th, 2022 at 12:18 AM, James O'Beirne via bitcoin-dev 
 wrote:

>> I don't think implementing a CTV opcode that we expect to largely be 
>> obsoleted by a TXHASH at a later date is yielding good value from a soft 
>> fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it). You're 
> presenting a novel idea that, as far as I know, hasn't had much time to bake 
> in public. Like Jeremy, I'm concerned by the combinatorial growth of flags 
> and the implications that has for testing. Caching for something like TXHASH 
> looks to me like a whole different ballgame relative to CTV, which has a 
> single kind of hash.
>
> Even if we were to adopt something like TXHASH, how long is it going to take 
> to develop, test, and release? My guess is "a while" - in the meantime, users 
> of Bitcoin are without a vault strategy that doesn't require either 
> presigning transactions with ephemeral keys (operationally difficult) or 
> multisig configurations that would make Rube Goldberg blush (operationally 
> difficult and precarious). The utility of vaulting seems underappreciated 
> among consensus devs and it's something I'd like to write about soon in a 
> separate post.
>
>> The strongest argument I can make in favour of CTV would be something like: 
>> "We definitely want bare CTV and if we are going to add CTV to legacy script 
>> (since we cannot use TXHASH in legacy script), then it is actually easier 
>> not to exclude it from tapscript, even if we plan to add TXHASH to tapscript 
>> as well."
>
> Another argument for CTV (which I find especially persuasive) is its 
> simplicity - it's 

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[James O'Beirne via bitcoin-dev]

> I don't think implementing a CTV opcode that we expect to largely be
obsoleted by a TXHASH at a later date is yielding good value from a soft
fork process.

This presumes the eventual adoption of TXHASH (or something like it).
You're presenting a novel idea that, as far as I know, hasn't had much time
to bake in public. Like Jeremy, I'm concerned by the combinatorial growth
of flags and the implications that has for testing. Caching for something
like TXHASH looks to me like a whole different ballgame relative to CTV,
which has a single kind of hash.

Even if we were to adopt something like TXHASH, how long is it going to
take to develop, test, and release? My guess is "a while" - in the
meantime, users of Bitcoin are without a vault strategy that doesn't
require either presigning transactions with ephemeral keys (operationally
difficult) or multisig configurations that would make Rube Goldberg blush
(operationally difficult and precarious). The utility of vaulting seems
underappreciated among consensus devs and it's something I'd like to write
about soon in a separate post.

> The strongest argument I can make in favour of CTV would be something
like: "We definitely want bare CTV and if we are going to add CTV to legacy
script (since we cannot use TXHASH in legacy script), then it is actually
easier not to exclude it from tapscript, even if we plan to add TXHASH to
tapscript as well."

Another argument for CTV (which I find especially persuasive) is its
simplicity - it's relatively easy to reason about and, at this point,
pretty well understood. It seems like a low-risk change relative to some of
the other covenant proposals, nearly all of which elicit a good deal of
headscratching (at least from me) and seem to require not only larger
on-chain footprints but sizable code changes.

> I am sensitive to technical debt and soft fork processes

If OP_CTV ends up being the most practical approach for vaulting - among
other things - in terms of weight (which it seems to be at the moment) I
don't think "technical debt" is an applicable term.

On Thu, Jan 27, 2022 at 5:20 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I am sensitive to technical debt and soft fork processes, and I don't
> believe I'm unordinary particular about these issues.  Once implemented,
> opcodes must be supported and maintained indefinitely.  Some opcodes are
> easier to maintain than others.  These particular opcodes involve caching
> of hash computations and, for that reason, I would judge them to be of
> moderate complexity.
>
> But more importantly, soft-forks are inherently a risky process, so we
> should be getting as much value out of them as we reasonably can. I don't
> think implementing a CTV opcode that we expect to largely be obsoleted by a
> TXHASH at a later date is yielding good value from a soft fork process.
>
> The strongest argument I can make in favour of CTV would be something
> like: "We definitely want bare CTV and if we are going to add CTV to legacy
> script (since we cannot use TXHASH in legacy script), then it is actually
> easier not to exclude it from tapscript, even if we plan to add TXHASH to
> tapscript as well."
>
> But that argument basically rests the entire value of CTV on the shoulders
> of bare CTV.  As I understand, the argument for why we want bare CTV,
> instead of just letting people use tapscript, involves the finer details of
> weight calculations, and I haven't really reviewed that aspect yet.  I
> think it would need to be pretty compelling to make it worthwhile to add
> CTV for that one use case.
>
>
> Regarding "OP_TXHASH+CSFSV doesn't seem to be the 'full' set of things
> needed", I totally agree we will want more things such as CAT, rolling
> SHA256 opcodes, wider arithmetic, pushing amounts onto the stack, some kind
> of tapleaf manipulation and/or TWEAKVERIFY.  For now, I only want to argue
> TXHASH+CSFSV is better than CTV+APO because it gives us more value, namely
> oracle signature verification.  In particular, I want to argue that
> TXHASH's push semantics is better that CTV's verify semantics because it
> composes better by not needing to carry an extra 32-bytes (per instance) in
> the witness data.  I expect that in a world of full recursive covenants,
> TXHASH would still be useful as a fast and cheap way to verify the
> "payload" of these covenants, i.e. that a transaction is paying a certain,
> possibly large, set of addresses certain specific amounts of money.  And
> even if not, TXHASH+CSFSV would still be the way that eltoo would be
> implemented under this proposal.
>
> On Wed, Jan 26, 2022 at 5:16 PM Jeremy  wrote:
>
>> 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 

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Anthony Towns via bitcoin-dev]

On Wed, Jan 26, 2022 at 12:20:10PM -0500, Russell O'Connor via bitcoin-dev 
wrote:
> Recapping the relationship between CTV and ANYPREVOUT::

> 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.

Even if they weren't eltoo channels, they could be updated lightning penalty
channels signed with APO signatures so that the txid wasn't crucial. So
I don't think this would require all the work to update to eltoo just to
have this feature, if APO were available without CTV per se.

> An Alternative Proposal::
>  ...

> For similar reasons, TXHASH is not amenable to extending the set of txflags
> at a later date.

> 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 [...]

I don't think that's really feasible -- eg, what you propose don't cover
SIGHASH_GROUP: 

 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html

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

I think baking this in from day 0 might be better: make TXHASH be
a multibyte opcode, so that when you decode "0xBB" on the stack,
you also decode a serialize.h:VarInt as the version number. Version 0
(0xBB00) gives hashes corresponding to bip342, version 1 (0xBB01) gives
hashes corresponding to bip118 (anyprevout), anything else remains as
OP_SUCCESS behaviour, and you retain a pretty compact encoding even if
we somehow eventually end up needing hundreds or thousands of different
TXHASH versions.

Because the version here is part of the opcode rather than pulled from
the stack, I think this preserves any benefits related to composition
or analysis, but is otherwise still pretty general. I'm imagining that
the idea would be to be consistent between CHECKSIG key versions and
TXHASH versions.

So I think just designing it this way means TXHASH *would* be "amenable
to extending the set of txflags at a later date."

> ' CHECKSIGVERIFY can be simulated by ' 
> TXHASH  CHECKSIGFROMSTACKVERIFY'. 

I don't think that's quite right. BIP 118 anyprevout is done by taking
the pubkey "P", marking it as "APO-capable" (by prefixing it with 0x01),
and then getting a sighash and sig from the witness. Doing the same
with TXHASH/CSFSV would just be replacing " CHECKSIGVERIFY" with
"TXHASH  CSFSV" with the witness providing both the signature and
txhash flag, just as separate elements rather than concatenated. (The
"APO-capable" part is implicit in the "TXHASH" opcode)

> 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!

While I see the appeal of this from a language design perspective;
I'm not sure it's really the goal we want. When I look at bitcoin's
existing script, I see a lot of basic opcodes to do simple arithmetic and
manipulate the stack in various ways, but the opcodes that are actually
useful are more "do everything at once" things like check(multi)sig or
sha256. It seems like what's most useful on the blockchain is a higher
level language, rather than more of blockchain assembly language made
up of small generic pieces. I guess "program their own use cases from
components" seems to be coming pretty close to "write your own crypto
algorithms" here...

I'm not really sure what the dividing line there is, or even which side
TXHASH would be on. I'm not even totally convinced that the "high level
language" should be describing what consensus provides rather than some
layer on top that people compile (a la miniscript). Just trying to put
into words why I'm not 100% comfortable with the principle per se.


One thing I've thought about is an opcode like "POP_SIGDATA" which would
populate a new "register" called "sigdata", which would then be added
to the message being signed. That's a generalisation of tapscript's
behaviour for "codeseparator" essentially. That is,

   x POP_SIGDATA p CHECKSIG

would be roughly the same as

   TXHASH x CAT SHA256SUM p CHECKSIGFROMSTACK

I think "POP_SIGDATA" makes for an interesting counterpart to
"PUSH_ANNEXITEM" -- we implicitly commit to all the annex items in
signatures, so PUSH_ANNEXITEM would give a way to use signed data that's
given verbatim in the witness in further calculations; but POP_SIGDATA

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

I am sensitive to technical debt and soft fork processes, and I don't
believe I'm unordinary particular about these issues.  Once implemented,
opcodes must be supported and maintained indefinitely.  Some opcodes are
easier to maintain than others.  These particular opcodes involve caching
of hash computations and, for that reason, I would judge them to be of
moderate complexity.

But more importantly, soft-forks are inherently a risky process, so we
should be getting as much value out of them as we reasonably can. I don't
think implementing a CTV opcode that we expect to largely be obsoleted by a
TXHASH at a later date is yielding good value from a soft fork process.

The strongest argument I can make in favour of CTV would be something like:
"We definitely want bare CTV and if we are going to add CTV to legacy
script (since we cannot use TXHASH in legacy script), then it is actually
easier not to exclude it from tapscript, even if we plan to add TXHASH to
tapscript as well."

But that argument basically rests the entire value of CTV on the shoulders
of bare CTV.  As I understand, the argument for why we want bare CTV,
instead of just letting people use tapscript, involves the finer details of
weight calculations, and I haven't really reviewed that aspect yet.  I
think it would need to be pretty compelling to make it worthwhile to add
CTV for that one use case.


Regarding "OP_TXHASH+CSFSV doesn't seem to be the 'full' set of things
needed", I totally agree we will want more things such as CAT, rolling
SHA256 opcodes, wider arithmetic, pushing amounts onto the stack, some kind
of tapleaf manipulation and/or TWEAKVERIFY.  For now, I only want to argue
TXHASH+CSFSV is better than CTV+APO because it gives us more value, namely
oracle signature verification.  In particular, I want to argue that
TXHASH's push semantics is better that CTV's verify semantics because it
composes better by not needing to carry an extra 32-bytes (per instance) in
the witness data.  I expect that in a world of full recursive covenants,
TXHASH would still be useful as a fast and cheap way to verify the
"payload" of these covenants, i.e. that a transaction is paying a certain,
possibly large, set of addresses certain specific amounts of money.  And
even if not, TXHASH+CSFSV would still be the way that eltoo would be
implemented under this proposal.

On Wed, Jan 26, 2022 at 5:16 PM Jeremy  wrote:

> 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
>  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
> 

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[James Lu via bitcoin-dev]

What if OP_TXHASH is a no op except for the purpose of emulating CTV and
APO?

On Wed, Jan 26, 2022 at 5:16 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>  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 

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Jeremy via bitcoin-dev]

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
 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 

[bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

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 ' TXHASH EQUALVERIFY'.  The reverse is also
true where ' TXHASH' can be simulated by CTV by
' 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.

' CHECKSIGVERIFY can be simulated by '
TXHASH  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