The goal here is to have a generic k-of-n Lightning Network node. Channels require a A & B between the channel parties, and for this “k-of-n LN node” future, either of A or B or both may actually be a k-of-n.
Now, I believe ANY k-of-n policy can be iterated as a DNF, e.g. for a 2-of-4 of A B C D, that would be ((A & B) | (A & C) | (A & D) | (B & C) | (B & D) | (C & D)). And the DNF form can be converted to an equivalent CNF form (they are just normal forms and I believe any nested AND-OR expression can be converted to either form).
Thus, we can consider ANY general policy of nested AND and OR gates, then flatten them to AND-of-OR and feed it to Blisk.
Now the issues here for a k-of-n LN node are two-fold:
- Creating a new channel state basically requires a partial signature from the other side, but without the full signature being generated on our side — the point is that the full signature can only be safely generated on unilateral closure. The CNF at the Blisk level may require the creation of the FULL signature, which is unsafe — storing the full signature is unsafe as old state can now be posted by anyone who gets access to your stored full signatures. I would need to look more deeply into this to see if this is actually safe; my intuition is that there will be at least one term in the CNF that is controlled only by signatories of one side, which would serve as the decision-makers for when to do a unilateral close later (and create the full signature).
- After creating a new channel state, we need to invalidate old state. There is simply no way to do this that still respects the shachain requirement of BOLT, so we should “just” drop the shachain requirement. Without the shachain requirement, the public key for the revocation key can be generated using flatten-to-CNF-then-Blisk and then at revocation time, the same calculations are done on private keys this time, then the resulting private key is the revocation private key that you hand over to the other party to revoke your old state.
Both the above can be sidestepped by switching to Decker-Wattenhofer, BTW: each state change both creates the new state and invalidate old state in a single atomic step of creating the FULL signature under Decker-Wattenhofer. And Decker-Wattenhofer, unlike Decker-Russell-Osuntokun, does not require a consensus change.
Also this scheme of “flatten to CNF form and then Blisk” may be considered a generalization of this technique: https://delvingbitcoin.org/t/flattening-nested-2-of-2-of-a-1-of-1-and-a-k-of-n