📅 Original date posted:2020-10-12
📝 Original message:
> I suggest adding tlv records in `commitment_signed` to tell our channel >
> peer that we're changing the values of these fields.
I think this fits in nicely with the "parameter re-negotiation" portion of
my
loose Dynamic commitments proposal. Note that in that paradigm, something
like this would be a distinct message, and also only be allowed with a
"clean commitment" (as otherwise what if I reduce the number of slots to a
value that is lower than the number of active slots?). With this, both sides
would be able to propose/accept/deny updates to the flow control parameters
that can be used to either increase the security of a channel, or implement
a sort of "slow start" protocol for any new peers that connect to you.
Similar to congestion window expansion/contraction in TCP, when a new peer
connects to you, you likely don't want to allow them to be able to consume
all the newly allocated bandwidth in an outgoing direction. Instead, you may
want to only allow them to utilize say 10% of the available HTLC bandwidth,
slowly increasing based on successful payments, and drastically
(multiplicatively) decreasing when you encounter very long lived HTLCs, or
an excessive number of failures.
A dynamic HTLC bandwidth allocation mechanism would serve to mitigate
several classes of attacks (supplementing any mitigations by "channel
acceptor" hooks), and also give forwarding nodes more _control_ of exactly
how their allocated bandwidth is utilized by all connected peers. This is
possible to some degree today (by using an implicit value lower than
the negotiated values), but the implicit route doesn't give the other party
any information, and may end up in weird re-send loops (as they _why_ an
HTLC was rejected) wasn't communicated. Also if you end up in a half-sign
state, since we don't have any sort of "unadd", then the channel may end up
borked if the violating party keeps retransmitting the same update upon
reconnection.
> Are there other fields you think would need to become dynamic as well?
One other value that IMO should be dynamic to protect against future
unexpected events is the dust limit. "It Is Known", that this value "doesn't
really change", but we should be able to upgrade _all_ channels on the fly
if it does for w/e reason.
-- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/1700eb6d/attachment.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 13:00:58
in reply to nevent1q…ejm6
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 13:00:58Event JSON
{
"id": "729bfbcf507aed6f7f78cba733329075e80a174b4f9938cb5d89980f78c83999",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315658,
"kind": 1,
"tags": [
[
"e",
"bf5d675863f97a951d35eeee3ef3828dfc349552a8c3471bf6b8f80c10432a22",
"",
"root"
],
[
"e",
"c944e1dadd366c8b1bfc59c4b7445934973f7e47adc59efda5e77277e46dc4f9",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2020-10-12\n📝 Original message:\n\u003e I suggest adding tlv records in `commitment_signed` to tell our channel \u003e\n\u003e peer that we're changing the values of these fields.\n\nI think this fits in nicely with the \"parameter re-negotiation\" portion of\nmy\nloose Dynamic commitments proposal. Note that in that paradigm, something\nlike this would be a distinct message, and also only be allowed with a\n\"clean commitment\" (as otherwise what if I reduce the number of slots to a\nvalue that is lower than the number of active slots?). With this, both sides\nwould be able to propose/accept/deny updates to the flow control parameters\nthat can be used to either increase the security of a channel, or implement\na sort of \"slow start\" protocol for any new peers that connect to you.\n\nSimilar to congestion window expansion/contraction in TCP, when a new peer\nconnects to you, you likely don't want to allow them to be able to consume\nall the newly allocated bandwidth in an outgoing direction. Instead, you may\nwant to only allow them to utilize say 10% of the available HTLC bandwidth,\nslowly increasing based on successful payments, and drastically\n(multiplicatively) decreasing when you encounter very long lived HTLCs, or\nan excessive number of failures.\n\nA dynamic HTLC bandwidth allocation mechanism would serve to mitigate\nseveral classes of attacks (supplementing any mitigations by \"channel\nacceptor\" hooks), and also give forwarding nodes more _control_ of exactly\nhow their allocated bandwidth is utilized by all connected peers. This is\npossible to some degree today (by using an implicit value lower than\nthe negotiated values), but the implicit route doesn't give the other party\nany information, and may end up in weird re-send loops (as they _why_ an\nHTLC was rejected) wasn't communicated. Also if you end up in a half-sign\nstate, since we don't have any sort of \"unadd\", then the channel may end up\nborked if the violating party keeps retransmitting the same update upon\nreconnection.\n\n\u003e Are there other fields you think would need to become dynamic as well?\n\nOne other value that IMO should be dynamic to protect against future\nunexpected events is the dust limit. \"It Is Known\", that this value \"doesn't\nreally change\", but we should be able to upgrade _all_ channels on the fly\nif it does for w/e reason.\n\n-- Laolu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/1700eb6d/attachment.html\u003e",
"sig": "b79a4d1acd918c05ff2d85291db9f590ad0b2524f019bb2dc5df922d98052c474b5efc209401e4d42134ffe3fc29c8c8abd9e7d885ed8bb9b81dc6a1539e1e75"
}