{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-10-06\n📝 Original message:\nHello Bastien,\n\nAs a first note , I was thinking dynamic policy adjustment would be covered\nby the dynamic commitment mechanism proposed by Laolu as it presents the\nsame trade-offs, you need to stop channel HTLC processing before upgrading,\notherwise it might falsify your whole in-flight HTLC accounting.\n\n\u003e Recent discussions around channel jamming [1] have highlighted again the\n\u003e need to think twice when\n\u003e configuring your channels parameters.\n\nI'm still dubious that straighter channel parameters are the best solution\nto solve channel jamming. As a routing node evaluating a HTLC, I think the\nquestion you're trying to answer is : \"Is this a _honest_ HTLC to relay ?\",\nwhere honest is defined both as paying more fees that the liquidity lock\nand with high odds of a positive settlement, otherwise you won't get paid.\n\nThe first predicate is easy to evaluate, just verify that the HTLC is\npaying more as an incoming packet that you have to send forward.\n\nOn the other hand, the second predicate is hard to evaluate. A first lead\nof a solution is to evaluate the packet forwarder instead of the packet\nitself. You may have a web-of-trust/reputation system with a one-level rank\nof trust which would be enforced at the channel opening layer, i.e don't\nopen/accept channels with random nodes. A less constraining version is\nstill a reputation system but where you statically attribute a HTLC\nforwarding policy based on counterparty reputation (~today).\n\nThe more evolved reputation system version you implicitly seem to argue for\nis adapting the forwarding policy based on counterparty past behavior, e.g\nlike relaxing channel parameters for a counterparty upstreaming a lot of\nsuccessful HTLCs. IMO, this is still presenting hurdles.\n\nIf you have 1 BTC of outgoing bandwidth but your counterparty is enforcing\na `max_htlc_value_in_flight_msat` of 0.5 BTC, it means you have a\n\"sleeping\" outgoing liquidity. Rationally, you should only open a channel\nwith a capacity somehow equivalent to what is authorized by your\ncounterparty relay policy.\n\nA lesson would be to negotiate first a policy then an opening, as of today\nthey're still bundled in one message flow. I don't think you can reduce the\ncapacity once you learn acceptor policy ? Don't overstake liquidity more\nthan you can actually gain from.\n\nThat said, if you have a dynamic policy model, at policy relaxation, you\nneed to increase channel capacity to profit from relaxation, let's say\nthrough some kind of splice-in. But now you have on-chain fees at each\npolicy/liquidity adjustment.\n\nUnder a dynamic policy model based on accumulated reputation, it sounds\nlike there is some kind of trade-off between useless off-chain liquidity\nand on-chain fees.\n\nInstead of relying on reputation, the other alternative is just to have an\nupfront payment system, where a relay node doesn't have to account for a\nHTLC issuer reputation to decide acceptance and can just forward a HTLC as\nlong it paid enough. More, I think it's better to mitigate jamming with a\nfees-based system than a web-of-trust one, less burden on network newcomers.\n\nThis doesn't prevent hybrid models where you might reward your good\nbehaving peers with a discount on your upfront payment policy.\n\nWhat's your opinion ?\n\nAntoine\n\nLe lun. 5 oct. 2020 à 07:54, Bastien TEINTURIER via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e Good evening list,\n\u003e\n\u003e Recent discussions around channel jamming [1] have highlighted again the\n\u003e need to think twice when\n\u003e configuring your channels parameters. There are currently parameters that\n\u003e are set once at channel\n\u003e creation that would benefit a lot from being configurable throughout the\n\u003e lifetime of the channel\n\u003e to avoid closing channels when we just want to reconfigure them:\n\u003e\n\u003e * max_htlc_value_in_flight_msat\n\u003e * max_accepted_htlcs\n\u003e * htlc_minimum_msat\n\u003e * htlc_maximum_msat\n\u003e\n\u003e Nodes can currently unilaterally udpate these by applying forwarding\n\u003e heuristics, but it would be\n\u003e better to tell our peer about the limits we want to put in place\n\u003e (otherwise we're wasting a whole\n\u003e cycle of add/commit/revoke/fail messages for no good reason).\n\u003e\n\u003e I suggest adding tlv records in `commitment_signed` to tell our channel\n\u003e peer that we're changing\n\u003e the values of these fields.\n\u003e\n\u003e Is someone opposed to that?\n\u003e Are there other fields you think would need to become dynamic as well?\n\u003e Do you think that needs a new message instead of using extensions of\n\u003e `commitment_signed`?\n\u003e\n\u003e Cheers,\n\u003e Bastien\n\u003e\n\u003e [1] https://twitter.com/joostjgr/status/1308414364911841281\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201006/8dc749f6/attachment.html\u003e"}