Published on: 2018-12-11T19:58:42+00:00
In a discussion between Trey Del Bonis and ZmnSCPxj, the topic of interoperability between Fulgurite and Burchert-Decker-Wattenhofer (BDW) in the Lightning Network (LN) is explored. It is important to prevent lying on gossip in LN to avoid fake channels that cannot route payments. This is achieved by visibly locking funds on-chain. However, low-capacity channels far from a node can be removed from their routemaps to reduce memory consumption. The idea of peers lying about which channel has the funds moving when routing a payment is also discussed.ZmnSCPxj suggests two solutions for using Fulgurite in LN. In the first solution, users and their peers lock funds in Fulgurite and split them into two subchannels: one for HTLC-only and the other for HTLC and DLC. This system appears as an ordinary channel to others on LN. If someone routes through the user, they prefer the HTLC-only subchannel, but if it lacks capacity, the user can either sign all 1 million DLC sub-contract signatures for every HTLC update or pretend to be out of funds.The second solution involves pretending to create a BDW channel factory with a single HTLC-only subchannel, while the remaining funds are not claimed for use on LN. Similar to the first solution, if someone routes through the user and the HTLC-only subchannel lacks capacity, the same options as before apply. Additionally, BOLT 1.1 allows short channel IDs to indicate the next node in the route, providing an alternative if the announced channel has insufficient capacity.Publishing update_channel messages with balances and fees in each direction, signed by both sides of the channel, is suggested as a useful feature. However, it is noted that current implementations work well without this information and including it would increase bandwidth usage for gossip.In another discussion about the Fulgurite proposal, it is mentioned that implementing Fulgurite in the Burchert-Decker-Wattenhofer channel is straightforward and would still provide scalability benefits. The conversation concludes with a mention of how channel gossip in the Burchert-Decker-Wattenhofer channel will need to work.The validation of channel data only requires consensus validation, which involves checking that both sides of the channel have agreed through signatures. Burchert-Decker-Wattenhofer channel factories require a single announcement for all channels within the factory, signed by all participants. Each channel within the factory then only needs updates signed by the two direct participants. When channels within the factory are reorganized, a new announcement is needed and must be signed by the participants involved in the reorganization. Contracts can be canceled if all participants agree, with the fulfillment of the hashlock in an HTLC considered a cancellation.In an email, it is noted that Decker-Wattenhofer and Decker-Russell-Osuntokun impose an extra CSV on their transported contracts. Most contracts cannot be transported across systems, but this limitation is not currently seen as a major restriction. However, addressing CSV requirements early on is important to avoid potential exploitation as an attack point. The email concludes by emphasizing the significance of code over words.Trey Del Bonis has shared a document outlining Lightning Network extension proposals, with a focus on his concept called "Fulgurite." Fulgurite aims to enhance the flexibility and fault-tolerance of the Lightning Network by introducing channel partitions that incorporate user balances and HTLCs. This allows for discreet log contracts within channels and improves anonymity. While further refinement is needed, a toy implementation of Fulgurite's core parts is available for experimentation.ZmnSCPxj provides additional information about individual Lightning channels. Burchert-Decker-Wattenhofer channel factories are described as multiparty channels with multiple 2-party child channels. The hierarchical structure of BDW reduces the redundancy of having multiple channels between the same participants. Punishment mechanisms are integrated into the update protocol, and the document suggests abstracting the update protocol from its description. The nesting capabilities of update protocols are exemplified in the Burchert-Decker-Wattenhofer approach.
Updated on: 2023-07-31T21:08:51.520709+00:00