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:
On RGBCon0 in Milano @renepickhardt proposed to use single-asset LN channels, which:
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:
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: