When adding an HTLC to a commitment transaction, care must be taken to ensure that the HTLC value isn't below the dust-limit. If so, then either party may find themselves in an undesirable situation wherein their current commitment transaction isn't relayed nor accepted by nodes on the network due to the policy around dust-limits.

Therefore, the logic around accepting/forwarding/clearing HTLC's needs to be cognizant of these limits in order to maintain the invariant that the current commitment transaction is eligible to be broadcast and included within the next block.

At the Lightning Summit in Milan we agreed on a mechanism to allow sub-dust HTLC's on the network:

• Nodes locally agree on a dust-limit when creating a channel.
• If an incoming/outgoing HTLC is below this dust-limit, then a state transition occurs, but, the HTLC isn't added. Instead when the HTLC is cleared, the value simply goes to miners fees.
• The HTLC is forwarded to the next peer in the route as normal.
• When the HTLC is being settled on the backwards route, the value in that was pushed to miners fees is credited to the settler's balance.

The above scheme gets around the issue by introducing local consensus on what constitutes dust. With this scheme we can safely support HTLC's down to a single satoshi.

The state machine (lnwallet/channel.go) should be modified to internally implement the above logic:

• On state machine initialization, an additional parameter should be added (the local consensus dust-limit)
• When adding a new HTLC to the state machine (.AddHTLC/ReceiveHTLC) a bool should be set if the value is below the current dust-limit.
• When evaluating the HTLC log to create a new commitment state, any HTLC with this bool set to true isn't added to the commitment transaction, but the balance is updated as if it were.