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