📅 Original date posted:2020-10-05
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201005/f98befeb/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:00:55
in reply to nevent1q…2d5g
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:00:55Event JSON
{
"id": "93ce492f26c7debce4cea90bd0ecda5180961ac1900266a6470926e9b57d2d7b",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315655,
"kind": 1,
"tags": [
[
"e",
"bf5d675863f97a951d35eeee3ef3828dfc349552a8c3471bf6b8f80c10432a22",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 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",
"sig": "de217e247f59ff0c57d2bd5aac433cdd7107d0a3b9c0020a617c07d11653f7d69d2b69976b6c807ecfc7726190654f4b9f796ec732e42ae166b2b438007641c0"
}