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

<h2><code>channel_announcement</code></h2>

<blockquote>
  <ol>
  <li>type: 256 (<code>channel_announcement</code>)</li>
  <li>data:
  
  <ul>
  <li>[<code>64</code>:<code>node_signature_1</code>]</li>
  <li>[<code>64</code>:<code>node_signature_2</code>]</li>
  <li>[<code>64</code>:<code>bitcoin_signature_1</code>]</li>
  <li>[<code>64</code>:<code>bitcoin_signature_2</code>]</li>
  <li>[<code>2</code>:<code>len</code>]</li>
  <li>[<code>len</code>:<code>features</code>]</li>
  <li>[<code>32</code>:<code>chain_hash</code>]</li>
  <li>[<code>8</code>:<code>short_channel_id</code>]</li>
  <li>[<code>33</code>:<code>node_id_1</code>]</li>
  <li>[<code>33</code>:<code>node_id_2</code>]</li>
  <li>[<code>33</code>:<code>bitcoin_key_1</code>]</li>
  <li>[<code>33</code>:<code>bitcoin_key_2</code>]</li>
  </ul></li>
  </ol>
</blockquote>

<h2><code>channel_update</code></h2>

<blockquote>
  <ol>
  <li>type: 258 (<code>channel_update</code>)</li>
  <li>data:
  
  <ul>
  <li>[<code>64</code>:<code>signature</code>]</li>
  <li>[<code>32</code>:<code>chain_hash</code>]</li>
  <li>[<code>8</code>:<code>short_channel_id</code>]</li>
  <li>[<code>4</code>:<code>timestamp</code>]</li>
  <li>[<code>1</code>:<code>message_flags</code>]</li>
  <li>[<code>1</code>:<code>channel_flags</code>]</li>
  <li>[<code>2</code>:<code>cltv_expiry_delta</code>]</li>
  <li>[<code>8</code>:<code>htlc_minimum_msat</code>]</li>
  <li>[<code>4</code>:<code>fee_base_msat</code>]</li>
  <li>[<code>4</code>:<code>fee_proportional_millionths</code>]</li>
  <li>[<code>8</code>:<code>htlc_maximum_msat</code>] (option_channel_htlc_max)</li>
  </ul></li>
  </ol>
</blockquote>

<p>If you look at this you'll see that the <code>channel_announcement</code> 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.</p>

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

<p><code>channel_update</code> may seem a bit more complicated since now there are <code>n*(n-1)</code> 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.</p>

<p>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.</p>

CC BY-SA 4.0
2019-03-17T13:57:09.833Z
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
CC BY-SA 4.0
2019-03-17T22:03:59.820Z
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
CC BY-SA 4.0
2019-03-17T22:38:45.150Z
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
CC BY-SA 4.0
2019-03-18T09:34:01.063Z
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
CC BY-SA 4.0
2019-03-17T13:37:57.810Z
2019-03-17T13:37:57.810Z
cdecker
<p>I was just listening to <a href="https://www.youtube.com/watch?v=21k8cUFZ7xs" rel="noreferrer">SLP59 with Christian Decker</a>. They mainly discussed channel factories. While the construction of multiparty channels and higher order systems (sub channels) being derived from them seems clear 
 and <a href="https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf" rel="noreferrer">is being described in this paper</a> I wonder how the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md" rel="noreferrer">gossip protocol</a> would have to be adapted so that people would be able to announce such channels? </p>

<p>Generally there is the necessity to point to a funding tx of a payment channel in order to prevent spamming <code>channel announcment</code> 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. </p>

<p>How would a solution for the gossip protocol look like? </p>

CC BY-SA 4.0
2019-03-16T20:09:52.953Z
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
CC BY-SA 4.0
2019-03-16T20:14:03.933Z
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
CC BY-SA 4.0
2019-03-16T20:24:58.200Z
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
<development><lightning-network><protocol><lightning-rfc><channel-factories>
How would the gossip protocol announce channels from a channel factory?
Rene Pickhardt
# How would the gossip protocol announce channels from a channel factory?

(Asked by: username_0 on 2019-03-15)

I was just listening to [SLP59 with Christian Decker](https://www.youtube.com/watch?v=21k8cUFZ7xs). 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](https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf) I wonder how the [gossip protocol](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md) 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?

**Tags:** development, lightning-network, protocol, lightning-rfc, channel-factories

> **Comments:**
> **username_1**: 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.  
> **username_1**: 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.  
> **username_1**: 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.  

---

## 1 answers

### Answer by username_2 on 2019-03-17. Score: 6 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  
> **username_2**: 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 :-)  
> **username_0**: 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  
> **username_2**: 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 :-)  

---

