Hi Joachim,
Fantastic questions!
I think it makes sense to think about it in terms of today, and then in terms of a long-dated future where wallets have much richer native understandings of these things. This helps preserve the purity of the arguments I'm making with respect to what it would look like today v.s. what it could look like with strong integration.
Today:
1) I would expect that exchanges do this as a CTV txn that is one initial confirmation to a single output, and then that output expands to either all the payments in the batch, or to a histogram of single-layer CTVs based on priority/amount being spent. E.g, either A -> B -> {C,D,E,F,G...} or A->B->{C -> {D,E,F}, G -> {H, I J}, K -> ....}. I would further expect that the entire tree would include fees such that it will get into at least the bottom of the mempool. See
https://utxos.org/analysis/batching_sim/ for more info. If txns land in the mempool, then users learn about it (even with an un-updated wallet) just like the learn of normal unconfirmed transactions. Even this simple two-step transaction can deliver massive batching savings. OpTech has some coverage of this simple commit-now-distribute-later scheme here
https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-new-opcode-for-transaction-output-commitments.
I'd also expect that exchanges in particular already store their outbound transactions in resilient storage (for audit and compliance as well as liability protection), so they would likely be able to make this data available to their customers on inquiry if discarded.
I'm all for redundancy, so exchanges can also e.g. send an email with a backup file if they want to. But that's not necessary for it to work today, you can just watch the mempool like wallets already do.
A slightly patched wallet can treat CTV outs as more confirmed (e.g., like an own-change address) than a normal unconfirmed out.
2) I would expect that exchanges pay a reasonable amount of fees for the transaction so it can expect to at least get to the bottom range of the mempool for children, and top of the mempool for the parent. Your question seems to be more about after this phase.
First I would note that it is truly O(log(N)), but E[O(1)], because it amortizes. That is, to claim out all of the outputs is a total overhead of O(N), not O(N log N). Fees in this model are paid by CPFP. Because CPFP is currently *Child* pays for parent and not *Children* pay for parent, we don't (unfortunately) have rational txn selection for this case. Any wallet can construct this spend path by rebroadcasting (if evicted) the parents and spending the txn. The exchange can also 'bound' themselves to seeing a transaction to completion by including some change address at the leaf node layer (not much overhead depending on radix).
Thus the payer of fees is the person who needs to spend.
3) Not exactly, the middle txns are immutable. but it may be possible to construct a low-fee longchain which can cause transaction pinning. If you do a shallow tree as described in (1), the current lightning carve should help to prevent this.
Future:
1) Most likely the desirable radix for a tree is something like 4 or 5 which minimizes the amount of work on an individual basis (you can compute this by figuring out how deep the tree would be and the per-tx overheads, 4 or 5 pop out as being minimal overhead and the benefit is recursive). Mempool broadcast still should work, but it's possible that for privacy reasons it's preferred to not broadcast through mempool. It's also possible that all payouts are into non-interactive lightning channels with N-of-N taproot at each layer, so you receive a proof through your lightning wallet and can immediately route payments, and when you want to close opportunistically cooperate to reduce chain overhead. You can think of CTV as an anchor for bootstrapping these layer two protocols with an on-chain bisection algorithm to discover online participants to re-negotiate with. A privacy and scalability win!
I further expect business wallets (like exchanges) to be able to credit deposits from CTV trees without requiring full expansion. This is also a privacy win, and can decrease latency of moving large value funds (e.g., exceeding inter exchange channel balances) and crediting funds for trading.
2) I think we'll eventually converge on a non-destructive way of adding fees. RBF is destructive in that you're replacing a TX. CPFP is destructive in that you have a spend a coin to drive progress. Without a new opcode you can emulate this with CTV by at nodes in the tree having a consumable output that serves as a CPFP hook/a RBF hook. You can see some discussion here (animated, so use pres mode)
https://docs.google.com/presentation/d/1XDiZOz52XyJc4LDSbiD9_JAaJobyF5QDGtR3O9qD7yg/edit#slide=id.g7d267915e2_0_44. This adds some extra chain weight, but is possible without further extension. What I think we'll eventually land on is a way of doing a tx that contributes fee to another tx chain as a passive observer to them. While this breaks one abstraction around how dependencies between transactions are processed, it also could help resolve some really difficult challenges we face with application-DoS (pinning and other attacks) in the mempool beyond CTV. I have a napkin design for how this could work, but nothing quite ready to share yet.
3) Hopefully 2 solves pinning :)
Hello everyone,
regarding OP_CTV, I am considering the scaling use case, specifically an exchange (or similar) who wants to batch pay to OP_CTV to many users, and I wonder
1) How do you expect the exchange to communicate the proof of the payment to the user wallets such that they are able to construct the follow up transactions and accept the payment. This is UI question. Do you expect exchanges to provide a certain importable file/blob that the wallet will allow you to entry?
2) Who pays the fees and how for the transaction within the structure that OP_CTVed output is committed to? Say there is a tree structure and I want to get the coin out. Someone needs to send log(N) transactions to the chain in order for me to get access to the final UTXO I am interested in. Who can construct such transaction path and what do they need for it and who pays fees on that (which input)?
3) Depending on 2) above, is it not possible for a malicious entity who is among the many users being paid, but who has very small UTXO there relative to others, to construct this middle transaction and use a very small fee rate in order to DoS other participants. Is it even possible for this attacker to create the middle transaction with RBF disabled?
Thank you,
Joachim
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Bitcoin Developers,
Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY (replaces previous OP_SECURETHEBAG BIP). Primarily:
1) Changed the name to something more fitting and acceptable to the community
2) Changed the opcode specification to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead
3) Permits future soft-fork updates to loosen or remove "constexpr" restrictions
4) More detailed comparison to alternatives in the BIP, and why OP_CHECKTEMPLATEVERIFY should be favored even if a future technique may make it semi-redundant.
Please see:
I believe this addresses all outstanding feedback on the design of this opcode, unless there are any new concerns with these changes.
I'm also planning to host a review workshop in Q1 2020, most likely in San Francisco. Please fill out the form here
https://forms.gle/pkevHNj2pXH9MGee9 if you're interested in participating (even if you can't physically attend).
And as a "but wait, there's more":
1) RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. The new command `sendmanycompacted` shows one way to use OP_CHECKTEMPLATEVERIFY. See:
https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-rpcs. `sendmanycompacted` is still under early design. Standard practices for using OP_CHECKTEMPLATEVERIFY & wallet behaviors may be codified into a separate BIP. This work generalizes even if an alternative strategy is used to achieve the scalability techniques of OP_CHECKTEMPLATEVERIFY.
2) Also under development are improvements to the mempool which will, in conjunction with improvements like package relay, help make it safe to lift some of the mempool's restrictions on longchains specifically for OP_CHECKTEMPLATEVERIFY output trees. See:
https://github.com/bitcoin/bitcoin/pull/17268 This work offers an improvement irrespective of OP_CHECKTEMPLATEVERIFY's fate.
Neither of these are blockers for proceeding with the BIP, as they are ergonomics and usability improvements needed once/if the BIP is activated.
See prior mailing list discussions here:
Thanks to the many developers who have provided feedback on iterations of this design.
Best,
Jeremy