Scaling Lightning With Simple Covenants

The author suggests that if the funding for this project comes solely from B, it may not be safe unless it receives a signature from A_i. The email mentions that if a particular A_i does not contact B but still confirms the entire path from the funding transaction output to the A_i && B output, the funds allocated by B will be locked unless B obtains a unilateral close signature from A_i to spend from A_i && B.The author also mentions that A_i needs to be online when B signs the funding transaction that anchors the entire tree. Failure to do so may result in the loss of funds, as seen with the implementation of multifundchannel by others. It is important to ensure that all counterparties in the same batch of openings have given unilateral close signatures before broadcasting the funding transaction.Another alternative discussed is infecting the leaf itself with a lifetime (A_i && B) || (B && CLTV), which is described as a Spilman channel variant used in swap-in-potentiam. In this scenario, B can dedicate the leaf output to a separate transaction that spends from the (A_i && B) branch and sends 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 (A_i && B) || (B && CLTV) and another for the unilateral close transaction from the aforementioned output.In conclusion, this email discusses the importance of obtaining a signature from A_i for the safety of a project, the need for A_i to be online when B signs the funding transaction, and the alternative approach of using a Spilman channel variant.