[feature]: Make the Anchor Sweep Configurable (after commitment is confirmed)

[ziggie1984]

Currently we have 2 situations where we are going to use the anchor output.

1. When the Commitment is not confirmed and either the sweeper uses the anchor to bump our commitment tx, or we use the bumpclosefee rpc which lets us bump the fee of a unconfirmed commitment transaction manually. This feature request does not touch these two scenarios

2. When the Commitment Tx is confirmed our anchor_resolver will try to sweep our anchor with the relayfee (253 sats/kweight). This is what this feature requests targets. Sweeping the Anchor only is economical only up to ~1.8 sat/vbyte (when sweeping before 16blocks). I propose to make this sweeping of anchors configurable. Allowing noderunners to switch off the anchor sweep either by just disabling this behaviour or maybe implement a check which evaluates whether the fee-estimation for maybe 144 blocks would give us a higher feerate than maybe 1.5 sat/vbyte and then not sweeping the anchor programmatically.
   Problem with this sweeping is, that it blocks useable outputs for the user. In bitcoin transactions can only be replaced so they would have to either replace this transaction (RBF) which makes it immediately not economical (size for p2tr output is around 194 byte), using CPFP to use the bigger output which was used to sweep this anchor makes it also not worth it, as soon as the effective feerate goes beyond 1,8 sat/vbyte. So allowing the user to switch off automatic sweeping makes totally sense in crowded mempool conditions.

I would like to tackle this issue if there is consensus that it is worth going in this direction :)

[ziggie1984]

I had another thought where the anchor sweep could be improved:

When more than one anchor is swept it would actually make sense to pay more for fees to get maybe a small return rather than none. (make sure the input is not negative yielding). In case of an SCB a lot of anchors are batched and swept for a feerate of 1sat/vbyte, this leads to a situation where all anchors will be swept by a third party when the timeout runs out.

Example: https://mempool.space/tx/91a1bea0d92a5d6793e5d384646ca9c833542d5828ed4cb69ca5baf8f6b377aa

This is a sweep by the node with 60 anchors. Lnd will aggregate them with a feerate of 1sat/vbyte which is bad in full mempool conditions. So one could think of also improving this logic, so the user gets at least some of his sats paying more.

It got replaced by: https://mempool.space/tx/482091ef9edeba13a19228d25bc8a7173bc75037aa68e55e1d2b64a29a324346

[ellemouton]

Definitely a concept ACK from me for improving the anchor sweep code to be more economical (and more lazy even - ie, only sweep way later on once I have a couple of UTXOs lying around). However, i'm not too sure about disabling it completely - I guess I just dont love the idea of "I don't need to clean it up because i'm sure someone else will" but maybe that is just me?

[Roasbeef]

IMO we should try to first fix the root issue here: that somehow the sweeper isn't getting the conflicting spend notifications it needs. We can ofc make this configurable, but this would just mask the issue.

So allowing the user to switch off automatic sweeping makes totally sense in crowded mempool conditions

IIUC, this should already be caught by our "negative yield" logic, where we make sure not to spend more on an output than its actual value.

[ziggie1984]

IMO we should try to first fix the root issue here: that somehow the sweeper isn't getting the conflicting spend notifications it needs. We can ofc make this configurable, but this would just mask the issue.

Hmm not sure if we are talking about the same thing here? I know we have an issue backpropagating information when an anchor is swept by a third party. What I meant here is we could increase the sweeping feerate of those anchors. But that's only one suggestions of mine. The other is to just let it be configurable maybe? As described above it's really hard to CPFP/RBF economically.

IIUC, this should already be caught by our "negative yield" logic, where we make sure not to spend more on an output than its actual value.

I think this can be improved because it has some small weaknesses. Lets say we have 60 anchors in the pipeline to sweep.

Let's say we wanna sweep for 3Sat/Vbyte which is a sure bet mostly in current mempool conditions.

1. We have the BaseSize +Output: 8 + 43 +1 (P2TR) = 52 bytes * 3 => 156 sats
   Every Anchor account for 2.6 sats for the "basesize".

2. The anchor has a Size of (when sweeping with own Sig): 41(inputsize) + 116/4 (29) = 70 vbytes * 3 = 210 sats

3. Every Anchor has now a yield when sweeping for 3 sat/vbyte of ~ 117sats => leading to nice 7020 sats yield

Can we also sweep 5 Anchors at 3 sat/vbyte: now every Anchor has to account for almost 52 sats for the base Size so we cannot sweep at this rate because our output would be below dust limit or barely above for some output types: 5*68 = 340 sats.

Let's say we sweep 200 channels (SCBing our node so all Channels get closed at once) at 3 sat/vbyte => now profit is almost 200*117 = 23400 sats yield.

But lnd currently would not sweep 200 anchors at a feerate of 3sat/byte because the logic only adds one input at a time. So sweeping 330 sats at 3 sat/vbyte would fail because its negative yielding at first.

[ziggie1984]

Thank you for your thoughts @ellemouton :)

Definitely a concept ACK from me for improving the anchor sweep code to be more economical (and more lazy even - ie, only sweep way later on once I have a couple of UTXOs lying around). However, i'm not too sure about disabling it completely - I guess I just dont love the idea of "I don't need to clean it up because i'm sure someone else will" but maybe that is just me?

Hmm Problem with waiting is, that 16 blocks csv are pretty short timeframe. Lets say we are not SCBing, meaning that maybe at most we can anticipate 2 FC at once maybe? Then we have 2 anchors to sweep which (with our current sweeper logic) would only sweep them for 1 sat/vbyte. But it could be very well swept for (70bytes *2+ 52 = 192 Size of the Tx with 2 anchor Inputs and 1 P2TR output ). Generating an Output above Dustlimit ~310 sats we could sweep this output for almost (2*330 - 310(Dustlimit) )/192vbyte = 1.8 sat/vbyte.

So the above example just illustrates that just increasing the "lazy period" will give us not much of a benefit with the current sweeper logic, which adds each input one at a time and evaluates the yield. Maybe in my opinion 2 approaches could be considered. Config setting which allows noderunners get rid of these annoying AnchorSweeps (0 conf outputs) in their wallet or improving the sweeper logic and aiming for higher fee rates, though calculating with at most 2 FCs in a medium time period this new logic would at most increase the sweep feerate up to 1.8 sat/vbyte so not sure whether it's worth it (there might also be the possibility to use this anchor to consolidate wallet utxos leading to another use case, because more Inputs increase the yielding of those anchors hence increase the fee rate).
I tend to just allow users to switch off the anchor sweep setting, which would be a simple solution.