<p>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.</p>
<p>The main issue that arises with (any) eltoo proposal is that you have to pay fees, somehow, and there is a Dust limit.</p>
<p>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 &gt;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.</p>
<p>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.</p>
<p>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.</p>
<p>Alternatively, my <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html" rel="nofollow noreferrer">Transaction Sponsors</a> proposal would benefit both APO and CTV based fee paying by moving the payment of fees to out of band.</p>
<p>Overall, short of a fee paying solution, the protocols are pretty much the same.</p>
<p>Lastly, as the <a href="https://twitter.com/michaelfolkson/status/1476159239374741506" rel="nofollow noreferrer">question asker has insinuated on other platforms</a>, 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.</p>

CC BY-SA 4.0
2021-12-29T18:21:47.247Z
"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.
Michael Folkson
CC BY-SA 4.0
2021-12-29T18:29:40.283Z
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.
Michael Folkson
CC BY-SA 4.0
2021-12-29T17:53:39.857Z
2021-12-29T17:53:39.857Z
Jeremy Rubin
<p>To add to Jeremy's answer I'll summarize some thoughts from Christian Decker (co-author of <a href="https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki" rel="nofollow noreferrer">BIP 118</a> for ANYPREVOUT) on the bitcoin-dev <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019730.html" rel="nofollow noreferrer">mailing list</a>.</p>
<p>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 <a href="https://yakshaver.org/bitcoin/#eltoo" rel="nofollow noreferrer">more work</a> 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).</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2022-01-24T14:37:22.270Z
2022-01-24T14:48:28.977Z
2022-01-24T14:48:28.977Z
Michael Folkson
<p>SIGHASH_ANYPREVOUT has been designed as I understand primarily for the eltoo channel construction use case although it has <a href="https://anyprevout.xyz/" rel="nofollow noreferrer">many other potential use cases</a> too.</p>
<p>BIP 119 <a href="https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Eltoo_with_OP_CHECKSIGFROMSTACKVERIFY" rel="nofollow noreferrer">states</a>:</p>
<blockquote>
<p>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:</p>
</blockquote>
<pre><code>witness(S+n): &lt;sig&gt; &lt;H(tx with nLockTime S+n paying to program(S+n))&gt;
    program(S): OP_CHECKTEMPLATEVERIFY &lt;musig_key(pk_update_a, pk_update_b)&gt; OP_CHECKSIGFROMSTACKVERIFY &lt;S+1&gt; OP_CHECKLOCKTIMEVERIFY
</code></pre>
<p>How do these two eltoo channel constructions compare e.g. upsides and downsides? They clearly aren't equivalent. The BIP states:</p>
<blockquote>
<p>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.</p>
</blockquote>

<eltoo><bip118-sighash-anyprevout><bip119-checktemplateverify>
How do eltoo channel constructions using ANYPREVOUT compare to those using CTV and CSFS?
Michael Folkson
# How do eltoo channel constructions using ANYPREVOUT compare to those using CTV and CSFS?

(Asked by: username_0 on 2021-12-29)

SIGHASH\_ANYPREVOUT has been designed as I understand primarily for the eltoo channel construction use case although it has [many other potential use cases](https://anyprevout.xyz/) too.

BIP 119 [states](https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Eltoo_with_OP_CHECKSIGFROMSTACKVERIFY):

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

**Tags:** eltoo, bip118-sighash-anyprevout, bip119-checktemplateverify


---

## 2 answers

### Answer by username_1 on 2021-12-29. Score: 3

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](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html) 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](https://twitter.com/username_0/status/1476159239374741506), 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.

> **Comments:**
> **username_0**: "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.  
> **username_0**: 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.  

---

### Answer by username_0 on 2022-01-24. Score: 2

To add to username_1's answer I'll summarize some thoughts from Christian Decker (co-author of [BIP 118](https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki) for ANYPREVOUT) on the bitcoin-dev [mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019730.html).

As username_1 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](https://yakshaver.org/bitcoin/#eltoo) 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.


---

