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

2018-11-06 Thread ZmnSCPxj via Lightning-dev
Good morning Laolu, >> I worry about doing away with initiator distinction > > Can you re-phrase this sentence? I'm having trouble parsing it, thanks. The initiator of an action is the node which performs the first step in an action. For instance, when opening a channel, the node which

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

2018-11-06 Thread Christian Decker
Olaoluwa Osuntokun writes: >> 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

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

2018-11-06 Thread Rusty Russell
Olaoluwa Osuntokun writes: >> Mainly limitations of our descriptor language, TBH. > > I don't follow...so it's a size issue? Or wanting to avoid "repeated" > fields? Not that smart: tools/extract-formats.py extracts descriptions from the spec for each message. It currently requires constants in

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

2018-11-05 Thread Olaoluwa Osuntokun
> Mainly limitations of our descriptor language, TBH. I don't follow...so it's a size issue? Or wanting to avoid "repeated" fields? > I thought about restarting the revocation sequence, but it seems like that > only saves a tiny amount since we only store log(N) entries Yeah that makes sense,

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

2018-11-05 Thread Olaoluwa Osuntokun
> 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

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

2018-10-24 Thread Rusty Russell
Conner Fromknecht writes: > In light of this, and if I'm following along, it seems our hand is forced in > splicing via a single on-chain transaction. In my book, this is preferable > anyway. I'd much rather push complexity off-chain than having to do a > mutli-stage splicing pipeline. Agreed.

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

2018-10-22 Thread Conner Fromknecht
Good evening lightning-dev, > If we receive later receive two `channel_update`s whose `short_channel_id`s > reference the spending transaction (and the node pubkeys are the same), we > assume the splice was successful and that this channel has been subsumed. I > think this works so long as the

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

2018-10-18 Thread ZmnSCPxj via Lightning-dev
Hi Rusty et al, Would this work? Glossary Old funding output - the TXO that the channel uses pre-splice. This must be a SegWit 2-of-2. New funding output - the TXO that the channel will use post-splice. This must be a SegWit 2-of-2. Old commitment transaction - a

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

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

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

2018-10-15 Thread Christian Decker
Olaoluwa Osuntokun writes: > Splicing isn't a substitute for allowing multiple channels. Multiple > channels allow nodes to: > > * create distinct channels with distinct acceptance policies. > * create a mix of public and non-advertised channels with a node. > * be able to send more than

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

2018-10-15 Thread Olaoluwa Osuntokun
> I would suggest more to consider the simpler method, despite its larger > onchain footprint (which is galling), The on-chain footprint is a shame, and also it gets worse if we start to allow multiple pending splices. Also the lack of a non-blocking splice in is a big draw back IMO. > but

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

2018-10-15 Thread Olaoluwa Osuntokun
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 allowing multiple channels. Multiple

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

2018-10-12 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > > > It may be good to start brainstorming possible failure modes during splice, > > and how to recover, and also to indicate the expected behavior in the > > proposal, as I believe these will be the points where splicing must be > > designed most precisely. What happens

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

2018-10-11 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, > > In BOLT #2 we currently impose a 2^24 satoshi limit on total channel > capacity. Is splicing intended to allow violation of this limit? I do not > see it mentioned in the proposal. Can I splice 21 million bitcoins on a > 1-satoshi channel? Good

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

2018-10-11 Thread Rusty Russell
Christian Decker writes: > On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell wrote: > >> > * Once we have enough confirmations we merge the channels (either >> > automatically or with the next channel update). A new commitment tx is >> > being created which now spends each output of each of the two

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

2018-10-11 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty and Christian and list, > This is one of the cases where a simpler solution (relatively > speaking ^^) is to be preferred imho, allowing for future > iterations. I would basically agree here, with the further proviso that I think splice is not quite as priority as AMP,

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

2018-10-11 Thread Christian Decker
On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell wrote: > > * Once we have enough confirmations we merge the channels (either > > automatically or with the next channel update). A new commitment tx is > > being created which now spends each output of each of the two funding tx > > and assigns the

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

2018-10-10 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, In BOLT #2 we currently impose a 2^24 satoshi limit on total channel capacity. Is splicing intended to allow violation of this limit? I do not see it mentioned in the proposal. Can I splice 21 million bitcoins on a 1-satoshi channel? It may be good to start brainstorming

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

2018-10-10 Thread René Pickhardt via Lightning-dev
Dear Rusty, thanks for the initiative. You suggested in your paragraph "messages changes during splicing" during splicing to duplicate each commitment transaction. One which spends the old funding tx and one which spends the spliced tx. I believe this can be simplified. Though I think my workflow

[Lightning-dev] Splicing Proposal: Feedback please!

2018-10-09 Thread Rusty Russell
Hi all! 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. Hence this rough proposal. For simplicity, I've chosen to only allow a single splice at a time. It's still