SIGHASH_ANYPREVOUT has been designed as I understand primarily for the eltoo channel construction use case although it has many other potential use cases too.

BIP 119 states:

Were both OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACKVERIFY to be added to Bitcoin, it would be possible to implement a variant of Eltoo's floating transactions using the following script:

witness(S+n): <sig> <H(tx with nLockTime S+n paying to program(S+n))>
    program(S): OP_CHECKTEMPLATEVERIFY <musig_key(pk_update_a, pk_update_b)> OP_CHECKSIGFROMSTACKVERIFY <S+1> OP_CHECKLOCKTIMEVERIFY

How do these two eltoo channel constructions compare e.g. upsides and downsides? I'm assuming they aren't equivalent. The BIP states:

Compared to SIGHASH_ANYPREVOUTANYSCRIPT, because OP_CHECKTEMPLATEVERIFY does not allow something similar to SIGHASH_ANYONECANPAY or SIGHASH_SINGLE, protocol implementers might elect to sign multiple versions of transactions with CPFP Anchor Outputs or Inputs for paying fees or an alternative such as transaction sponsors might be considered.

SIGHASH_ANYPREVOUT has been designed as I understand primarily for the eltoo channel construction use case although it has many other potential use cases too.

BIP 119 states:

Were both OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACKVERIFY to be added to Bitcoin, it would be possible to implement a variant of Eltoo's floating transactions using the following script:

witness(S+n): <sig> <H(tx with nLockTime S+n paying to program(S+n))>
    program(S): OP_CHECKTEMPLATEVERIFY <musig_key(pk_update_a, pk_update_b)> OP_CHECKSIGFROMSTACKVERIFY <S+1> OP_CHECKLOCKTIMEVERIFY

How do these two eltoo channel constructions compare e.g. upsides and downsides? They clearly aren't equivalent. The BIP states:

Compared to SIGHASH_ANYPREVOUTANYSCRIPT, because OP_CHECKTEMPLATEVERIFY does not allow something similar to SIGHASH_ANYONECANPAY or SIGHASH_SINGLE, protocol implementers might elect to sign multiple versions of transactions with CPFP Anchor Outputs or Inputs for paying fees or an alternative such as transaction sponsors might be considered.

SIGHASH_ANYPREVOUT has been designed as I understand primarily for the eltoo channel construction use case although it has many other potential use cases too.

It was stated on Twitter that the proposed opcode CHECKTEMPLATEVERIFY can also support eltoo channel constructions. Is this the case?

The second part of that tweet ("APO isn’t enough on its own for Eltoo") I think is just false unless they are referring to ANYPREVOUTANYSCRIPT.

Jeremy Rubin stated on IRC that CTV commits to all scriptsigs and sequences whereas ANYPREVOUT does not.

He also stated that CTV and CHECKSIGFROMSTACK can emulate ANYPREVOUT but I haven't found further details other than what it is in the BIP.

BIP 119 states:

Were both OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACKVERIFY to be added to Bitcoin, it would be possible to implement a variant of Eltoo's floating transactions using the following script:

witness(S+n): <sig> <H(tx with nLockTime S+n paying to program(S+n))>
    program(S): OP_CHECKTEMPLATEVERIFY <musig_key(pk_update_a, pk_update_b)> OP_CHECKSIGFROMSTACKVERIFY <S+1> OP_CHECKLOCKTIMEVERIFY

SIGHASH_ANYPREVOUT has been designed as I understand primarily for the eltoo channel construction use case although it has many other potential use cases too.

BIP 119 states:

Were both OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACKVERIFY to be added to Bitcoin, it would be possible to implement a variant of Eltoo's floating transactions using the following script:

witness(S+n): <sig> <H(tx with nLockTime S+n paying to program(S+n))>
    program(S): OP_CHECKTEMPLATEVERIFY <musig_key(pk_update_a, pk_update_b)> OP_CHECKSIGFROMSTACKVERIFY <S+1> OP_CHECKLOCKTIMEVERIFY

How do these two eltoo channel constructions compare e.g. upsides and downsides? I'm assuming they aren't equivalent. The BIP states:

Compared to SIGHASH_ANYPREVOUTANYSCRIPT, because OP_CHECKTEMPLATEVERIFY does not allow something similar to SIGHASH_ANYONECANPAY or SIGHASH_SINGLE, protocol implementers might elect to sign multiple versions of transactions with CPFP Anchor Outputs or Inputs for paying fees or an alternative such as transaction sponsors might be considered.

SIGHASH_ANYPREVOUT has been designed as I understand primarily for the eltoo channel construction use case although it has many other potential use cases too.

It was stated on Twitter that the proposed opcode CHECKTEMPLATEVERIFY can also support eltoo channel constructions. Is this the case?

The second part of that tweet ("APO isn’t enough on its own for Eltoo") I think is just false unless they are referring to ANYPREVOUTANYSCRIPT.

Jeremy Rubin stated on IRC that CTV commits to all scriptsigs and sequences whereas ANYPREVOUT does not.

He also stated that CTV and CHECKSIGFROMSTACK can emulate ANYPREVOUT but I haven't found further details.

SIGHASH_ANYPREVOUT has been designed as I understand primarily for the eltoo channel construction use case although it has many other potential use cases too.

It was stated on Twitter that the proposed opcode CHECKTEMPLATEVERIFY can also support eltoo channel constructions. Is this the case?

The second part of that tweet ("APO isn’t enough on its own for Eltoo") I think is just false unless they are referring to ANYPREVOUTANYSCRIPT.

Jeremy Rubin stated on IRC that CTV commits to all scriptsigs and sequences whereas ANYPREVOUT does not.

He also stated that CTV and CHECKSIGFROMSTACK can emulate ANYPREVOUT but I haven't found further details other than what it is in the BIP.

BIP 119 states:

Were both OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACKVERIFY to be added to Bitcoin, it would be possible to implement a variant of Eltoo's floating transactions using the following script:

witness(S+n): <sig> <H(tx with nLockTime S+n paying to program(S+n))>
    program(S): OP_CHECKTEMPLATEVERIFY <musig_key(pk_update_a, pk_update_b)> OP_CHECKSIGFROMSTACKVERIFY <S+1> OP_CHECKLOCKTIMEVERIFY