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 initiate
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
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
> 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, fo
> 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
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. A
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 spe
Good evening all,
Thank you Rusty for starting us down this path :) and to ZmnSCPxj and Lisa
for
your thoughts. I think this narrows down the design space considerably!
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 b
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 Poon-Dryja-revoca
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
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
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
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
>
> 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
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
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
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 the
> 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 mostly
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
chan
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 wh
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 quest
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 f
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, decorre
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 ch
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 p
René Pickhardt writes:
> So let us take the example of Splicing in:
> * The situation before splicing is that we have one output in our funding
> tx that is being spent with each commitment tx. (actually if the channel
> was spliced before we have more inputs but that should not change anything)
>
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
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 comple
28 matches
Mail list logo
