Author: Johan Torås Halseth 2018-10-16 19:25:59
Published on: 2018-10-16T19:25:59+00:00
The discussion is about simplifying the funding of Lightning Network channels. The proposal suggests splicing in one on-chain transaction to allow for future iterations, rather than using multiple funding outputs which adds more complexity. ZmnSCPxj suggests pre-seating inputs to generate addresses that can be spliced directly into the channel. This can be done by each channel having two public-key-derivation paths to create on-chain addresses, with the client detecting incoming funds and initiating a splice-in automatically from the UTXO paying to the address into the channel. This can be implemented without requiring a BOLT change. However, there are safety concerns without trust in the other peer, as the other party can refuse to create the new commit transaction. One solution proposed was to use Taproot addresses, which by default is just a 2-of-2, but in an uncooperative case it can reveal the script it commits to, which is a timelocked refund requiring a single-sig. However, this means that the entirety of the funds may have to be claimed by one endpoint, and third-party funds cannot be split in case of an uncollaborative refund.
Updated on: 2023-05-25T14:25:46.163545+00:00