Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-06 📝 Original message: > However personally I do ...
📅 Original date posted:2018-11-06
📝 Original message:
> 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 specific
big
> businesses you transact with regularly.
I made no reference to any "big businesses", only the utility that arises
when one has multiple channels to a given peer. Consider an easier example:
given the max channel size, I can only ever send 0.16 or so BTC to that
peer. If I have two channels, then I can send 0.32 and so on. Consider the
case post AMP where we maintain the current limit of the number of in flight
HTLCs. If AMP causes most HTLCs to generally be in flight within the
network, then all of a sudden, this "queue" size (outstanding HTLCS in a
commitment) becomes more scarce (assume a global MTU of say 100k sat for
simplicity). This may then promote nodes to open additional channels to
other nodes (1+) in order to accommodate the increased HTLC bandwidth load
due to the sharded multi-path payments.
Independent on bolstering the bandwidth capabilities of your links to other
nodes, you would still want to maintain a diverse set of channels for fault
tolerance, path diversity, and redundancy reasons.
In the splicing case, if only a single in flight splice is permitted, and me
as users wants to keep all their funds in channels, the more channels I
have, the more concurrent on-chain withdraws/deposits I'll be able to
service.
> I worry about doing away with initiator distinction
Can you re-phrase this sentence? I'm having trouble parsing it, thanks.
> which puzzles me, and I wonder if I am incorrect in my prioritization.
Consider that not all work items are created equal, and they have varying
levels of implementation and network wide synchronization. For example, I
think we all consider multi-hop decor to be a high priority. However, it
has the longest and hardest road to deployment as it effectively forces us
to perform a "slow motion hard-fork" within the network. On the other hand,
if lnd wanted to deploy a flavor of non-interactive (no invoice) payments
*today*, we could do that without *any* synchronization at the
implementation of network level, as it's purely an end-to-end change.
> I am uncertain what this means in particular, but let me try to restate
> what you are talking about in other terms:
Thought about it a bit more (like way ago) and this is really no different
than having a donation page where people use public derivation to derive
addresses to deposit directly to your channel. All the Lightning node needs
to do, is recognize that any coins send to these derived addresses should be
immediately spliced into an available channel (doesn't have any other
outstanding splices).
> It seems to me naively that the above can be done by the client software
> without any modifications to the Lightning Network BOLT protocol
Sticking with that prior version yes, this would be able to be seamlessly
included in the async splce proposal. The one requirement is a link-level
protocol that allows both sides to collaboratively create and recognize
these outputs.
> Or is my above restatement different from what you are talking about?
You're missing the CLTV timeout clause. It isn't a plain p2wkh, it's a p2wsh
script. Either they splice this in before the timeout, or it times out and
it goes back to one party. In this case, it's no different than the async
concurrent commitment splice in double spend case.
-- Laolu
On Tue, Oct 16, 2018 at 10:16 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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
> the channel initiation and shutdown protocols are written "directly", i.e.
> if the BOLT spec says this must happen before that, we literally write in
> the C code this_function(); that_function();. It would be possible to
> change this architecture with significant difficulty.
>
> 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 specific big businesses you transact with regularly. But I suppose,
> that we will have to see how the network evolves eventually; perhaps the
> goal of decentralization is simply doomed regardless, and Lightning will
> indeed evolve into a set of channels you maintain to specific big
> businesses you regularly work with.
>
>
> > * [`4`:`feerate_per_kw`]
>
> What fee rate is this? IMO we should do commitmentv2 before splicing as
> then
> we can more or less do away with the initiator distinction and have most
> fees be ad hoc.
>
>
> I worry about doing away with initiator distinction, as I worry that an
> initiatee may be forced to pay fees they did not really voluntarily
> consider paying, when they are given funds on a channel initiated by
> someone else in exchange for funds on a separate channel; but this is
> probably a separate topic.
>
> >If you think any of these items is a higher priority than splicing then
> you
> >can simply start working on them! There's no agency that prescribes what
> >should and shouldn't be pursued or developed, just your willingness to
> >write some code.
>
> While true, for me personally I can only devote a limited amount of time
> to coding for Lightning, and thus I must always worry whether my priorities
> are even correct. I find it very common that people want to prioritize
> splicing over AMP or watchtowers, which puzzles me, and I wonder if I am
> incorrect in my prioritization.
>
> > 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 channel. Public derivation can be used,
> along
> > with a script template to do it non-interactively, with the clients
> picking
> > up these deposits, and initiating a splice in as needed.
>
> I am uncertain what this means in particular, but let me try to restate
> what you are talking about in other terms:
>
> 1. Each channel has two public-key-derivation paths (BIP32) to create
> onchain addresses. One for each side of the channel.
> 2. When somebody sends to one of the onchain addresses in the path, their
> client detects this.
> 3. The client initiates a splice-in automatically from this UTXO paying
> to that address into the channel.
>
> It seems to me naively that the above can be done by the client software
> without any modifications to the Lightning Network BOLT protocol, as long
> as the BOLT protocol is capable of supporting *some* splice-in operation,
> i.e. it seems to be something that a client software can implement as a
> feature without requiring a BOLT change. Or is my above restatement
> different from what you are talking about?
>
> How about this restatement?
>
> 1. Each channel has two public-key-derivation paths (BIP32) to create
> onchain addresses. One for each side of the channel.
> 2. The base of the above is actually a combined private-public keypair of
> both sides (e.g. created via MuSig or some other protocol). Thus the
> addresses require cooperation of both parties to spend.
> 3. When somebody sends to one of the onchain addresses in the path, their
> client detects this.
> 4. The client updates the current transaction state, such that the new
> commit transaction has two inputs ( the original channel transaction and
> the new UTXO).
>
> The above seems unsafe without trust in the other peer, as, the other peer
> can simply refuse to create the new commit transaction. Since the address
> requires both parties to spend, the money cannot be spent and there is no
> backoff transaction that can be used. But maybe you can describe some
> mechanism to ensure this, if this is what is meant instead?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181106/76f37b9c/attachment.html>;
📝 Original message:
> 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 specific
big
> businesses you transact with regularly.
I made no reference to any "big businesses", only the utility that arises
when one has multiple channels to a given peer. Consider an easier example:
given the max channel size, I can only ever send 0.16 or so BTC to that
peer. If I have two channels, then I can send 0.32 and so on. Consider the
case post AMP where we maintain the current limit of the number of in flight
HTLCs. If AMP causes most HTLCs to generally be in flight within the
network, then all of a sudden, this "queue" size (outstanding HTLCS in a
commitment) becomes more scarce (assume a global MTU of say 100k sat for
simplicity). This may then promote nodes to open additional channels to
other nodes (1+) in order to accommodate the increased HTLC bandwidth load
due to the sharded multi-path payments.
Independent on bolstering the bandwidth capabilities of your links to other
nodes, you would still want to maintain a diverse set of channels for fault
tolerance, path diversity, and redundancy reasons.
In the splicing case, if only a single in flight splice is permitted, and me
as users wants to keep all their funds in channels, the more channels I
have, the more concurrent on-chain withdraws/deposits I'll be able to
service.
> I worry about doing away with initiator distinction
Can you re-phrase this sentence? I'm having trouble parsing it, thanks.
> which puzzles me, and I wonder if I am incorrect in my prioritization.
Consider that not all work items are created equal, and they have varying
levels of implementation and network wide synchronization. For example, I
think we all consider multi-hop decor to be a high priority. However, it
has the longest and hardest road to deployment as it effectively forces us
to perform a "slow motion hard-fork" within the network. On the other hand,
if lnd wanted to deploy a flavor of non-interactive (no invoice) payments
*today*, we could do that without *any* synchronization at the
implementation of network level, as it's purely an end-to-end change.
> I am uncertain what this means in particular, but let me try to restate
> what you are talking about in other terms:
Thought about it a bit more (like way ago) and this is really no different
than having a donation page where people use public derivation to derive
addresses to deposit directly to your channel. All the Lightning node needs
to do, is recognize that any coins send to these derived addresses should be
immediately spliced into an available channel (doesn't have any other
outstanding splices).
> It seems to me naively that the above can be done by the client software
> without any modifications to the Lightning Network BOLT protocol
Sticking with that prior version yes, this would be able to be seamlessly
included in the async splce proposal. The one requirement is a link-level
protocol that allows both sides to collaboratively create and recognize
these outputs.
> Or is my above restatement different from what you are talking about?
You're missing the CLTV timeout clause. It isn't a plain p2wkh, it's a p2wsh
script. Either they splice this in before the timeout, or it times out and
it goes back to one party. In this case, it's no different than the async
concurrent commitment splice in double spend case.
-- Laolu
On Tue, Oct 16, 2018 at 10:16 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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
> the channel initiation and shutdown protocols are written "directly", i.e.
> if the BOLT spec says this must happen before that, we literally write in
> the C code this_function(); that_function();. It would be possible to
> change this architecture with significant difficulty.
>
> 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 specific big businesses you transact with regularly. But I suppose,
> that we will have to see how the network evolves eventually; perhaps the
> goal of decentralization is simply doomed regardless, and Lightning will
> indeed evolve into a set of channels you maintain to specific big
> businesses you regularly work with.
>
>
> > * [`4`:`feerate_per_kw`]
>
> What fee rate is this? IMO we should do commitmentv2 before splicing as
> then
> we can more or less do away with the initiator distinction and have most
> fees be ad hoc.
>
>
> I worry about doing away with initiator distinction, as I worry that an
> initiatee may be forced to pay fees they did not really voluntarily
> consider paying, when they are given funds on a channel initiated by
> someone else in exchange for funds on a separate channel; but this is
> probably a separate topic.
>
> >If you think any of these items is a higher priority than splicing then
> you
> >can simply start working on them! There's no agency that prescribes what
> >should and shouldn't be pursued or developed, just your willingness to
> >write some code.
>
> While true, for me personally I can only devote a limited amount of time
> to coding for Lightning, and thus I must always worry whether my priorities
> are even correct. I find it very common that people want to prioritize
> splicing over AMP or watchtowers, which puzzles me, and I wonder if I am
> incorrect in my prioritization.
>
> > 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 channel. Public derivation can be used,
> along
> > with a script template to do it non-interactively, with the clients
> picking
> > up these deposits, and initiating a splice in as needed.
>
> I am uncertain what this means in particular, but let me try to restate
> what you are talking about in other terms:
>
> 1. Each channel has two public-key-derivation paths (BIP32) to create
> onchain addresses. One for each side of the channel.
> 2. When somebody sends to one of the onchain addresses in the path, their
> client detects this.
> 3. The client initiates a splice-in automatically from this UTXO paying
> to that address into the channel.
>
> It seems to me naively that the above can be done by the client software
> without any modifications to the Lightning Network BOLT protocol, as long
> as the BOLT protocol is capable of supporting *some* splice-in operation,
> i.e. it seems to be something that a client software can implement as a
> feature without requiring a BOLT change. Or is my above restatement
> different from what you are talking about?
>
> How about this restatement?
>
> 1. Each channel has two public-key-derivation paths (BIP32) to create
> onchain addresses. One for each side of the channel.
> 2. The base of the above is actually a combined private-public keypair of
> both sides (e.g. created via MuSig or some other protocol). Thus the
> addresses require cooperation of both parties to spend.
> 3. When somebody sends to one of the onchain addresses in the path, their
> client detects this.
> 4. The client updates the current transaction state, such that the new
> commit transaction has two inputs ( the original channel transaction and
> the new UTXO).
>
> The above seems unsafe without trust in the other peer, as, the other peer
> can simply refuse to create the new commit transaction. Since the address
> requires both parties to spend, the money cannot be spent and there is no
> backoff transaction that can be used. But maybe you can describe some
> mechanism to ensure this, if this is what is meant instead?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181106/76f37b9c/attachment.html>;