Published on: 2019-06-05T14:05:17+00:00
In this email thread, Cezary Dziemian expresses frustration with the implementation of a project he had been working on for over a year. He initially built a prototype based on c-lightning but switched to LND due to issues with c-lightning. However, he faced problems with LND as well, as there were missing API methods. Cezary suggests building a cross-implementation group to work together and mentions that his friend is willing to fund the development of the project, preferably in Java.Another part of the discussion revolves around charging for liquidity on Lightning channels. ZmnSCPxj proposes establishing a channel with a fixed rate of payment per hour, but there are concerns that a second node could game the system by making payments through the channel to capture the fees. To address this, higher transmission fees are suggested to make the attack infeasible. An alternative mechanism to CLTV-encumberance is proposed, which may be superior.The discussion also focuses on advertising and receiving offers for dual funding. Skewed channels are required for large vendors like Amazon, and open channels with Amazon can benefit liquidity providers. An attack scenario is discussed where a node operator advertises liquidity but does not deliver it after receiving payment. Possible solutions include modifying channel commitment transactions and encumbering only the liquidity provider.A proposal is made to allow nodes to advertise initial liquidity matching through their node_announcement. This would create a market of inbound capacity that any node can take advantage of, reducing the need for out-of-band negotiation. New feature flags are added to the node_announcement, including data such as fee rates for liquidity and base fees for providing liquidity. If a node cannot provide the requested liquidity, it must return an error. The proposal credits Casey Rodamor for the initial idea.In the discussion about charging for liquidity, Jim Posen suggests a model based on the amount multiplied by time. Another proposal suggests establishing a channel with specific payment terms for a certain period. However, there are concerns about potential gaming of the system by a second node. To mitigate this, higher transmission fees are suggested. The idea is still in its early stages and may require protocol modifications.The debate on whether a node should be able to request more liquidity than they put into a channel is discussed. There are concerns that allowing arbitrary capacity requests could lead to malicious attacks where funds are locked up in unusable channels. Suggestions include requiring nodes to have a minimum amount of capacity tied into the channel. Advertised liquidity creates a market of inbound capacity, reducing the need for out-of-band negotiation.In the context of node announcements, it is mentioned that most implementations currently ignore announcements from nodes without any channels. This behavior would need to be changed globally for node announcements to propagate effectively. The usefulness of incoming capacity from a random node without other channels is questioned.The proposal to allow nodes to advertise liquidity matching is seen as a solution to the problem of sourcing inbound capacity. It would create a market of inbound capacity, reducing the need for out-of-band negotiation. The proposal depends on dual funding being possible and credits Casey Rodamor for the initial idea.The challenges of offering liquidity and potential solutions are discussed. Charging based on the amount of liquidity provided multiplied by time is suggested, but enforcing it at the protocol layer is difficult. Pre-paying on fees and locking up fees in a channel reserve are also proposed. Aligning incentives better is seen as crucial, and paying upfront for routing fees and reimbursing as needed is one idea.Overall, the discussions revolve around finding fair and secure ways to charge for liquidity on Lightning channels, allowing nodes to advertise liquidity matching, addressing attack scenarios, and reducing the need for out-of-band negotiation to obtain inbound capacity.
Updated on: 2023-07-31T20:39:18.354928+00:00