Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread ZmnSCPxj via Lightning-dev
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

[Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-10-16 Thread Rusty Russell
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: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread lisa neigut
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

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread Rusty Russell
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

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread Rusty Russell
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

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread Johan TorĂ¥s Halseth
> > 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.

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread Christian Decker
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

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread ZmnSCPxj via Lightning-dev
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