Author: ZmnSCPxj 2023-09-18 04:14:55+00:00
Published on: 2023-09-18T04:14:55+00:00
Based on the email received, the main point discussed is the safety of user `B` creating something without a signature from user `A_i`. It is suggested that if the funding for the project comes solely from user `B`, it may not be safe unless user `A_i` provides a signature. The email mentions that if a specific user `A_i` never contacts user `B`, but still confirms the entire path from the funding transaction output to the `A_i && B` output, then the funds allocated by `B` are locked unless `B` receives a unilateral close signature from `A_i` to spend from the `A_i && B` output.The email emphasizes the need for `A_i` to be online when `B` signs the funding transaction that anchors the entire tree. It also mentions that many people lost funds when implementing `multifundchannel` because they didn't ensure that all counterparties in the same batch of openings had provided unilateral close signatures before broadcasting the funding transaction. Another alternative mentioned is to use a Spilman channel variant, where the leaf itself is infected with a lifetime `(A_i && B) || (B && CLTV)`. In this case, `B` can dedicate the leaf output to a separate transaction that spends from the `(A_i && B)` branch to a plain `A && B` Lightning channel. `B` can fund the tree and when `A_i` comes online and agrees to accept the channel from `B`, `A_i` creates two signatures: one for the transaction spending from `(A_i && B) || (B && CLTV)` to `A && B`, and another for the unilateral close transaction from the above output.Overall, the email discusses the importance of obtaining signatures from `A_i` for the safety of the project and highlights issues related to funding transactions and unilateral close signatures.
Updated on: 2023-09-19T01:56:23.179394+00:00