The Ark case for CTV

In discussing the complexities of handling transactions within a network, two primary concerns are identified: the risk of Denial-of-Service (DoS) attacks that compromise the integrity of transaction rounds for all participants, and the issue of liquidity lockup that directly impacts the server. The liquidity lockup problem arises when there is an incoming pending payment with no assurance that the user will reveal the necessary preimage, forcing the server to lock up liquidity until the round expires. It's suggested that one way to mitigate these risks could involve only servicing users who have demonstrated good behavior, possibly through the use of blinded tokens. However, this approach presents a catch-22 situation, especially if the system solely relies on Lightning Network (LN) receive actions as proof of good behavior. Another proposed solution is verifying ownership of other existing unspent transaction outputs (UTXOs), which also faces a similar dilemma.

The discussion further explores the challenge of DoS attacks, where malicious actors can cause transaction rounds to fail. This results in numerous retries, inconveniencing all users involved by requiring them to restart the round. The introduction of CHECKTEMPLATEVERIFY (CTV) offers a partial solution by allowing the server to issue the Hash Time-Locked Contract (HTLC) leaf in a new round. This is contrasted with scenarios lacking CTV support, where the HTLC receiver must join the round anew and may refuse to sign, leading to further round retries without any mechanism for the server to penalize non-compliant users. In comparison, situations that allow for refreshes enable the server to slash the input UTXO of a user who fails to sign, thereby imposing a penalty and discouraging non-cooperation.

Overall, these discussions underscore the intricacies of managing transaction security and liquidity in decentralized networks, highlighting the balance servers must strike between mitigating risks and maintaining user accessibility.