> 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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
