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
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 26, 2019 1:50 AM, Jeremy via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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:
> BIP:https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki
> Reference
> Implementation:https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify
>
> 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/17268This 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:
>
> * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html
> *
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html
>
> Thanks to the many developers who have provided feedback on iterations of
> this design.
>
> Best,
>
> Jeremy
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
