6

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
  • 11,670
  • 8
  • 35
  • 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](https://bitcoin.stackexchange.com/questions/84098/do-extra-hop-channels-in-a-bolt11-invoice-need-to-exist-on-chain) which you previously gave me an answer. – Mark H Mar 16 '19 at 20:09
  • 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 Mar 16 '19 at 20:14
  • 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 Mar 16 '19 at 20:24

1 Answers1

6

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
  • 9,319
  • 1
  • 38
  • 61
  • 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 Mar 17 '19 at 13:57
  • 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 Mar 17 '19 at 22:03
  • 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 Mar 17 '19 at 22:38
  • 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 Mar 18 '19 at 09:34