使用 ANYPREVOUT 的 eltoo 頻道建設與使用 CTV 和 CSFS 的相比如何？
據我了解，SIGHASH_ANYPREVOUT 主要用於 eltoo 通道建構案例，儘管它也有許多其他潛在案例。
BIP 119規定：
如果將 OP_CHECKTEMPLATEVERIFY 和 OP_CHECKSIGFROMSTACKVERIFY 都添加到比特幣中，則可以使用以下腳本實現 Eltoo 浮動交易的變體：
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這兩種 eltoo 通道結構如何比較優勢和劣勢？它們顯然不是等價的。BIP 規定：
與 SIGHASH_ANYPREVOUTANYSCRIPT 相比，由於 OP_CHECKTEMPLATEVERIFY 不允許類似於 SIGHASH_ANYONECANPAY 或 SIGHASH_SINGLE 的東西，協議實現者可能會選擇使用 CPFP 錨輸出或輸入簽署多個版本的交易以支付費用，或者可以考慮使用諸如交易發起人之類的替代方案。
主要的答案是我們並沒有真正為 Anyprevout（或 CTV+CSFS）提供完全規範的 Eltoo 設計，這需要更徹底的調查才能為 Eltoo 製作正確的原語，包括 SIGHASH_BUNDLE 之類的東西。
（任何）eltoo 提案出現的主要問題是您必須以某種方式支付費用，並且有灰塵限制。
使用 APO Eltoo 存在一個問題，因為不同的 sighash 模式只允許您簽署一個或所有輸出，如果它們的輸出 >1，則很難向其中的交易添加費用。因此（我看到 eltoo 的描述，我可能會離開）是這樣的，一個具有 1 個輸出的根事務驅動狀態向前，輸出可以動態添加，第二層事務擴展到 HTLC，但對解決時間不敏感，但我不確定它是如何添加建議的費用的。一種選擇是允許添加輸入（但不是輸出），並且您必須製作完美尺寸的付費輸出，另一種選擇是每個 HTLC 上的 CPFP。這是此階段的一個選項，因為每一方都應該有一些輸出（記住，eltoo 是 N 方）。這在 eltoo 的狀態更新級別不起作用，因為我們沒有
在 CTV 世界中，您可以選擇添加輸入，但不能動態添加更改。因此，如果您有 N 方，您可能會簽署 N 筆交易以允許多達 N 方添加（完美大小的）輸入以增加費用。這些輸入槽可以容納任何 UTXO（沒有相對時間鎖集）。狀態更新還可以有一個 CPFP 錨輸出，任何人都可以使用，它還可以有一個錨輸出的 CTV 擁塞控制樹，以允許任何一方支付費用，只需 log4(N) 成本即可獲得單個 CPFP 掛鉤，以及不斷的成本來獲得 N 個掛鉤。
CPFP 方法相對於具有新輸入方法的 RBF 的好處之一是，當您的交易不能被第三方動態更改時，處理各種類型的 pinning 攻擊會稍微簡單一些。
或者，我的交易發起人提案將通過將費用支付轉移到帶外，從而使 APO 和基於 CTV 的費用支付受益。
總體而言，缺少付費解決方案，協議幾乎相同。
最後，正如提問者在其他平台上暗示的那樣，除非我們證明 CTV+CSFS 對 Eltoo 有效，否則他希望反對 CTV，我建議不要這樣做。關鍵是 Eltoo 描述的可通過 APO 實現的主要狀態更新機制可以通過 CTV + 另一個可能的提案 (CSFS) 來實現，該提案比 APO 簡單一些，但目前沒有 BIP。在任何一種情況下，應該做的主要事情是對 Eltoo 進行更多研究，以充分證明系統的要求，然後我們可以採用所需的升級集，為我們提供最好的版本。我懷疑這意味著諸如交易贊助商或 sighash 捆綁包之類的東西，但這不是我的主要研究領域。CTV 有足夠多的“其他東西”在進行，因此在等待對閃電網路的持續研究之前不發布它似乎是一個非受迫性錯誤。
為了補充 Jeremy 的回答，我將在比特幣開發郵件列表中總結 Christian Decker（ BIP 118 for ANYPREVOUT 的合著者）的一些想法。
正如 Jeremy 指出的那樣，SIGHASH_ANYPREVOUT (APO) 已針對 eltoo 通道建構案例進行了改進和優化，其程度遠高於 OP_CHECKTEMPLATEVERIFY (CTV)。使用 ANYPREVOUT 建構和測試 eltoo 構造還有很多工作要做，但在撰寫本文時（2022 年 1 月），還沒有使用 CTV 和 CHECKSIGFROMSTACK 構造完成這些工作。
雖然可以使用 CTV 模擬 APO，但 APO 在事務大小方面沒有任何成本，而 CTV 則不然。因此，使用 APO 的 eltoo 事務在 vbytes 方面更有效。
此外（並且可以說是最不重要的），CTV 僅代表約 200 行程式碼更改已在許多場合得到強調。就程式碼行而言，APO 甚至比這更簡單。最初的 SIGHASH_NOINPUT（自為 Taproot 更新並重命名為 SIGHASH_ANYPREVOUT）在比特幣核心中僅包含 3-5 行程式碼。