Published on: 2018-09-12T07:15:48+00:00
In a Lightning-dev discussion, users debated the issue of initiating receiving channels in the Lightning Network. One user argued that there is currently no good way to do so, while another countered that consistently keeping a node online for a few months generally results in incoming capacity. A third user suggested that routing nodes could compete to fund stable channels with new merchants, potentially resolving the issue in the long run.Giovanni and ZmnSCPxj discussed the implementation of both-side funding channels in the Lightning Network. Giovanni expressed excitement about this development, while ZmnSCPxj raised concerns about centralization risks and privacy leaks if not implemented properly. They agreed that automating the negotiation process and widely supporting it would be beneficial. ZmnSCPxj proposed an extension to 'node_announcement' to advertise node support for dual-funding and emphasized the importance of every node supporting incoming dual-funding requests to improve decentralization and privacy.The email conversation focused on the process of a merchant starting to use the Lightning Network by receiving funds. The merchant would need to fund a channel with the desired amount and wait for confirmation. They can then exchange on-chain bitcoins for LN bitcoins, repeating the process until they reach their total capacity or run out of on-chain funds. It was noted that keeping a node consistently online for a few months generally results in receiving incoming capacity. The issue of multiple on-chain transactions could potentially be addressed through transactional cut-through offered by Lightning or submarine swaps, but further research is needed.A proposal to implement both-side funding channels in the Lightning Network was discussed to improve its growth. Concerns were raised regarding privacy, locked funds, and potential attack vectors. To mitigate these concerns, the proposal suggests requiring the initiator of a dual-sided channel to pay a fee based on the requested capacity from the other party. An alternate solution using off-to-onchain swaps was also proposed, allowing funds on a single channel to be moved back on-chain to gain incoming capacity. While the implementation of the former proposal may take time, the latter solution can theoretically be implemented now.The conversation revolved around the weaknesses of using Lightning Network for receiving funds and the potential implementation of dual-funded channels. The current method requires the merchant to possess all funds, involves a longer process with two on-chain transactions, and lacks trustless implementation. Dual-funded channels would require fees and measures to mitigate privacy leakage. Details will be discussed at the lightning-dev summit in November, with implementation potentially taking over a year. An alternate solution of off-to-onchain swaps can be implemented now, but trustworthy services are lacking.The implementation of dual-funded channels in the Lightning Network was discussed, allowing both parties to contribute funds in a single transaction. Concerns were raised about privacy leaks and attacks on funds. Mitigation measures include requiring fees based on requested capacity and the "to_self_delay" parameter. The starting state of the channel would favor the initiatee, and the initiator must put up equal or greater funds to mitigate privacy leakage. These issues will be further discussed at the lightning-dev summit in November, with implementation taking over a year. The author suggests that dual-funded channels may not be necessary given the requirement for initiator funds and the potential for off-to-onchain swaps.Cezary had a conversation with Christian Decker, who informed him about the plan to implement both-side funding channels in the Lightning Network. This implementation would allow for a single, trustless transaction where Cezary could pay 100 sat to a peer in exchange for their funds being added to the channel. Cezary sought clarification on the plan and requested information on the timeline for implementation.
Updated on: 2023-07-31T20:28:17.040306+00:00