Published on: 2021-08-14T02:09:18+00:00
In a recent email conversation, ZmnSCPxj suggests using "initiator" and "acceptor" instead of "funder" and "fundee" in the BOLT's rationale section for dual-funding. Lisa has already created a patch for this change. Rusty adds to the discussion by highlighting the risks for the sender and receiver of an HTLC. The sender faces the risk that the channel never confirms but can close it on-chain, while the receiver faces the risk that the channel never confirms and must not route or resolve the HTLC unless they trust the peer. However, Rusty notes that this overlooks the important case of single-sided funding, where the user is in control if the peer hasn't contributed funds.A new text has been proposed for `funding_locked_tlvs` in the lightning-rfc pull request #895. The proposed changes allow funding_locked to be sent early without any feature requirement. However, it is only useful if the sender is the sole funder or trusts the other side. The short_channel_id needs to be known for the channel for route hints and chainsplit scenarios. The proposed requirements state that the sender should set the short_channel_id and may send funding_locked before the funding transaction reaches minimum_depth if they are the sole contributor or trust the peer. If the sender will route payments to that short_channel_id, they may use a fake value. Otherwise, they must wait until the funding transaction reaches minimum_depth. The sender should re-transmit funding_locked if the short_channel_id for this channel has changed. The receiver should ignore the funding_locked if they know the short_channel_id and it differs from the value in funding_locked. Nodes that have funded the channel or trust their peers can start using the channel instantly by sending funding_locked.Martin has suggested adding a bit to signal whether zero-conf channels are fully operational or push-only. This idea was originally meant for trusted exchanges, but some implementations have made zero-conf channels fully operational. Martin would like to differentiate between the two cases. In the discussion about zero-conf channels, ZmnSCPxj suggests that the BOLT should have a "rationale" section and proposes using "initiator" and "acceptor" instead of "funder" and "fundee" in the context of dual-funding. Rusty adds that the risks for the sender and receiver of an HTLC depend on whether the channel confirms. However, he notes that single-sided funding is more common and provides a different perspective. If the user has control, they can safely send out an HTLC even before the channel confirms if they get the preimage. If the peer has contributed funds, cancellation results in a free refund, and incoming HTLCs should not be routed unless the user trusts the peer.The email thread discusses the implementation of zero-conf channels, which are currently not specified. A proposal suggests assigning a new feature bit "I accept zeroconf channels" and negotiating it per direction in the channel init message(s). The risks for the funder are that the channel never confirms, while the risks for the fundee are that the funder doublespends. HTLCs from unconfirmed channels should not be routed unless there is a reason to trust the peer. The terminology used in the discussion is also debated, with "funder" and "fundee" being deprecated in favor of "initiator" and "acceptor". The substantial feature of turbo channels is the confirmation of the channel, not the opening process itself.Rusty Russell proposed a way to handle zero-confirm channels, suggesting a new feature bit "I accept zeroconf channels" to be negotiated per direction in the channel init message(s). However, Matt Corallo suggested keeping things simple until channel_types is fixed. c-lightning will offer zero-conf channels but implement the "don't route from non-locked-in channels" option to minimize risks. The funder faces the risk of the channel never confirming but can close it on-chain if necessary. For fundees or DF channels, the risk is that the funder doublespends, so HTLCs should not be routed unless there is a reason to trust the peer.Rusty Russell proposed assigning a new feature bit for accepting zeroconf channels, which have been hackable for some time. This proposal aims to unlock new user experiences and formalize the use of zeroconf. Not every implementation accepts zero-conf channels, but they are desired by wallets and LN exchanges. Rusty plans to draft something this week.In a conversation between Bastien and Rusty, they discuss the implementation of `option_zeroconf` for channels. They agree that a signal is needed to indicate the use of zero-conf channels and consider two options: setting `min_depth = 0` or using a `channel_type` that sets `option_zeroconf`.
Updated on: 2023-07-31T23:29:55.974490+00:00