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.