Good morning Laolu,

> Is there a fundamental reason that CL will never allow nodes to create
> multiple channels? It seems unnecessarily limiting.

The architecture of c-lightning assigns a separate process to each peer.  For 
simplicity this peer process handles only a single channel.  Some of the 
channel initiation and shutdown protocols are written "directly", i.e. if the 
BOLT spec says this must happen before that, we literally write in the C code 
this_function(); that_function();.  It would be possible  to change this 
architecture with significant difficulty.

However personally I do not really see the need to create multiple channels to 
a single peer, or increase the capacity with a specific peer (via splice or 
dual-funding).  As Christian says in the other mail, this consideration, is 
that it becomes less a network and more of some channels to specific big 
businesses you transact with regularly.  But I suppose, that we will have to 
see how the network evolves eventually; perhaps the goal of decentralization is 
simply doomed regardless, and Lightning will indeed evolve into a set of 
channels you maintain to specific big businesses you regularly work with.

>>    * [`4`:`feerate_per_kw`]
> What fee rate is this? IMO we should do commitmentv2 before splicing as then
> we can more or less do away with the initiator distinction and have most
> fees be ad hoc.

I worry about doing away with initiator distinction, as I worry that an 
initiatee may be forced to pay fees they did not really voluntarily consider 
paying, when they are given funds on a channel initiated by someone else in 
exchange for funds on a separate channel; but this is probably a separate topic.

>If you think any of these items is a higher priority than splicing then you
>can simply start working on them! There's no agency that prescribes what
>should and shouldn't be pursued or developed, just your willingness to
>write some code.

While true, for me personally I can only devote a limited amount of time to 
coding for Lightning, and thus I must always worry whether my priorities are 
even correct.  I find it very common that people want to prioritize splicing 
over AMP or watchtowers, which puzzles me, and I wonder if I am incorrect in my 

> One thing that I think we should lift from the multiple funding output
> approach is the "pre seating of inputs". This is cool as it would allow
> clients to generate addresses, that others could deposit to, and then have
> be spliced directly into the channel. Public derivation can be used, along
> with a script template to do it non-interactively, with the clients picking
> up these deposits, and initiating a splice in as needed.

I am uncertain what this means in particular, but let me try to restate what 
you are talking about in other terms:

1.  Each channel has two public-key-derivation paths (BIP32) to create onchain 
addresses.  One for each side of the channel.
2.  When somebody sends to one of the onchain addresses in the path, their 
client detects this.
3.  The client initiates a splice-in automatically from this UTXO paying to 
that address into the channel.

It seems to me naively that the above can be done by the client software 
without any modifications to the Lightning Network BOLT protocol, as long as 
the BOLT protocol is capable of supporting *some* splice-in operation, i.e. it 
seems to be something that a client software can implement as a feature without 
requiring a BOLT change.  Or is my above restatement different from what you 
are talking about?

How about this restatement?

1.  Each channel has two public-key-derivation paths (BIP32) to create onchain 
addresses.  One for each side of the channel.
2.  The base of the above is actually a combined private-public keypair of both 
sides (e.g. created via MuSig or some other protocol).  Thus the addresses 
require cooperation of both parties to spend.
3.  When somebody sends to one of the onchain addresses in the path, their 
client detects this.
4.  The client updates the current transaction state, such that the new commit 
transaction has two inputs ( the original channel transaction and the new UTXO).

The above seems unsafe without trust in the other peer, as, the other peer can 
simply refuse to create the new commit transaction.  Since the address requires 
both parties to spend, the money cannot be spent and there is no backoff 
transaction that can be used.  But maybe you can describe some mechanism to 
ensure this, if this is what is meant instead?

Lightning-dev mailing list

Reply via email to