On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier wrote: > > > On Tue, 15 Jun 2021 at 02:47, Antoine Riard > 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