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

[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