Anchor Outputs Tracking Issue
- [x] Add utility to simplify handling of
BumpTransactionEvents for users (#2089) - [x] Remove anchors config flag (#2367)
- [x] Require manual inbound acceptance (#2368)
- [x] Restrict inbound anchors channel open to manual acceptance (https://github.com/lightningdevkit/rust-lightning/pull/2368)
- [x] Use different dust exposure thresholds for channels pre-anchors and post-anchors (https://github.com/lightningdevkit/rust-lightning/pull/2354)
- [x] Improve test coverage for onchain claims
- [x] Improve documentation on
ConfirmationTargetand their intended use within LDK (https://github.com/lightningdevkit/rust-lightning/pull/2415) - [x] Use mempool min fee for outbound feerate updates and lower bound of inbound feerate updates (https://github.com/lightningdevkit/rust-lightning/pull/2415)
- [ ] https://github.com/lightningdevkit/rust-lightning/issues/2320
- [ ] Ensure the level of fee-bumping reserves is correct for the channel exposure and reasonable worst-historical mempool (@ariard)
There is one more item to check:
- Ensure the level of fee-bumping reserves is correct for the channel exposure and reasonable worst-historical mempool (you can assign this one to myself)
From a deployment viewpoint, which ones are required to remove the compilation flag #[cfg(anchors)] ? My thinking we can remove the flag for 0.0.116 or 0.0.117, have one or two LDK users integrate anchors and then activate by default anchor channels when we think it’s stable for all the LDK users in 0.0.118 ? It’s not like anchor outputs support is very robust in other implementations so better to be conservative here, I think.
From a deployment viewpoint, which ones are required to remove the compilation flag #[cfg(anchors)] ?
All of them. Users will still need to opt in manually via: https://github.com/lightningdevkit/rust-lightning/blob/5c89d019050a4b2dd68610d2e59d45acbfee5775/lightning/src/util/config.rs#L172
All of them. Users will still need to opt in manually via:
All good yeah we might let one or two release between the removal of the dedicated compilation flag and turning on by default negotiate_anchors_zero_fee_htlc_tx.
Some review feedback from #2089:
- allow unconfirmed inputs in case of empty fee-bumping reserve: https://github.com/lightningdevkit/rust-lightning/pull/2089#discussion_r1199683560
- clean utxo lock state afer confirmation: https://github.com/lightningdevkit/rust-lightning/pull/2089#discussion_r1198807426
And interactions with dust: https://github.com/lightningdevkit/rust-lightning/pull/2354#discussion_r1248157965
If we can update the state of anchor output after #2089, #2367 and #2368 that is valuable to know what prioritize next to harden anchor outputs support.