Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-13 📝 Original message: Hi, For a long time I've ...
📅 Original date posted:2023-02-13
📝 Original message:
Hi,
For a long time I've held the expectation that eventually payers on the
lightning network will become very strict about node performance. That they
will require a routing node to operate flawlessly or else apply a hefty
penalty such as completely avoiding the node for an extended period of time
- multiple weeks. The consequence of this is that routing nodes would need
to manage their liquidity meticulously because every failure potentially
has a large impact on future routing revenue.
I think movement in this direction is important to guarantee
competitiveness with centralised payment systems and their (at least
theoretical) ability to process a payment in the blink of an eye. A
lightning wallet trying multiple paths to find one that works doesn't help
with this.
A common argument against strict penalisation is that it would lead to less
efficient use of capital. Routing nodes would need to maintain pools of
liquidity to guarantee successes all the time. My opinion on this is that
lightning is already enormously capital efficient at scale and that it is
worth sacrificing a slight part of that efficiency to also achieve the
lowest possible latency.
This brings me to the actual subject of this post. Assuming strict
penalisation is good, it may still not be ideal to flip the switch from one
day to the other. Routing nodes may not offer the required level of service
yet, causing senders to end up with no nodes to choose from.
One option is to gradually increase the strength of the penalties, so that
routing nodes are given time to adapt to the new standards. This does
require everyone to move along and leaves no space for cheap routing nodes
with less leeway in terms of liquidity.
Therefore I am proposing another way to go about it: extend the
`channel_update` field `channel_flags` with a new bit that the sender can
use to signal `highly_available`.
It's then up to payers to decide how to interpret this flag. One way could
be to prefer `highly_available` channels during pathfinding. But if the
routing node then returns a failure, a much stronger than normal penalty
will be applied. For routing nodes this creates an opportunity to attract
more traffic by marking some channels as `highly_available`, but it also
comes with the responsibility to deliver.
Without shadow channels, it is impossible to guarantee liquidity up to the
channel capacity. It might make sense for senders to only assume high
availability for amounts up to `htlc_maximum_msat`.
A variation on this scheme that requires no extension of `channel_update`
is to signal availability implicitly through routing fees. So the more
expensive a channel is, the stronger the penalty that is applied on failure
will be. It seems less ideal though, because it could disincentivize cheap
but reliable channels on high traffic links.
The effort required to implement some form of a `highly_available` flag
seem limited and it may help to get payment success rates up. Interested to
hear your thoughts.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230213/adf0c913/attachment.html>;
📝 Original message:
Hi,
For a long time I've held the expectation that eventually payers on the
lightning network will become very strict about node performance. That they
will require a routing node to operate flawlessly or else apply a hefty
penalty such as completely avoiding the node for an extended period of time
- multiple weeks. The consequence of this is that routing nodes would need
to manage their liquidity meticulously because every failure potentially
has a large impact on future routing revenue.
I think movement in this direction is important to guarantee
competitiveness with centralised payment systems and their (at least
theoretical) ability to process a payment in the blink of an eye. A
lightning wallet trying multiple paths to find one that works doesn't help
with this.
A common argument against strict penalisation is that it would lead to less
efficient use of capital. Routing nodes would need to maintain pools of
liquidity to guarantee successes all the time. My opinion on this is that
lightning is already enormously capital efficient at scale and that it is
worth sacrificing a slight part of that efficiency to also achieve the
lowest possible latency.
This brings me to the actual subject of this post. Assuming strict
penalisation is good, it may still not be ideal to flip the switch from one
day to the other. Routing nodes may not offer the required level of service
yet, causing senders to end up with no nodes to choose from.
One option is to gradually increase the strength of the penalties, so that
routing nodes are given time to adapt to the new standards. This does
require everyone to move along and leaves no space for cheap routing nodes
with less leeway in terms of liquidity.
Therefore I am proposing another way to go about it: extend the
`channel_update` field `channel_flags` with a new bit that the sender can
use to signal `highly_available`.
It's then up to payers to decide how to interpret this flag. One way could
be to prefer `highly_available` channels during pathfinding. But if the
routing node then returns a failure, a much stronger than normal penalty
will be applied. For routing nodes this creates an opportunity to attract
more traffic by marking some channels as `highly_available`, but it also
comes with the responsibility to deliver.
Without shadow channels, it is impossible to guarantee liquidity up to the
channel capacity. It might make sense for senders to only assume high
availability for amounts up to `htlc_maximum_msat`.
A variation on this scheme that requires no extension of `channel_update`
is to signal availability implicitly through routing fees. So the more
expensive a channel is, the stronger the penalty that is applied on failure
will be. It seems less ideal though, because it could disincentivize cheap
but reliable channels on high traffic links.
The effort required to implement some form of a `highly_available` flag
seem limited and it may help to get payment success rates up. Interested to
hear your thoughts.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230213/adf0c913/attachment.html>;