Thank you for your review and feedback.
I'm not sure what best practice is w.r.t. linking to BIPs and implementations given need to rebase and respond to feedback with changes. Appreciate any pointers on how to better solve this. For the time being, I will suggest an edit to point it to the PR, although I recognize this is not ideal. I understand your preference for a commit hash and can do one
One note that is unfortunate in your review is that there is a discrepancy between the BIP and the implementation (the original reference or the current PR either) in that caching and DoS is not addressed. This was an explicit design goal of CTV and for it not to be mentioned in the BIP (and just the reference) is an oversight on my part to not aid reviewers more explicitly. Compounding this, I accepted a third-party PR to make the BIP more clear as to what is required to implement it that does not have caching (functional correctness), that exposes the issue if implemented by the BIP directly and not by the reference implementation. I have explained this in a
review last year to pyskell on the PR that caching is required for non-DoS. I will add a note to the BIP about the importance of caching to avoid DoS as that should make third party implementers aware of the issue.
That said, this is not a mis-considered part of CTV. The reference implementation is specifically designed to not have quadratic hashing and CTV is designed to be friendly to caching to avoid denial of service. It's just a part of the BIP that can be more clear. I will make a PR to more clearly describe how that should happen.
------
use cases
------
One thing that's not clear to me is the amount of work a BIP needs to do within itself to fully describe all applications and use cases. I don't think it's appropriate for most BIPs to do so, but in some cases it is a good idea. However, for CTV the applications actually are relatively fleshed out, just outside the BIP. Further, the availability of generic tooling through Sapio and it's examples has demonstrated how one might build a variety of applications. See
rubin.io/advent21 for numerous worked examples.
## Congestion Controlled Transactions
Generally, the existence of these transactions can be tracked using existing wallets if the transaction is seen in the mempool, it will be marked as "mine" and can even be marked as "trusted". See
https://utxos.org/analysis/taxes/ which covers the legal obligations of senders with respect to payees under congestion control. Generally, a legally identifiable party such as an exchange sending a congestion control payment must retain and serve it to the user to prove that they made payment to the user. Users of said exchanges can either download a list of their transactions at the time of withdrawal or they can wait to see it e.g. in the mempool. This was also discussed at
https://diyhpl.us/wiki/transcripts/ctv-bip-review-workshop/ where you can see notes/videos of what was discussed if the notes are hard to parse.
Lightning specific wallets such as Muun and LND particularly plan to use CTV to batch-open a multitude of channels for users, using both congestion control and non-interactive batching. Channels have to be opened on-chain and if channels are to be the future so will on-chain opening of them. These wallets can be built out to track and receive these opening proofs.
## Wallet VaultsThere exists at least 3 implementations of Vaults using CTV (one by me in C++, one by me in Sapio, another by Bryan Bishop in python), and there exist oracles as you mention for emulating it.
## Payment ChannelsActually taking advantage of them is quite simple and has been discussed and reviewed with a number of independent lightning developers.
You can see here a rudimentary implementation and description of how it can work
https://rubin.io/bitcoin/2021/12/11/advent-14/.
This is composable with any `impl Revokable` channel update specification so generalizes to Lightning.
Of course, making it production grade requires a lot of work, but the concept is sound.
## CoinJoin
CTV trees may mean more transactions, not less, but if feerates are not monotonic and CTV allows you to defer the utilization of chainspace.
CTV CoinJoins also open the opportunity to cooperation through payment pools (which can be opened via a coinjoin), which saves further space.
The opportunity to use embedded non-interactive channels (technically, this is a part of payment pools) also further decreases the urgency of getting a UTXO out.
Lastly, while it is a slight privacy leak, CTV also allows coin-joiners of different fee-priority levels to batch together where previously they would not have incentive to (see
https://utxos.org/analysis/batching_sim/). This does use overall less chainspace total than if it is not incentive compatible to batch together. While this is a slight privacy leak, it is not that large since the batches would otherwise be unable to join together (worse) and priority is still unlinked from the inputs. Further, priority already leaks through the observability of coins being spent anyways.
# Covenant Design Trade-Offs and Risks
The important part is the the covenant -- regardless of its length -- must be entirely known in advance. CTV is a fully enumerated non-recursive validation-only non-dynamic state covenant. This limits the types of issues that can arise.
Useful links: