Published on: 2018-12-04T02:00:18+00:00
In a discussion on the Lightning-dev mailing list, user ZmnSCPxj suggested adding a 128-bit seed to the `open_channel2` function in order to improve security. They proposed sorting the seed by SHA (seed | input | ) and SHA (seed |) for added entropy. Rusty Russell responded that `open_channel2` already has a good amount of entropy due to its temporary channel ID and various basepoints. He suggested using an existing basepoint as the seed, such as the revocation_basepoint, which would not be exposed on-chain.Lisa Neigut proposes a draft for the new dual funding flow which involves creating a new channel open protocol set (v2) with three new message types. The proposal includes a quick overview of the message exchange for v2. The willingness to use v2 is flagged in init via `option_dual_fund`. The proposal also includes details about the various messages involved such as `accept_channel2`, `funding_puts2`, and `commitment_signed2`. The requirements for sending and receiving nodes are also mentioned. The proposal aims to allow each node to have a complete set of transaction inputs/outputs to derive the funding transaction hash while mitigating any asymmetry between the nodes.The context goes on to describe the requirements and rationale for RBF (Replace-By-Fee) for Channel Establishment v2. The first step is `init_rbf`, which is sent by the initiator after the funding transaction has been broadcast but before the `funding_locked2` has been exchanged. The sending node must set a larger `feerate_per_kw` than the most recent funding tx, and may update other parameters like amount, fee rate, dust limit, or channel reserve for the channel. The receiving node may reject the RBF request if there are any unreasonable demands or errors. If there are no errors or unreasonable demands, it should send an `accept_rbf` message.Exchanging witness data via `funding_signed2` allows either side to broadcast the funding transaction while maintaining information symmetry between the nodes. The sender must remember the details of this funding transaction and send one `witness_stack` for each `output_info` it sent in `funding_puts2`. The receiver should check that the number of witnesses sent matches the number of inputs. If a `witness_stack` length exceeds the corresponding `max_extra_witness_len`, it may error.If the receiving node has not received a valid `commitment_signed2` message, it must not send its `funding_signed2` message. The receiving node must verify the commitment signature is valid for the funding transaction-commitment transaction that it has derived independently. If this signature is invalid, it must fail the channel. If it has not sent a `commitment_signed2` message, it must send its `commitment_signed2` message.The previous channel establishment protocol compressed the commitment signature into `funding_created`/`funding_signed`, but with dual funding, the requirement is interaction to build the funding transaction and commitment signature exchange is now a separate step.A dual-funding node (B) should broadcast its funding transaction if it does not see the transaction broadcast after a reasonable timeout. The channel id that becomes fixed for this node will be determined by the `funding_locked2` message. Once an `init_rbf` has been accepted by the dual-funding node, the message flow returns to `commitment_signed2`.In this email exchange, ZmnSCPxj provides minor comments on two messages related to the Lightning Network protocol. In regards to `accept_channel2`, ZmnSCPxj suggests that the `options_tlv` type should be even instead of odd to ensure proper shutdown script enforcement. They clarify that being inside an `options_tlv` does not preclude the need for even/oddness designation. Regarding `funding_puts2`, ZmnSCPxj notes that this message exchanges input and output information needed for composing a funding transaction. They ask for clarification on whether `script` refers to `scriptPubKey` and what `wscript` is. The requirements for the sending node are stated, including ensuring each `input_info` refers to an existing UTXO and not spending any UTXOs specified in `funding_puts2` until/unless channel establishment has failed. However, it is unclear what action must be taken if a violation is detected. Finally, ZmnSCPxj mentions that the message borrows heavily from Rusty's splicing proposal and non-SegWit inputs should be assumed to be disallowed.This is a draft proposal for the new dual funding flow for Lightning developers.
Updated on: 2023-07-31T21:00:09.651065+00:00