Fulgurite: ideas for making a more flexible Lightning Network protocol



Summary:

The discussion is related to the interoperability of Fulgurite and Burchert-Decker-Wattenhofer channel factories in Lightning Network (LN). While a single channel announcement will be done for all channels within Burchert-Decker-Wattenhofer factory, each channel within Fulgurite would then need channel updates only signed off by the two direct participants in the channel. The issue of lying on gossip was raised, which LN cannot support as it could lead to fake channels that do not exist at all, making it impossible to route payments. In the future, nodes may remove low-capacity channels from their local routemaps in an effort to reduce memory consumption. Short channel IDs can be used to indicate the next node in the route, even if there is some private unannounced channel or other channel on the route. In terms of Fulgurite and Burchert-Decker-Wattenhofer interoperability, the solution suggested is to split Fulgurite into two sub-channels, one HTLC-only channel, and the other supporting both HTLC and DLC. If somebody routes through you, you prefer the HTLC-only sub-channel, and if that has insufficient capacity, you either swallow the cost of signing all 1 million DLC sub-contract signatures for every update of the HTLC, or pretend to be out of funds in the specified direction. In the future, when Burchert-Decker-Wattenhofer gets onto BOLT, it should be trivial to compose Fulgurite in Burchert-Decker-Wattenhofer exactly as-is, and still get all the nice scalability benefits.


Updated on: 2023-06-02T15:45:47.332473+00:00