Gloria,
This is a brilliant post! Great job systematizing many of the issues. Quite
a lot to chew on & I hope other readers of this list digest the post fully.
Three things come to mind as partial responses:
under:
- **DoS Protection**: Limit two types of DoS attacks on the node's
> mempool:
On Wed, Jan 26, 2022 at 12:20:10PM -0500, Russell O'Connor via bitcoin-dev
wrote:
> Recapping the relationship between CTV and ANYPREVOUT::
> While this is a pretty neat feature,
> something that ANYPREVOUT cannot mimic, the main application for it is
> listed as using congestion control to fund
I am sensitive to technical debt and soft fork processes, and I don't
believe I'm unordinary particular about these issues. Once implemented,
opcodes must be supported and maintained indefinitely. Some opcodes are
easier to maintain than others. These particular opcodes involve caching
of hash
Hi everyone,
This post discusses limitations of current Bitcoin Core RBF policy and
attempts to start a conversation about how we can improve it,
summarizing some ideas that have been discussed. Please reply if you
have any new input on issues to be solved and ideas for improvement!
Just in case
What if OP_TXHASH is a no op except for the purpose of emulating CTV and
APO?
On Wed, Jan 26, 2022 at 5:16 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Russell,
>
> Thanks for this email, it's great to see this approach described.
>
> A few preliminary notes of
Hi,
Lloyd, thanks for this excellent writeup. I must say that indeed using CTV
seems like it would very much lower the complexity of the DLC protocol (and
it seems like APO would also work, thanks Jonas for pointing that out).
Though thinking about it, I can't help wondering if the ideal op code
