On Wed, Jun 11, 2025 at 11:33:35AM -0400, Greg Sanders wrote:
> It clearly can be a liability if the relative utility of CTV is damaged by
> a possible future change, even non-consensus ones, some of which are
> already being deployed with non-zero miner support such as
> https://x.com/PortlandHODL/status/1921350395424563572 . This could have led
> to legitimate usage of CTV being trivially DoS'able. Good news is there are
> practical if not beautiful mitigations to this that don't involve annex
> commitment. See https://github.com/bitcoin/bitcoin/pull/32453 and
> https://github.com/petertodd/bitcoin/pull/10 for some relevant details.

Note that in this example the "mitigation" is simply enforcing what is optimal
for miners: mining annexes only when the annexes are required for the
transaction to be valid.

A miner who had allowed standard annexes who was *not* mining CTV transactions
because of a large uncommitted annex is just unnecessarily losing money. They
could easily take that exact transaction, remove the uncommitted annex, and
earn a bit more money. In much the same way that a miner can always do
themselves unnecessary harm by disabling the clean-stack check, and then
failing to mine perfectly valid transactions that would be more profitable if
the extraneous stack elements were removed (modulo non-segwit cases with
high-fee child transactions of course).

It may be a good idea for CTV to commit to annexes. But this issue isn't a
reason to do so.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aFVwDLBUJBbHKJLX%40petertodd.org.