How would the gossip protocol announce channels from a channel factory?

4

I was just listening to SLP59 with Christian Decker. They mainly discussed channel factories. While the construction of multiparty channels and higher order systems (sub channels) being derived from them seems clear and is being described in this paper I wonder how the gossip protocol would have to be adapted so that people would be able to announce such channels?

Generally there is the necessity to point to a funding tx of a payment channel in order to prevent spamming channel announcment messages and in order to authenticate channels. However with channel factories there is only one large funding tx for the multiparty channel. The sub channels are offchain.

How would a solution for the gossip protocol look like?

Rene Pickhardt

Posted 2019-03-15T22:33:44.047

Reputation: 6 565

I don't know enough about this to give a proper answer. It seems like the semantics of short_channel_id would need changing, or that the channels would need to be private and the short_channel_id could be a made up value passed in a BOLT#11 invoice. Related question which you previously gave me an answer.

– Mark H – 2019-03-16T20:09:52.953

Another possibility which might be possible without changes to gossip, is that the short_channel_id of the hook transaction could be used in the BOLT#11 invoice, and the payee could pass the payment_hash to their channel peer privately, so that when the peer receives an incoming update_add_htlc with the hook's short_channel_id and that payment_hash, they know which member of the channel factory it is intended for. For outgoing payments, the participants would have a channel_id for the transaction which does not depend on it being in a specific location on the blockchain. – Mark H – 2019-03-16T20:14:03.933

Another (perhaps bad) idea is to use the short_channel_id of the hook transaction, and when the factory participant receives an update_add_htlc, they broadcast it to all of the members of the factory. All but one member should return a update_fail_malformed_htlc, and one member should return either an update_fulfull_htlc or update_fail_htlc. The node could collect these replies and figure out who it was intended for. – Mark H – 2019-03-16T20:24:58.200

Answers

4

Pretty much everything would stay the same. If you look at the relevant messages channel_announcement and channel_update we have the following formats:

channel_announcement

  1. type: 256 (channel_announcement)
  2. data:
    • [64:node_signature_1]
    • [64:node_signature_2]
    • [64:bitcoin_signature_1]
    • [64:bitcoin_signature_2]
    • [2:len]
    • [len:features]
    • [32:chain_hash]
    • [8:short_channel_id]
    • [33:node_id_1]
    • [33:node_id_2]
    • [33:bitcoin_key_1]
    • [33:bitcoin_key_2]

channel_update

  1. type: 258 (channel_update)
  2. data:
    • [64:signature]
    • [32:chain_hash]
    • [8:short_channel_id]
    • [4:timestamp]
    • [1:message_flags]
    • [1:channel_flags]
    • [2:cltv_expiry_delta]
    • [8:htlc_minimum_msat]
    • [4:fee_base_msat]
    • [4:fee_proportional_millionths]
    • [8:htlc_maximum_msat] (option_channel_htlc_max)

If you look at this you'll see that the channel_announcement includes a lexicographically sorted list of node and bitcoin signatures and their corresponding pubkeys. This is trivial to extend to arbitrary number of participants by making this list variable in length.

In particular the short_channel_id still refers to the single output that the off-chain contract was opened with, that'd also stay the same.

channel_update may seem a bit more complicated since now there are n*(n-1) possible directions (sender-receiver pairs) this contract can be traversed, whereas in the simple 2 participant channel we just have 2 directions. The direction concept can however be easily extended to just lexicographically rank all sender-receiver pairs and use the index to identify the pair.

It is likely that some of the message formats need to be amended (variable length pubkey and signature lists) and some fields be made explicit (rank index for sender-receiver pair), but the general concept stays the same.

cdecker

Posted 2019-03-15T22:33:44.047

Reputation: 7 878

the capacity of the channel is not part of any of the 2 messages. I believe currently we know the capacity of the initial channel from the onchain funding tx. but when creating sub channels we need to account for the capacities and make sure that the total capacity is not exceeding the capacity of the funding tx. – Rene Pickhardt – 2019-03-17T13:57:09.833

That is no different from the current situation: you know that both endpoints of an LN channel have a cumulative balance of x if the output is for x satoshis, but you don't know the actual current balance. With multi-party channels instead of splitting the cumulative balance in two you split it into n for n participants, everything else remains the same :-) – cdecker – 2019-03-17T22:03:59.820

I think I was talking about something different. When a multiparty channel is being used for a channel factory the subchannel derived from it should be announced over the gossip protocol (BOLT 07) this channel needs to have a capacity. as you mentioned in analogy to our current system this would correspond to the balance and be private. but a channel coming from a factory should not be that way. in particular if members from the party drop out and the subchannels become visible on the blockchain as the settlement tx (as in the eltoo case) of the multiparty channel is broadcasted – Rene Pickhardt – 2019-03-17T22:38:45.150

In case all members are still responding the channel allocations inside of the factory really aren't important, since you can replace them on a whim (actually no need to create channels in the first place, just move balances between participants). When participants become unresponsive you drop to chain and all of the sudden you have an on-chain funding for a normal lightning channel :-) – cdecker – 2019-03-18T09:34:01.063

Asked: 2019-03-15T22:33:44.047

Viewed: 138 times

Active: 2019-03-17T13:37:57.810