[bitcoin-dev] A fee-bumping model

[Peter Todd]

On Mon, Nov 29, 2021 at 02:27:23PM +0000, darosior via bitcoin-dev wrote:
> ## 2. Problem statement
> 
> For any delegated vault, ensure the confirmation of a Cancel transaction in a configured number of
> blocks at any point. In so doing, minimize the overpayments and the UTxO set footprint. Overpayments
> increase the burden on the watchtower operator by increasing the required frequency of refills of the
> fee-bumping wallet, which is already the worst user experience. You are likely to manage a number of
> UTxOs with your number of vaults, which comes at a cost for you as well as everyone running a full
> node.
> 
> Note that this assumes miners are economically rationale, are incentivized by *public* fees and that
> you have a way to propagate your fee-bumped transaction to them. We also don't consider the block
> space bounds.
> 
> In the previous paragraph and the following text, "vault" can generally be replaced with "offchain
> contract".

For this section I think it'd help if you re-wrote it mathematically in terms
of probabilities, variance, and costs. It's impossible to ensure confirmation
with 100% probability, so obviously we can start by asking what is the cost of
failing to get a confirmation by the deadline?

Now suppose that cost is X. Note how the lowest _variance_ approach would be to
pay a fee of X immediately: that would get us the highest possible probability
of securing a confirmation prior to the deadline, without paying more than that
confirmation is worth.

Of course, this is silly! So the next step is to trade off some variance -
higher probability of failure - for lower expected cost. A trivial way to do
that could be to just bump the fee linearly between now and that deadline. That
lowers expected cost. But does increase the probability of failure. We can of
course account for this in an expected cost.


One final nuance here is if this whole process is visible in the UI we might
want to take into account user discomfort: if I know the process could fail,
the user will probably be happier if it succeeds quickly, even if the
probability of success in the future is still very high.


FWIW the approach taken by the OpenTimestamps calendars is a trivial linear
increase. While they don't have deadlines in the same sense as your
application, there is a trade-off between cost and confirmation time. So our
strategy is to spend money at a constant rate by simply bumping the fee by the
same amount at every new block. I could improve this by using knowledge of the
mempool. But so far I haven't bothered.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211209/7d38040e/attachment.sig>