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
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,
> 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
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
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
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.
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
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
> 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
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
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
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,
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
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
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
18 matches
Mail list logo
