{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-10-05\n📝 Original message:\nGood evening list,\n\nRecent discussions around channel jamming [1] have highlighted again the\nneed to think twice when\nconfiguring your channels parameters. There are currently parameters that\nare set once at channel\ncreation that would benefit a lot from being configurable throughout the\nlifetime of the channel\nto avoid closing channels when we just want to reconfigure them:\n\n* max_htlc_value_in_flight_msat\n* max_accepted_htlcs\n* htlc_minimum_msat\n* htlc_maximum_msat\n\nNodes can currently unilaterally udpate these by applying forwarding\nheuristics, but it would be\nbetter to tell our peer about the limits we want to put in place (otherwise\nwe're wasting a whole\ncycle of add/commit/revoke/fail messages for no good reason).\n\nI suggest adding tlv records in `commitment_signed` to tell our channel\npeer that we're changing\nthe values of these fields.\n\nIs someone opposed to that?\nAre there other fields you think would need to become dynamic as well?\nDo you think that needs a new message instead of using extensions of\n`commitment_signed`?\n\nCheers,\nBastien\n\n[1] https://twitter.com/joostjgr/status/1308414364911841281\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/f98befeb/attachment.html\u003e"}