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

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.

2 Answers 2


The main answer is that we don't really have a fully spec'd Eltoo design for Anyprevout (or CTV+CSFS), and that's something that requires more thorough investigation to make the correct primitives for Eltoo, including things like SIGHASH_BUNDLE.

The main issue that arises with (any) eltoo proposal is that you have to pay fees, somehow, and there is a Dust limit.

With APO Eltoo there is an issue that because the different sighash modes let you only sign one or all of the outputs, it's difficult to add fees to the transactions in it if they have >1 output. Thus (how I've seen eltoo described, I could be off) is such that one root transaction with 1 output drives state forward where outputs can be dynamically added, and the second layer of transaction expands to HTLCs but is not time sensitive to resolve, but I'm not sure how it's proposed fees are added to that. One option is to allow adding inputs (but not outputs) and you have to craft perfectly sized fee paying outputs, another option is CPFP on each HTLC. This is an option at this phase since every party should have some output (remember, eltoo is N party). This doesn't work at the state update level of eltoo since we don't want to have to create N outputs for CPFP-ing.

In CTV world you can have the option of adding an input, but you can't dynamically add change. So if you have N parties, you might sign N transactions to allow up to N parties to add an (perfectly sized) input to add fees. These input slots can accomodate any UTXO (without a relative timelock set). The state updates can also have a CPFP anchor output, that could be anyone can spend, it could also have a CTV congestion control tree of anchor outputs to allow any party to pay fee with only log4(N) cost to get a single CPFP hook, and constant overhead to get N hooks out.

One of the benefits of a CPFP approach over a RBF with new inputs approach is that it is slightly simpler to deal with various types of pinning attack when your transactions can't be dynamically changed by a third party.

Alternatively, my Transaction Sponsors proposal would benefit both APO and CTV based fee paying by moving the payment of fees to out of band.

Overall, short of a fee paying solution, the protocols are pretty much the same.

Lastly, as the question asker has insinuated on other platforms, he wishes to oppose CTV unless we prove that CTV+CSFS works for Eltoo, I'd advise against that. The point is that the main state update mechanisms described by Eltoo as implementable via APO can be achieved with CTV + another possible proposal (CSFS) that is a little simpler than APO, but does not currently have a BIP. In either case, the main thing that should happen is more research into Eltoo to fully prove out the requirements for the system and then we can adopt the set of upgrades required to give us the best version of that. I suspect that means something like transaction sponsors or sighash bundles, but it's not my prime area of research. CTV has enough 'other stuff' going on that witholding it's release pending ongoing research on the lightning network seems like an unforced error.

  • "Lastly, as the question asker has insinuated on other platforms, he wishes to oppose CTV unless we prove that CTV+CSFS works for Eltoo, I'd advise against that. " Nope, merely to hammer out details before attempting activation. Answering questions before activation rather than afterwards. Does CTV work for eltoo is only one of those questions. If the answer is no I'd focus more on the other use cases of CTV. Dec 29, 2021 at 18:21
  • 1
    I wish to support CTV if it is optimal for a single or multiple use cases that the community is demanding. I wish to oppose CTV if it is not optimal for any of the use cases the community is demanding. Today I haven't worked out whether it is optimal or isn't for these use cases hence the question. Dec 29, 2021 at 18:29

To add to Jeremy's answer I'll summarize some thoughts from Christian Decker (co-author of BIP 118 for ANYPREVOUT) on the bitcoin-dev mailing list.

As Jeremy points out SIGHASH_ANYPREVOUT (APO) has been refined and optimized for the eltoo channel construction use case to a much greater extent than OP_CHECKTEMPLATEVERIFY (CTV). There is still a lot more work to do to build out and test the eltoo construction using ANYPREVOUT but none of this work has been done using the CTV and CHECKSIGFROMSTACK construction at the time of writing (January 2022).

While it may be possible to emulate APO using CTV, APO does not have any overhead in the transaction size which is not the case for CTV. Hence eltoo transactions using APO are more efficient in terms of vbytes.

In addition (and arguably least importantly) it has been highlighted on a number of occasions that CTV only represents ~200 lines of code change. APO is even simpler in terms of lines of code than this. The original SIGHASH_NOINPUT (since updated for Taproot and renamed to SIGHASH_ANYPREVOUT) contained as little as 3-5 lines of code in Bitcoin Core.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.