On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier <lloyd.fourn@gmail.com> wrote:


On Tue, 15 Jun 2021 at 02:47, Antoine Riard <antoine.riard@gmail.com> wrote:
> This makes a lot of sense as it matches the semantics of what we are trying
to achieve: allow the owner of an output (whether an individual or group)
to reduce that output's value to pay a higher fee.

Note, I think you're still struggling with some trust issue that anchor upgrade is at least eliminating for LN, namely the pre-agreement among a group of signers about the effective feerate to use at some unknown time point in the future. If you authorize your counterparty for a broadcast at feerate X, how do you prevent a broadcast at feerate Y, where Y is far under X, thus maliciously burning a lot of your fee-bumping reserve ?

Of course, one mitigation is to make a contribution to a common fee-bumping output reserve proportional to what has been contributed as a funding collateral. Thus disincentivizing misuse of the common fee-bumping reserve in a game-theoretical way. But if you take the example of a LN channel, you're now running into another issue. Off-chain balances might fluctuate in a way that most of the time, your fee-bumping reserve contribution is out-of-proportion with your balance amounts to protect ? And as such enduring some significant timevalue bleeding on your fee-bumping reserve.

Single-party managed fee-bumping reserve doesn't seem to suffer from this drawback ?

I claim that what I am suggesting is a single-party managed fee-bumping system that solves all fee-bumping requirements of lightning without needing external utxos and without additional interaction or fee pre-agreement between parties. On the commit tx you have your balance going exclusively towards you which you can unilaterally reduce to increase the fee up to whatever threshold you want. With a HTLC or PTLC you also always have a tx with an output that you can unilaterally drain to bump fee (either the hltc-success or htlc-timeout). Are you saying that there are protocols where this would require pre-arrangement or are you saying that it would require pre-arrangement in lightning for some reason I don't see?

Ok now I see what I am missing: We don't really know who owns certain outputs in lightning until the most-recent-state-enforcement mechanism has done its job. i.e. the outputs are 2-of-2s up until that has been resolved. I was operating on some simplified imaginary lightning. Indeed this makes the proposal far less attractive and does require interaction and pre-agreement. This complexity here makes it worse than just keeping external fee-bumping utxos around (as undesirable as this is). Thanks for helping me figure this out.

LL