Single-asset LN channel design considerations

[dr-orlovsky]

On RGBCon0 in Milano @renepickhardt proposed to use single-asset LN channels, which:

• minimizes amount of LN message customization: in most cases we don't need TLVs and new types of messages, which is especially important for poorly-extensible gossips
• simplifies invoicing
• minimizes node code customization
• avoids reverse American call option problem as a whole

Nevertheless, using single-asset LN channels for RGB has its own trade-offs: addition of each asset will require new channel funding transaction, which limits scalability. Here I'd like to discuss the ways how we can mitigate this issue.

Channel splitting

Use channel splitting: create a new transaction spending funding output, which will contain new version of funding outputs, one per asset. Don't publish this information on-chain.
Pros:

• Fast and flexible way to open, close and distribute funds between multiple channels without any on-chain transactions
  Cons:
• Not supported by any existing lightning node, requires full LNP-node
• No standards for channel splitting in BOLTs: requires us to await for the standard — or work on it as a part of Generalized LN effort

Channel factories

Use channel factories: the same of above, but instead of splitting within the existing channel we use channel factory to create a new channel. The pros and cons are exactly like the above

Channel virtualization

Channel "superposition"/virtualization within the same commitment transaction: nodes operate multiple channels sharing single commitment transaction.
Cons:

• channel updates must be synched/put in strict serial order
• channels must share the same set of keys
• probably not standard-compatible
• low incentives for Lightning community to add support for the standards and existing software
  Pros:
• potentially can be done with c-lightning