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 th
ZmnSCPxj via Lightning-dev
writes:
>> 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 cha
>
> This is one of the cases where a simpler solution (relatively
> speaking ^^) is to be preferred imho, allowing for future
> iterations.
>
I think we should strive to splice in 1 on-chain tx, as if not the biggest
benefit really is lost compared to just closing and reopening the channel.
Compl
Rusty Russell writes:
> If we're going to do side splice-in like this, I would use a very
> different protocol: the reason for this protocol was to treat splice-in
> and splice-out the same, and inline splice-in requires wait time. Since
> splice-out doesn't, we don't need this at all.
>
> It wou
Olaoluwa Osuntokun writes:
> Hi Rusty,
>
> Happy to get the splicing train rolling!
>
>> We've had increasing numbers of c-lightning users get upset they can't
>> open multiple channels, so I guess we're most motivated to allow splicing
> of
>> existing channels
>
> Splicing isn't a substitute for
To add some context to this, if you start accepting HTLC's for the new
balance after the parallel commitment is made, but before the re-anchor is
buried, there's the potential for a race condition between a unilateral
close (or any revoked commitment transaction) and the re-anchoring
commitment tra
Hi all,
Everywhere in the protocol where we negotiate, we've had
problems: what do you do if you can't agree? In most cases, we've
settled on defacto generally-accepted values which aren't mentioned
anywhere in the spec (I've skimmed codebases below, looked at defaults).
I'd like to re-ex
Good morning lisa,
This is a good observation.
Before, I'd already considered the rationale, for why channels have a single
2-of-2 UTXO as funding output. And it seems I should have considered this,
prior to accepting the "parallel" construction as feasible.
For sake of posterity, I leave the
