[enhancement]: Premature Taproot-Asset Channel Exhaustion Due to Above-dust lnd Requirement

[dstadulis]

Background

In scenarios where taproot assets are contained within bitcoin lightning channels,
LND has the requirement to push an above-dust amount of satoshis to the remote side of the channel to complete a HTLC payment.

Potential complication with this LND requirement is:
In the scenario a taproot-assets-enabled lightning channel contains a de minimis amount of satoshis, (in situ taproot-assets outputs have limits -- until #721 is fixed) the bitcoin satoshi-balance of the channel will be exhausted after a few (3-5?) payments (assuming a payment in the to_local direction doesn't occur).

Deliverables

A method to ensure that a taproot-assets lightning channel can send and receive HTLCs without being constrained by the LND above-dust requirement.

Proposed Remediation Options

• add an inbound fee discount of the incoming channel w/ a base fee the same as the asset carrier HTLC amt
• ?Alternatives

Necessity

This functionality isn't required to demonstrate tapd payment-channel functionality but will be necessary to meet user-expectations before LL endorses Taproot-assets payment-channel functionality.

[jharveyb]

You can also set up a matching HTLC (with no anchored assets) in the opposite direction to net out the BTC amount transferred.

[Roasbeef]

You can also set up a matching HTLC (with no anchored assets) in the opposite direction to net out the BTC amount transferred.

Yep, this was a very early idea for LN, but we just ended up doing the trimmed dust route instead. The bi-directional HTLC trick does require one side to have some funds to begin with, but the push_amt feature does exist, so that could be utilized. Mechanically, I think we'd want to add a new special rule where we insert that HTLC in the other direction automatically (special evaluation rule).

[GeorgeTsagk]

add an inbound fee discount of the incoming channel w/ a base fee the same as the asset carrier HTLC amt

I don't think this works well. It assumes there's some symmetry in inbound/outbound traffic, and if that was the case (assuming that remote side also uses non-dust htlcs) then a fix would not even be needed as the sats would auto-balance

I think we'd want to add a new special rule where we insert that HTLC in the other direction automatically (special evaluation rule).

given that the channel lifecycle is totally LND's job, then that would have to be exposed via LND API?
IIUC we want a special case where if we want to send just an above dust amount to the other side, the commitment will also add an incoming htlc of the same amt.

I think building this directly into lnd channels is way too involved for what we actually need.

We might be better of with an automation in litd/tapd that simply compensates any received dust? After all, it's in both parties' interest to keep the channel operational

[dstadulis]

Remediation Options

1. A draft implementation on LND has been developed to achieve feature-bit-less HTLC symmetry in the channel state machine. While this design will be the ultimate solution, more comprehensive test coverage is needed to ensure no significant faults could occur. E.g. Bugs in the channel state machine could result in loss of funds even outside the Taproot channel context.

2. A bodge: As an interim solution, induce, on invoice creation, litd to cause the receiver of the tap payment to pay the dust back to the sender.

Notes:
#923 "Soft Cap": 100k sat channels as a default, which would be sufficient for making multiple payments. Users will need to rebalance after a fixed number of HTLCs. The advantages of this approach include no significant code changes and a clean codebase, while the drawbacks include potential UX issues.