Lightning Network multi-asset channels

[shesek]

Abstract

Support for funding, managing and transferring multiple asset types within Lightning Network channels.

Motivation

Decrease the costs and confirmation times for transacting with meta-protocol assets ("colored coins") by allowing users to transfer them over Lightning Network channels.

This could allow LN to be used as a scalable payment solution for fiat-backed crypto-tokens (like USDT, which is running on Omni), for high-frequency trading of stocks (like the Mycelium crowdsale tokens, which are running on Colu), and more.

Specification

Each channel can have multiple asset types associated with it. Channels must have exactly one asset that represents the native token of a blockchain (e.g. BTC for Bitcoin), which is always required for fees, plus zero or more additional meta-protocol assets. Nodes should reject channel requests with unknown assets.

The wire protocol changes are rather minimal:

• The crypto assets to be used throughout the channel are specified in the open_channel message as [2:num-assets] [num-assets*34:asset-ids].

• Any field that currently contains satoshis/millisataohis amounts is replaced with a variable-length [num-assets*(4|8):amounts] field that specifies an amount for each of the channel's assets, in the same order as they originally appear in open_channel.

  This effects the open_channel, accept_channel and add_update_htlc messages.

(See the attached patch for 02-peer-protocol.md for more details)

Rationale

• The proposed specs were designed to be as generic as possible and be agnostic to any specific meta-protocol implementation (Colu, Counterparty, ChromeWay, Omni, etc).

  It is up to implementations to define specific behaviors for funding the channel with multiple asset types (that is, creating a funding output containing both BTC and the meta asset(s)), updating the channel's commitment (usually by modifying the OP_RETURN-based meta-protocol instructions), etc.

• The proposed specs instruct implementations (as SHOULD) to implicitly determine the underlying blockchain being used according to the specified native blockchain token (i.e. the BTC asset implies the Bitcoin blockchain). Current implementations are expected to only support Bitcoin, but this opens up the door for supporting additional blockchains in the future.

  An alternative approach is an explicit separate field to specify the blockchain.

• Although the common case is channels with either one (just BTC) or two (BTC plus a single meta asset) assets, with 3 or more assets being an exception, these specs follow the Zero One Infinity priniciple (essentially, "Arbitrary fixed limits are a CodeSmell") and support any N number of assets.

• The exact asset id structure is not strictly defined as part of the proposed specs and is open to interpretation by implementations.

  The specs propose a 34 bytes long identifier, consisting of a 2 bytes protocol/version prefix followed by 32 bytes of arbitrary protocol-specific data (usually, a hash). This could perhaps be rounded up to 40 to add some extra space, like for flags/modifiers, but a hash should usually suffice. Some more input on this is needed from other meta-asset protocol developers.

  For native blockchain tokens, we can use the 0x0000 prefix followed by the blockchain's genesis block hash (or possibly H(pow_function || block_interval || genesis) to be even more precise), but this requires further discussion and is not specified in the proposed specs.

• The proposed specs only include num-assets in the initial open_channel message, and don't repeat it again in the accept_channel or update_add_htlc messages.

  The advantages are slightly smaller messages, less redundancy, and less code changes that are required in existing implementations (see "Backwards Compatibility").

  The disadvantage is that the channel's state (the number of assets) is now required* to properly parse messages.

  (* technically speaking, since the amounts are currently the only variable-length fields in the messages containing them, the number of assets could theoretically be deducted from the message itself - but this feels somewhat hacky and would break the moment another variable-length field is added.)

• The proposed specs for update_add_htlc takes a variable-length [num-assets*4:milliamounts] field, thus allowing the transfer of multiple asset types in a single message.

  If it feels like this adds too much complexity, this could be changed to something like [34:asset-id] [4:milliamount] (or perhaps even [2:asset-index] instead of the full asset-id to save some space) to support just a single asset.

• The dust-limit-satoshis field was left as-is and was not converted to a variable-length field. This is because, AFAICT, dust limits only ever make sense for the native blockchain token.

  That being said, an argument could be made that this should be supported, just for the sake of uniformity.

• Since amounts do not necessarily represent "satoshis" now, satoshis was renamed to to amounts and msat was renamed to milliamounts, but some other terminology like (m|milli)tokens or (m|milli)units could work too.

• The size of the open_channel, accept_channel and update_add_htlc messages is no longer fixed, and could vary based on the number of assets in the channel.

  This somewhat reduces the anonymity set for message size analysis, especially for channels with many assets - 1 asset (just BTC) would have the biggest anonymity set, 2 assets (BTC+meta-asset) would have a smaller one, and 3 (BTC+2 meta-assets) or more would (probably?) be tiny.

Backwards Compatibility

The new wire protocol is not backwards compatible with old software.

However, existing implementations have an easy upgrade route for quickly conforming to the new protocol specs while still only supporting BTC (until actual multi-asset support is built) - they just have to parse num-assets and assset-ids in the open_channel message and reject any channels whose asset-ids isn't exactly [ BTC ]. After verifying that, everything else remains (byte-for-byte) the same.

Further work

The specification document was not fully updated to reflect all changes and still requires some additional re-phrasing, re-structuring and field re-naming (especially regarding the amount fields, which should all be renamed and documented as containing multiple values). This will be completed as we get more community feedback and a general ACK for the direction we're taking.

Disclaimer & Association

This work is funded by Colu, which has its own colored coins scheme which it intends to develop on top of this protocol specification.

[josephpoon]

Thanks for your pull request! I'm personally very interested in getting support for cross-chain/tokens into lightning network spec, so work & thinking around this is greatly appreciated and is likely going to be a significant use case for the lightning network.

I do have some feedback and suggestions, and am definitely interested in seeing this merged sooner rather than later, provided that implementations don't have to do significant (or any tangible) work towards supporting it today.

• Asset is a loaded word, perhaps use the word "token" instead? I'm not sure what the common nomenclature within the community is, but I notice token seems like the most neutral word being used today. I'm personally open to whatever name, this is just a suggestion, but I'll be using the word token for the rest of this post.
• I think the open channel message should move the token-related aspects to the end of the message. The parameters per-token should be grouped together (so that asset-id, funding-amount, reserve, etc. are together and it can be conceptualized as one blob per token).
• I think there should be a strong preference towards 32-byte sized token-ids. Is there some specific restriction with Colu's colored coins which requires 34-bytes? Seems logical for you (or any implementation) to take the 34-byte IDs and hash them to 32-bytes, with some internal mapping.
• The native token (Bitcoin) MUST be the first item. There isn't any definition of the native token's ID, perhaps should be defined as all 0s initially, or more helpfully and my preference, the genesis block hash or genesis coinbase tx? Whatever it is, it should probably defined in-spec what the token-id/asset-id of BTC is defined as.
• "+or contains more than one native blockchain assets." Seems superflouous and potentially limiting. But might be helpful to specify in the same part that it MUST fail if it contains zero (for obvious reasons).
• Would probably be helpful to have some specifics /w the HTLC onion payment path for specifying routing, and eventually defining gossiping aspects.
• There could be lack of clarity with heterogeneous incompatible implementations, e.g. there could be significant problems in paying into channels with different token/colored-coins implementations, especially w/r/t the UI (someone tries to create a channel with a specific tokenID using the wrong platform). While this isn't necessarily part of the spec, it could be helpful in defining best-practices in how to construct things safely. My gut feeling is it's probably safe to give the user the native token to input in the UI, and then do SHA256(colu-34-byte-asset-id + "COLU-COLORED-COIN") or something to that effect. So the UI shows the "colu asset-id", but over-the-wire it shows a hash. This makes it very clear when setting up the channel what's going on, leaving the specifics to the implementations (i.e. the token implementation needs to know the asset-id). There are some impacts with what information gets disclosed when this is used for routing gossiping, but I don't see this as a problem, and this construction allows for flexibility without being overly verbose over the wire. I'm not emotionally attached to this particular solution, just something I'm concerned about and seems plausible.

An area which I do not have strong opinions on is how to do this with minimal disruption towards existing implementations. I don't expect many implementation to support multiple assets for a while, so more thinking is needed on how to go about this flexibly without blocking existing work. The simplest thing would be to simply error the channel out when it sees more than one num-assets and/or the asset-id isn't bitcoin or whatever. Not sure if this is a good case for flagging as optional bits...

I'll come up with more comments in the days ahead if anything comes up.

Thanks~~~!

[shesek]

Thanks for your pull request! I'm personally very interested in getting support for cross-chain/tokens into lightning network spec, so work & thinking around this is greatly appreciated and is likely going to be a significant use case for the lightning network.

I'm glad to hear that! Thanks for the enthusiasm (-:

provided that implementations don't have to do significant (or any tangible) work towards supporting it today.

One of the primary design goals for me was to make this as painless as possible for current implementations. Have you see the "Backwards Compatibility" section?

Asset is a loaded word, perhaps use the word "token" instead?

I'm thinking of "tokens" as the transferable units themselves and "asset" as the token types. But I have no strong preference either way.

I think the open channel message should move the token-related aspects to the end of the message.

To make this as least disruptive as possible to current implementations, I retained from moving things around too much. If we take the freedom to re-design the specs as we see fit, then yes - I think that some re-ordering is in order.

The parameters per-token should be grouped together (so that asset-id, funding-amount, reserve, etc. are together and it can be conceptualized as one blob per token).

I have a slight preference for the format of every amount field grouping the values for all the assets together (can be thought of as asset-ids=BTC,USDT;funding-amount=200000,5000;push-amount=10000,250), but I don't feel strongly about that - your approach (can be thought of as asset-id=BTC{funding-amount=200000,push-amount=10000};asset-id=USDT{funding-amount=5000,push-amount=250}) works too.

I think there should be a strong preference towards 32-byte sized token-ids. Is there some specific restriction with Colu's colored coins which requires 34-bytes?

The extra two bytes are for identifying the protocol being used (Colu, Counterparty, Omni, etc).

You're right in that IDs can always be trimmed down (at the cost of losing some collision resistance). If a total of 32 bytes is important then I would be okay with 2 bytes version + 30 bytes ID (but I do think that the version bytes should be there - see below for more on that).

The native token (Bitcoin) MUST be the first item.

I didn't see much importance for their order, just for the fact that a native token must be specified, but sure - we can add this as a requirement.

There isn't any definition of the native token's ID, perhaps should be defined as all 0s initially, or more helpfully and my preference, the genesis block hash or genesis coinbase tx?

It's not part of the specs themselves, but I offered something similar under "Rationale" in the pull request (bullet 4): For native blockchain tokens, we can use the 0x0000 prefix followed by the blockchain's genesis block hash (or possibly H(pow_function || block_interval || genesis) to be even more precise), but this requires further discussion and is not specified in the proposed specs.

"+or contains more than one native blockchain assets." Seems superflouous and potentially limiting.

Under what circumstances can we have multiple native tokens in the same channel? My understanding was that every channel conceptually represents a funding output, which can only exists on one blockchain which can only handle its own native tokens.

Or are you thinking of "channels" as something that could conceptually span multiple blockchains/outputs? I'm aware of the hash-lock-based cross-chain swaps LN is capable of, but is it going to be abstracted as a single channel spanning multiple blockchains, or as multiple channels each in its own blockchain and using hash-locks to achieve atomicity between them?

But might be helpful to specify in the same part that it MUST fail if it contains zero (for obvious reasons).

The full paragraphs says this: "The receiving node MUST fail the channel if it contains any unknown or unsupported assets, does not contain any native blockchain assets, or contains more than one native blockchain assets."

Would probably be helpful to have some specifics /w the HTLC onion payment path for specifying routing, and eventually defining gossiping aspects.

Yeah, there's definitely some more work to do around these parts. I'll give it some thought.

There could be lack of clarity with heterogeneous incompatible implementations, e.g. there could be significant problems in paying into channels with different token/colored-coins implementations, especially w/r/t the UI (someone tries to create a channel with a specific tokenID using the wrong platform). While this isn't necessarily part of the spec, it could be helpful in defining best-practices in how to construct things safely. My gut feeling is it's probably safe to give the user the native token to input in the UI, and then do SHA256(colu-34-byte-asset-id + "COLU-COLORED-COIN") or something to that effect. So the UI shows the "colu asset-id", but over-the-wire it shows a hash. This makes it very clear when setting up the channel what's going on, leaving the specifics to the implementations (i.e. the token implementation needs to know the asset-id). There are some impacts with what information gets disclosed when this is used for routing gossiping, but I don't see this as a problem, and this construction allows for flexibility without being overly verbose over the wire. I'm not emotionally attached to this particular solution, just something I'm concerned about and seems plausible.

That's what the prefix version bytes were meant to solve.

Under your proposed solution, the asset id itself wouldn't convey information about the protocol being used - the user would have to specifically input the asset id in a Colu-only software, or manually pick "Colu" under some dropdown. I think that an asset id that users can send to each-other and which already encapsulates that information would be better.

[rustyrussell]

Joseph Poon <notifications@github.com> writes:

Thanks for your pull request! I'm personally very interested in getting support for cross-chain/tokens into lightning, so work & thinking around this is greatly appreciated and is likely going to be a significant use case for the lightning network. I do have some feedback and suggestions, and am definitely interested in seeing this merged sooner rather than later, provided that implementations don't have to do significant (or any tangible) work towards supporting it today.

I agree that it's interesting, but I'm extremely reluctant to expand the current spec. The upgrade path is fairly clear for doing this later, though. In practice, I'd want to see a scratch implementation before rushing into a spec, because there are complexities all over this. In particular, what does a commitment transaction which contains an asset/token look like? That's the core problem to solve, and everything else grows out of that. Perhaps that's already a solved problem? Thanks, Rusty.

[shesek]

In practice, I'd want to see a scratch implementation before rushing into a spec, because there are complexities all over this.

We're definitely looking to implement the Colu coloring scheme using this protocol specification (based on lnd, in two stages - an abstraction layer for generic multi-asset support first, then a colu-specific "driver" built on top), but it is critical for us to know that we're doing this in a way that the community supports and which has a chance to eventually get merged back upstream.

(BTW - we do have a PoC implementation of Colu coloring on top of lnd, but as a quick & dirty hack, without the generic multi-asset abstraction layer, and without using the wire protocol proposed here.)

In particular, what does a commitment transaction which contains an asset/token look like?

The proposed specifications intentionally do not go into these details. They just extend the wire protocol to allow nodes to talk in terms of multiple asset types identified by IDs, and leaves all the coloring-scheme-specific details to implementations.

That being said, the most common coloring schemes used today involve some variant of encoding meta protocol instructions in OP_RETURN outputs. A color-aware lightning implementation would need to mutate these OP_RETURN instructions as the state/commitment updates.

[rustyrussell]

Nadav Ivgi <notifications@github.com> writes:

That being said, the most common coloring schemes used today involve some variant of encoding meta protocol instructions in OP_RETURN outputs. A color-aware lightning implementation would need to mutate these OP_RETURN instructions as the state/commitment updates.

But this doesn't work, as you can't produce standard transactions with multiple OP_RETURN. And how do you encode a conditional transfer, eg. "You can have this asset if you provide the payment preimage, otherwise I can have it back after some period of time"? The wire protocol is the least of your problems, AFAICT. Hope that helps, Rusty.

[shesek]

But this doesn't work, as you can't produce standard transactions with
multiple OP_RETURN.

The OP_RETURN output contains instructions regarding the transfer of colored assets from the inputs to the outputs. There should only be one of these, regardless of the number of inputs/outputs (with the Colu protocol, the 80 bytes allowed on OP_RETURN are enough for 20-25 instructions).

And how do you encode a conditional transfer, eg. "You can have this
asset if you provide the payment preimage, otherwise I can have it back
after some period of time"?

The Colu colored coins scheme is based on the output model of bitcoin and works alongside it. Script can still be used to put constrains on how the output can be spent, in the same manner that you would normally use it. This is also true of some of the other meta-asset protocols, but not all (like Omni, though I understand that they're showing some interest in moving to an output-based model for script- and LN- compatibility. @udiWertheimer can perhaps expand on that).

As an example, a commitment transaction spending a colored funding output (of, say, crypto-euros) to HTLC outputs would look like that:

• input #1: channel funding output, contains 10,000 satoshi (for fees and dust, + 100 crypto-euros according to the meta-protocol)

• output #1: HTLC script (multisig/timelock/hashlock) to Bob with 600 satoshis (+ 70 crypto-euros according to the meta-protocol)

• output #2: HTLC script (multisig/timelock/hashlock) to Alice with 600 satoshis (+ 30 crypto-euros according to the meta-protocol)

• output #3: OP_RETURN output containing instructions to transfer 70 crypto-euros to the first output and 30 crypto-euros to the second

  (for Colu that would be OP_RETURN 0x43430215002071011E, where 0x4343 is the protocol, 0x02 is the version, 0x15 is an internal opcode/flag and 0x002071011E encodes the instructions "transfer 70 tokens from input #1 to output #1" and "transfer the remaining 30 tokens from input #1 to output #2".)

[jjmr007]

Hi guys, I'm relatively new in crypto and bitcoin and I'm not a coder either, but this project draws powerfully my attention for its enormous potential and I've been curious on and getting acquinted with lightning network for several months since last year.

This multi-asset channel proposal is a very interesting pull request, and in the name of the progress I've decided taking the risk of making a fool of myself here, with these observations:

1°.- Conceptually, Lightning Network is a new layer of network services, which has been built over the layer of Bitcoin, but also directly over TCP/IP. As I see it, Lightning has two main modules of services and apps: The transaction handling module and the circuit-oriented network module. This last module relies strongly on TCP/IP and as I see it is a master piece.

But by the other hand, the transaction module has been built directly over a Bitcoin network which do not exist yet: A Bitcoin layer WITH the Seg-Wit package of services. This by itself is not a problem, since I think Seg-Wit will be activated soon on Bitcoin, but this is a restriction for the adoption of cross-chain tokens (coloured coins) in this network. The reason for this is twofold. ONE: the very architecture of network layers as it has been evolving so far. Meta-Protocols came first. LN should adapt to meta-protocols, not the contrary.
Meta-Protocols are network layers built over (an existing) Bitcoin layer, and many of them (Omni, Colu, etc.) are working hard to be compatible with Seg-Wit when the time comes. But it is not necessarily the case of all of them.
TWO: (I'm risking to make even more the ridiculous here) Meta-Protocol layers based on "Class C" encoded transactions after OP_RETURN code, offer (may be accidentally) a high degree of protection against a malleability attack. (The reason for this as I see it is quite trivial, but I'll leave the explanation to the end of the post). So RIGHT NOW a lightning network could exist and operate over the existing Bitcoin layer, only if the transactions module of LN were built over the layer of Meta-Protocols, i.e. if the only coins to be on trade were colour coins or tokens, not bitcoins.
And if LN project aims to be the most agnostic possible, it would be of great benefit to be able to operate over both scenarios: Over the layer of a blockchain wit SegWit and over a Meta-Protocol compatible or not with Seg-Wit operating over a blockchain with or without Seg-Wit. Meta-Protocol transactions are relatively easy to struct, as the previous post of @shesek shows. They are just bitcoin transactions with a "comment" in an output headed with the op code "return".

2°.- LN project will be a very demanded app if it allows from its network layer, the development of future layers of new and interesting network services, which would use more complex smart contracts. In order to be able to do it, LN may provide you with an extra module of apps for allowing to the user more generic HTLC's. Not a big deal, LN just need HTLC's wich allows more elaborated booleans with hashes functions like H(x)&H(y)||H(z) in the script of a HTLC.
Sadly, the things as I see them may require a lot of work right now, but it is likely that creating some fork in the code (as Colu people did) to make room to further aplications in LN as a network layer, may be feasible, enabling improvements in the near future. The details of these changes may require detailed discussions in spaces/forums like this. But it is needed first some conceptual talking. This is how I see the LN right now. And this is how (IMHO) it should fork or evolve.
Lightning network may be in a near future the platform for new networks of trade, exchange of assets and for hiring services, and it will only be possible if these new layers can request services to LN, by accesing some kind of service access point.
In the case of bitcoin, this access was made by the OP_RETURN code, and it is expected to mutate to Seg-Wit to allow more services like those demanded by LN, and new features as Schnorr signatures. The same scenario will happen with LN itself.
The current standard HTLC in LN is useful just to make simple sendings of funds from one user to other.
Does LN allows or not, right now, to its users generating (by themselves or by the use of a higwer layer of network services) tailored HTLCs in order to commit funds in some more encumbered contracts? If the answer is NO, then some fork will be needed in order to allow further developments in the future. And likely this feature will exist whether by fixing the present LN project or in a future fork of this project.

Colu is trying to make some room for new features in LN (this request), and that´s interesting.

I really apologize for these comments, if this is not the proper space to discuss them. In that case I would appreciate if you suggest another place I would go and post, but I thought this post would be a good start.

3.- Immunity to malleablity attacks over "Class C" transactions of meta-protocol layers. Meta protocols give a pretty high protection against malleability. LN may be adapted and benefit from the advantages of these protocols, but some extra (and simple) steps are required. To illustrate how simple it would be I'll describe an example: Opening a Channel.

Let suppose Alice wants to fund a channel with Bob. Let's suppose it will be funded with a famous token, (allegedly) pegged to the dollar: The Tether, which is an Omni-Core token.

1. Alice and Bob calculate the Channel P2SH, from the script:
   2 [Alice Pub Key] [Bob Pub Key] 2 CHECKMULTISIG

2. Alice then funds P2SH just with (2700 + fee) satoshis in a pure and simple bitcoin transaction.

3. Alice and Bob waits until the former transaction gets at least 3 confirmations.

4. Alice structs a transaction template in which one input will use the UTXO of the former (confirmed) transaction; and a couple of outputs, one output to the Alice's P2PKH, paying just 2700 satoshis (the rest of UTXO's satoshis goes for the miners as fees), and other output which is a comment headed with the OP_RETURN code, and a message wich will encode the transfer of, say, 1.000,oo Tethers. Alice gives this template to be signed by Bob, and this will be the refund transaction.

5. Alice then sends to P2SH, an Omni-Core transaction for 1.000,oo Tethers. This is the funding transaction. This transaction has more or less the same structure explained by @shesek in the former comment.
   One input: Uses any UTXO owned by Alice, Three outputs: one with (2700 + fees) satoshis to P2SH, other as a comment with OP_RETURN, (with the code of 1.000,oo Tethers sent) and a third output giving the rest of the satoshis back to any Alice's address (minus fees).
   The refund transaction doesn't need to refer to the same UTXO of this transaction just described, because omni transactions (Or any other meta-protocol layer like Omni, Colu, etc.) are parsed by the omni virtual machine to assign balances to the involved addresses. This way, this kind of protocol is immune (up to some degree) to malleability attacks.

It can be proved that by taking similar simple steps (just few extra pre-funding tx's placing into certain P2SH addresses with few satoshios), the whole ligtning procedure can be perfectly implemented over these kind of meta protocol layers existing today, and with all the other (the vast majority of) tx's occuring off-chain.

In conclusion: just wanted to leave my personal view on the best path for the LN evolution; If this sparks some interest, it will be great to approach the subject with more details, thus I'll be able to share my ideas about a LN opperating over meta-protocol layers and how would run a higher layer of merchant and trade network, calling to the services of LN.

[jonathancross]

Seems things got a bit derailed here...

@jjmr007, you clearly have a lot of interest in this, but it might be more constructive to discuss on the Mailing list or in a separate pull request.

@shesek Any updates to share?

[dr-orlovsky]

Just to let you know, we are currently actively working on RGB — bitcoin-based assets with near-zero blockchain pollution and client-side validation, basing on original idea by Peter Todd on single-use seals. It has a special part allowing to add assets into LN channels, named Spectrum; you can read more on the topic at https://github.com/rgb-org/spec/blob/spectrum-0.5/04-lightning-network.md.

Spectrum works fine with the current BOLTs, since it does not modifies the transaction structure; the only two things that are required to make it compatible with all existing LN nodes is to

1. add TLV extension to most of LN messages (see BOLT 1: Add a TLV stream extension to existing messages. #630 (comment) for details);
2. create some BOLT standardizing plug-in interface across all LN node implementations, in particular we need to change public key inside P2WPKH output the commitment and HTLC transactions.

[sidhujag]

@dr-orlovsky @rustyrussell @Roasbeef @shesek I don't think it makes a whole lot of sense to do multi-asset payment channels. Today I took the time to really try to understand the theoretical attack vectors and we came with a vector of attack that I cannot see a way around leading us to believe that single asset LN is the only thing that will work, not to say that multi-asset strategies aren't useful just that using them on a singular p2p network doesn't make a whole lot of sense unless someone can show a way around the issue which is related to how payment channels work in our current understanding. Atomic swaps is going to be the only way to move assets across blockchains because the external rate exchange between the two tokens are attached to a single point in time and not susceptible to time-delay attacks.

As you can see, a single exchange rate in time cannot be chosen between the two tokens A and B, and thus the exchanger (channel between A<->B) either is going to be drained, or if parameters chosen in another way, will drain either ends up the parties looking to send payments through exchanging channels.

If you assume that 1 and 4 user are the same person, they can set up an American Call Option to choose at the end of time delay to choose which side of the channel to accept based on economic incentives. This was described here https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html by ZmnSCPxj.

Because either way you cut it, economic incentives prevents dishonest players from creating risk-free arbitrage opportunities it is very likely only to make sense that off-chain payment systems will deal with single assets only unless the construction of such channels is drastically different.

The only thing that I can see would offset it is premiums that are based on time value of the time lock timeout in relation to volatility.

[t-bast]

This has been inactive for a while, and other proposals exist for the use-case that don't require any change to the BOLTs (TapAss and RGB for example).