Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-06 📝 Original message: Hello Bastien, As a first ...
📅 Original date posted:2020-10-06
📝 Original message:
Hello Bastien,
As a first note , I was thinking dynamic policy adjustment would be covered
by the dynamic commitment mechanism proposed by Laolu as it presents the
same trade-offs, you need to stop channel HTLC processing before upgrading,
otherwise it might falsify your whole in-flight HTLC accounting.
> Recent discussions around channel jamming [1] have highlighted again the
> need to think twice when
> configuring your channels parameters.
I'm still dubious that straighter channel parameters are the best solution
to solve channel jamming. As a routing node evaluating a HTLC, I think the
question you're trying to answer is : "Is this a _honest_ HTLC to relay ?",
where honest is defined both as paying more fees that the liquidity lock
and with high odds of a positive settlement, otherwise you won't get paid.
The first predicate is easy to evaluate, just verify that the HTLC is
paying more as an incoming packet that you have to send forward.
On the other hand, the second predicate is hard to evaluate. A first lead
of a solution is to evaluate the packet forwarder instead of the packet
itself. You may have a web-of-trust/reputation system with a one-level rank
of trust which would be enforced at the channel opening layer, i.e don't
open/accept channels with random nodes. A less constraining version is
still a reputation system but where you statically attribute a HTLC
forwarding policy based on counterparty reputation (~today).
The more evolved reputation system version you implicitly seem to argue for
is adapting the forwarding policy based on counterparty past behavior, e.g
like relaxing channel parameters for a counterparty upstreaming a lot of
successful HTLCs. IMO, this is still presenting hurdles.
If you have 1 BTC of outgoing bandwidth but your counterparty is enforcing
a `max_htlc_value_in_flight_msat` of 0.5 BTC, it means you have a
"sleeping" outgoing liquidity. Rationally, you should only open a channel
with a capacity somehow equivalent to what is authorized by your
counterparty relay policy.
A lesson would be to negotiate first a policy then an opening, as of today
they're still bundled in one message flow. I don't think you can reduce the
capacity once you learn acceptor policy ? Don't overstake liquidity more
than you can actually gain from.
That said, if you have a dynamic policy model, at policy relaxation, you
need to increase channel capacity to profit from relaxation, let's say
through some kind of splice-in. But now you have on-chain fees at each
policy/liquidity adjustment.
Under a dynamic policy model based on accumulated reputation, it sounds
like there is some kind of trade-off between useless off-chain liquidity
and on-chain fees.
Instead of relying on reputation, the other alternative is just to have an
upfront payment system, where a relay node doesn't have to account for a
HTLC issuer reputation to decide acceptance and can just forward a HTLC as
long it paid enough. More, I think it's better to mitigate jamming with a
fees-based system than a web-of-trust one, less burden on network newcomers.
This doesn't prevent hybrid models where you might reward your good
behaving peers with a discount on your upfront payment policy.
What's your opinion ?
Antoine
Le lun. 5 oct. 2020 à 07:54, Bastien TEINTURIER via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Good evening list,
>
> Recent discussions around channel jamming [1] have highlighted again the
> need to think twice when
> configuring your channels parameters. There are currently parameters that
> are set once at channel
> creation that would benefit a lot from being configurable throughout the
> lifetime of the channel
> to avoid closing channels when we just want to reconfigure them:
>
> * max_htlc_value_in_flight_msat
> * max_accepted_htlcs
> * htlc_minimum_msat
> * htlc_maximum_msat
>
> Nodes can currently unilaterally udpate these by applying forwarding
> heuristics, but it would be
> better to tell our peer about the limits we want to put in place
> (otherwise we're wasting a whole
> cycle of add/commit/revoke/fail messages for no good reason).
>
> I suggest adding tlv records in `commitment_signed` to tell our channel
> peer that we're changing
> the values of these fields.
>
> Is someone opposed to that?
> Are there other fields you think would need to become dynamic as well?
> Do you think that needs a new message instead of using extensions of
> `commitment_signed`?
>
> Cheers,
> Bastien
>
> [1] https://twitter.com/joostjgr/status/1308414364911841281
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201006/8dc749f6/attachment.html>;
📝 Original message:
Hello Bastien,
As a first note , I was thinking dynamic policy adjustment would be covered
by the dynamic commitment mechanism proposed by Laolu as it presents the
same trade-offs, you need to stop channel HTLC processing before upgrading,
otherwise it might falsify your whole in-flight HTLC accounting.
> Recent discussions around channel jamming [1] have highlighted again the
> need to think twice when
> configuring your channels parameters.
I'm still dubious that straighter channel parameters are the best solution
to solve channel jamming. As a routing node evaluating a HTLC, I think the
question you're trying to answer is : "Is this a _honest_ HTLC to relay ?",
where honest is defined both as paying more fees that the liquidity lock
and with high odds of a positive settlement, otherwise you won't get paid.
The first predicate is easy to evaluate, just verify that the HTLC is
paying more as an incoming packet that you have to send forward.
On the other hand, the second predicate is hard to evaluate. A first lead
of a solution is to evaluate the packet forwarder instead of the packet
itself. You may have a web-of-trust/reputation system with a one-level rank
of trust which would be enforced at the channel opening layer, i.e don't
open/accept channels with random nodes. A less constraining version is
still a reputation system but where you statically attribute a HTLC
forwarding policy based on counterparty reputation (~today).
The more evolved reputation system version you implicitly seem to argue for
is adapting the forwarding policy based on counterparty past behavior, e.g
like relaxing channel parameters for a counterparty upstreaming a lot of
successful HTLCs. IMO, this is still presenting hurdles.
If you have 1 BTC of outgoing bandwidth but your counterparty is enforcing
a `max_htlc_value_in_flight_msat` of 0.5 BTC, it means you have a
"sleeping" outgoing liquidity. Rationally, you should only open a channel
with a capacity somehow equivalent to what is authorized by your
counterparty relay policy.
A lesson would be to negotiate first a policy then an opening, as of today
they're still bundled in one message flow. I don't think you can reduce the
capacity once you learn acceptor policy ? Don't overstake liquidity more
than you can actually gain from.
That said, if you have a dynamic policy model, at policy relaxation, you
need to increase channel capacity to profit from relaxation, let's say
through some kind of splice-in. But now you have on-chain fees at each
policy/liquidity adjustment.
Under a dynamic policy model based on accumulated reputation, it sounds
like there is some kind of trade-off between useless off-chain liquidity
and on-chain fees.
Instead of relying on reputation, the other alternative is just to have an
upfront payment system, where a relay node doesn't have to account for a
HTLC issuer reputation to decide acceptance and can just forward a HTLC as
long it paid enough. More, I think it's better to mitigate jamming with a
fees-based system than a web-of-trust one, less burden on network newcomers.
This doesn't prevent hybrid models where you might reward your good
behaving peers with a discount on your upfront payment policy.
What's your opinion ?
Antoine
Le lun. 5 oct. 2020 à 07:54, Bastien TEINTURIER via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :
> Good evening list,
>
> Recent discussions around channel jamming [1] have highlighted again the
> need to think twice when
> configuring your channels parameters. There are currently parameters that
> are set once at channel
> creation that would benefit a lot from being configurable throughout the
> lifetime of the channel
> to avoid closing channels when we just want to reconfigure them:
>
> * max_htlc_value_in_flight_msat
> * max_accepted_htlcs
> * htlc_minimum_msat
> * htlc_maximum_msat
>
> Nodes can currently unilaterally udpate these by applying forwarding
> heuristics, but it would be
> better to tell our peer about the limits we want to put in place
> (otherwise we're wasting a whole
> cycle of add/commit/revoke/fail messages for no good reason).
>
> I suggest adding tlv records in `commitment_signed` to tell our channel
> peer that we're changing
> the values of these fields.
>
> Is someone opposed to that?
> Are there other fields you think would need to become dynamic as well?
> Do you think that needs a new message instead of using extensions of
> `commitment_signed`?
>
> Cheers,
> Bastien
>
> [1] https://twitter.com/joostjgr/status/1308414364911841281
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201006/8dc749f6/attachment.html>;