rich1.0npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddhttps://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddnjumphttps://nostr.ae📅 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>