Message-ID: <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com>
Date: Thu, 10 Feb 2022 19:12:16 -0500
MIME-Version: 1.0
Content-Language: en-US
To: James O'Beirne <james.obeirne@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
Precedence: list

This is great in theory, but I think it kinda misses *why* the complexity keeps creeping in. We 
agree on (most of) the goals here, but the problem is the goals explicitly lead to the complexity, 
its not some software engineering failure or imagination failure that leads to the complexity.

On 2/10/22 14:40, James O'Beirne via bitcoin-dev wrote:
-snip-
> # Purely additive feerate bumps should never be impossible
> 
> Any user should always be able to add to the incentive to mine any
> transaction in a purely additive way. The countervailing force here
> ends up being spam prevention (a la min-relay-fee) to prevent someone
> from consuming bandwidth and mempool space with a long series of
> infinitesimal fee-bumps.
> 
> A fee bump, naturally, should be given the same per-byte consideration
> as a normal Bitcoin transaction in terms of relay and block space,
> although it would be nice to come up with a more succinct
> representation. This leads to another design principle:

This is where *all* the complexity comes from. If our goal is to "ensure a bump increases a miner's 
overall revenue" (thus not wasting relay for everyone else), then we precisely *do* need

 > Special consideration for "what should be in the next
 > block" and/or the caching of block templates seems like an imposing
 > dependency

Whether a transaction increases a miner's revenue depends precisely on whether the transaction 
(package) being replaced is in the next block - if it is, you care about the absolute fee of the 
package and its replacement. If it is not in the next block (or, really, not near a block boundary 
or further down in the mempool where you assume other transactions will appear around it over time), 
then you care about the fee *rate*, not the fee difference.

 > # The bandwidth and chain space consumed by a fee-bump should be minimal
 >
 > Instead of prompting a rebroadcast of the original transaction for
 > replacement, which contains a lot of data not new to the network, it
 > makes more sense to broadcast the "diff" which is the additive
 > contribution towards some txn's feerate.

This entirely misses the network cost. Yes, sure, we can send "diffs", but if you send enough diffs 
eventually you send a lot of data. We cannot simply ignore network-wide costs like total relay 
bandwidth (or implementation runtime DoS issues).

> # Special transaction structure should not be required to bump fees
> 
> In an ideal design, special structural foresight would not be needed
> in order for a txn's feerate to be improved after broadcast.
> 
> Anchor outputs specified solely for CPFP, which amount to many bytes of
> wasted chainspace, are a hack. > It's probably uncontroversial at this

This has nothing to do with fee bumping, though, this is only solved with covenants or something in 
that direction, not different relay policy.

> Coming down to earth, the "tabula rasa" thought experiment above has led
> me to favor an approach like the transaction sponsors design that Jeremy
> proposed in a prior discussion back in 2020[1].

How does this not also fail your above criteria of not wasting block space?

Further, this doesn't solve pinning attacks at all. In lightning we want to be able to *replace* 
something in the mempool (or see it confirm soon, but that assumes we know exactly what transaction 
is in "the" mempool). Just being able to sponsor something doesn't help if you don't know what that 
thing is.

Matt