Re: [Lightning-dev] Making (some) channel limits dynamic
Hey laolu, I think this fits in nicely with the "parameter re-negotiation" portion of > my > loose Dynamic commitments proposal. Yes, maybe it's better to not offer two mechanisms and wait for dynamic commitments to offer that flexibility. 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. Exactly, that's the kind of heuristic I had in mind. Peers need to slowly build trust before you give them access to more resources. 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 Agreed, it's easy to implement locally but it's not going to be very nice to your peer, who has no way of knowing why you're rejecting HTLCs and may end up closing the channel because it sees weird behavior. That's why we need to offer an explicit re-negotiation of these parameters, let's keep this use-case in mind when designing dynamic commitments! Cheers, Bastien Le lun. 12 oct. 2020 à 20:59, Olaoluwa Osuntokun a écrit : > > > 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
Re: [Lightning-dev] Making (some) channel limits dynamic
> 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
Re: [Lightning-dev] Making (some) channel limits dynamic
Good morning, For instance, Tor is basically two-layer: there is a lower-level TCP/IP > layer where packets are sent out to specific nodes on the network and this > layer is completely open about where the packet should go, but there is a > higher layer where onion routing between nodes is used. > We could imitate this, with HTLC packets that openly show the next > destination node, but once all parts reach the destination node, it decodes > and turns out to be an onion to be sent to the next destination node, and > the current destination node is just another forwarder. That's an interesting comment, it may be worth exploring. IIUC you're suggesting that payments may look like this: * Alice wants to reach Dave by going through Bob and Carol * An onion encodes the route Alice -> Bob -> Carol -> Dave * When Bob receives that onion and discovers that Carol is the next node, he finds a route to Carol and sends it along that route, but it's not an onion, it's "clear-text" routing * When Carol receives that message, she unwraps the Alice -> Bob -> Carol -> Dave onion to discover that Dave is the next hop and applies the same steps as Bob It looks a lot like Trampoline, but Trampoline does onion routing between intermediate nodes. Your proposal would replace that with a potentially more efficient but less private routing scheme. As long as the Trampoline route does use onion routing, it could make sense... For your proposal, how sure is the receiver that the input end of the > trampoline node is "nearer" to the payer than itself? Invoices to the rescue! Since lightning payments are invoice-based, recipients would add to the invoice a few nodes that are close to them (or a partial route, which would probably be better for privacy). Thanks, Bastien Le dim. 11 oct. 2020 à 10:50, ZmnSCPxj a écrit : > Good morning t-bast, > > > Hey Zman, > > > > > raising the minimum payment size is another headache > > > > It's true that it may (depending on the algorithm) lower the success > rate of MPP-split. > > But it's already a parameter that node operators can configure at will > (at channel creation time), > > so IMO it's a complexity we have to deal with anyway. Making it dynamic > shouldn't have a high > > impact on MPP algorithms (apart from failures while `channel_update`s > are propagating). > > Right, it should not have much impact. > > For the most part, when considering the possibility of splicing in the > future, we should consider that such parameters must be made changeable > largely. > > > > > > To be fully honest, my (maybe unpopular) opinion about MPP is that it's > not necessary on the > > network's backbone, only at its edges. Once the network matures, I > expect channels between > > "serious" routing nodes to be way bigger than the size of individual > payments. The only places > > where there may be small or almost-empty channels are between end-users > (wallets) and > > routing nodes. > > If something like Trampoline were to be implemented, MPP would only be > needed to reach a > > first routing node (short route), that routing node would aggregate the > parts and forward as a > > single HTLC to the next routing node. It would be split again once it > reaches the other edge > > of the network (for a short route as well). In a network like this, the > MPP routes would only have > > to be computed on a small subset of the network, which makes brute-force > algorithms completely > > reasonable and the success rate higher. > > This makes me wonder if we really need the onions-per-channel model we > currently use. > > For instance, Tor is basically two-layer: there is a lower-level TCP/IP > layer where packets are sent out to specific nodes on the network and this > layer is completely open about where the packet should go, but there is a > higher layer where onion routing between nodes is used. > > We could imitate this, with HTLC packets that openly show the next > destination node, but once all parts reach the destination node, it decodes > and turns out to be an onion to be sent to the next destination node, and > the current destination node is just another forwarder. > > HTLC packets could be split arbitrarily, and later nodes could potentially > merge with the lower CLTV used in subsequent hops. > > Or not, *shrug*. > It has the bad problem of being more expensive on average than purely > source-based routing, and probably having worse payment latency. > > > For your proposal, how sure is the receiver that the input end of the > trampoline node is "nearer" to the payer than itself? > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Making (some) channel limits dynamic
Good morning t-bast, > Hey Zman, > > > raising the minimum payment size is another headache > > It's true that it may (depending on the algorithm) lower the success rate of > MPP-split. > But it's already a parameter that node operators can configure at will (at > channel creation time), > so IMO it's a complexity we have to deal with anyway. Making it dynamic > shouldn't have a high > impact on MPP algorithms (apart from failures while `channel_update`s are > propagating). Right, it should not have much impact. For the most part, when considering the possibility of splicing in the future, we should consider that such parameters must be made changeable largely. > > To be fully honest, my (maybe unpopular) opinion about MPP is that it's not > necessary on the > network's backbone, only at its edges. Once the network matures, I expect > channels between > "serious" routing nodes to be way bigger than the size of individual > payments. The only places > where there may be small or almost-empty channels are between end-users > (wallets) and > routing nodes. > If something like Trampoline were to be implemented, MPP would only be needed > to reach a > first routing node (short route), that routing node would aggregate the parts > and forward as a > single HTLC to the next routing node. It would be split again once it reaches > the other edge > of the network (for a short route as well). In a network like this, the MPP > routes would only have > to be computed on a small subset of the network, which makes brute-force > algorithms completely > reasonable and the success rate higher. This makes me wonder if we really need the onions-per-channel model we currently use. For instance, Tor is basically two-layer: there is a lower-level TCP/IP layer where packets are sent out to specific nodes on the network and this layer is completely open about where the packet should go, but there is a higher layer where onion routing between nodes is used. We could imitate this, with HTLC packets that openly show the next destination node, but once all parts reach the destination node, it decodes and turns out to be an onion to be sent to the next destination node, and the current destination node is just another forwarder. HTLC packets could be split arbitrarily, and later nodes could potentially merge with the lower CLTV used in subsequent hops. Or not, *shrug*. It has the bad problem of being more expensive on average than purely source-based routing, and probably having worse payment latency. For your proposal, how sure is the receiver that the input end of the trampoline node is "nearer" to the payer than itself? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Making (some) channel limits dynamic
Hey Zman, raising the minimum payment size is another headache > It's true that it may (depending on the algorithm) lower the success rate of MPP-split. But it's already a parameter that node operators can configure at will (at channel creation time), so IMO it's a complexity we have to deal with anyway. Making it dynamic shouldn't have a high impact on MPP algorithms (apart from failures while `channel_update`s are propagating). To be fully honest, my (maybe unpopular) opinion about MPP is that it's not necessary on the network's backbone, only at its edges. Once the network matures, I expect channels between "serious" routing nodes to be way bigger than the size of individual payments. The only places where there may be small or almost-empty channels are between end-users (wallets) and routing nodes. If something like Trampoline were to be implemented, MPP would only be needed to reach a first routing node (short route), that routing node would aggregate the parts and forward as a single HTLC to the next routing node. It would be split again once it reaches the other edge of the network (for a short route as well). In a network like this, the MPP routes would only have to be computed on a small subset of the network, which makes brute-force algorithms completely reasonable and the success rate higher. This is an interesting fork of the discussion, but I don't think it's a good reason to prevent these parameters from being updated on live channels, what do you think? Bastien Le jeu. 8 oct. 2020 à 22:05, ZmnSCPxj a écrit : > Good morning t-bast, > > > Please forget about channel jamming, upfront fees et al and simply > consider the parameters I'm > > mentioning. It feels to me that these are by nature dynamic channel > parameters (some of them are > > even present in `channel_update`, but no-one updates them yet because > direct peers don't take the > > update into account anyway). I'd like to raise `htlc_minimum_msat` on > some big channels because > > I'd like these channels to be used only for big-ish payments. Today I > can't, I have to close that > > channel and open a new one for such a trivial configuration update, > which is sad. > > At the risk of once more derailing the conversation: from the MPP > trenches, raising the minimum payment size is another headache. > The general assumption with MPP is that smaller amounts are more likely to > get through, but if anyone is making a significant bump up in > `htlc_minimum_msat`, that assumption is upended and we have to reconsider > if we may actually want to merge multiple failing splits into one, as well > as considering asymmetric splits (in particular asymmetric presplits) > because maybe the smaller splits will be unable to pass through the bigger > channels but the bigger-side split *might*. > > On the other hand: one can consider that the use of big payments as an > aggregation. > For example: a forwarding node might support smaller `htlc_minimum_msat`, > then after making multiple such forwards, find that a channel is now > heavily balanced towards one side or another. > It can then make a single large rebalance via one of the > high-`htlc_minimum_msat` channels t-bast is running. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Making (some) channel limits dynamic
Good morning t-bast, > Please forget about channel jamming, upfront fees et al and simply consider > the parameters I'm > mentioning. It feels to me that these are by nature dynamic channel > parameters (some of them are > even present in `channel_update`, but no-one updates them yet because direct > peers don't take the > update into account anyway). I'd like to raise `htlc_minimum_msat` on some > big channels because > I'd like these channels to be used only for big-ish payments. Today I can't, > I have to close that > channel and open a new one for such a trivial configuration update, which is > sad. At the risk of once more derailing the conversation: from the MPP trenches, raising the minimum payment size is another headache. The general assumption with MPP is that smaller amounts are more likely to get through, but if anyone is making a significant bump up in `htlc_minimum_msat`, that assumption is upended and we have to reconsider if we may actually want to merge multiple failing splits into one, as well as considering asymmetric splits (in particular asymmetric presplits) because maybe the smaller splits will be unable to pass through the bigger channels but the bigger-side split *might*. On the other hand: one can consider that the use of big payments as an aggregation. For example: a forwarding node might support smaller `htlc_minimum_msat`, then after making multiple such forwards, find that a channel is now heavily balanced towards one side or another. It can then make a single large rebalance via one of the high-`htlc_minimum_msat` channels t-bast is running. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Making (some) channel limits dynamic
> There is no need to stop the channel's operations while you're updating these parameters, since they can be updated unilaterally anyway I think it's just how you defne channel's operations, either emptying out all pending HTLCs or more a `update_fee` alike semantic. You're right that the latter should be good enough for the set of parameters you're proposing. A lightweight `update_policy` doesn't sound to bear difficulty at first sight. Le jeu. 8 oct. 2020 à 08:23, Bastien TEINTURIER a écrit : > Good morning Antoine and Zman, > > Thanks for your answers! > > I was thinking dynamic policy adjustment would be covered by the dynamic >> commitment mechanism proposed by Laolu > > > I didn't mention this as I think we still have a long-ish way to go before > dynamic commitments > are spec-ed, implemented and deployed, and I think the parameters I'm > interested in don't require > that complexity to be updated. > > Please forget about channel jamming, upfront fees et al and simply > consider the parameters I'm > mentioning. It feels to me that these are by nature dynamic channel > parameters (some of them are > even present in `channel_update`, but no-one updates them yet because > direct peers don't take the > update into account anyway). I'd like to raise `htlc_minimum_msat` on some > big channels because > I'd like these channels to be used only for big-ish payments. Today I > can't, I have to close that > channel and open a new one for such a trivial configuration update, which > is sad. > > There is no need to stop the channel's operations while you're updating > these parameters, since > they can be updated unilaterally anyway. The only downside is that if you > make your policy stricter, > your peer may send you some HTLCs that you will immediately fail > afterwards; it's only a minor > inconvenience that won't trigger a channel closure. > > I'd like to know if other implementations than eclair have specificities > that would make this > feature particularly hard to implement or undesirable. > > Thanks, > Bastien > > Le mar. 6 oct. 2020 à 18:43, ZmnSCPxj a écrit : > >> Good morning Antoine, and Bastien, >> >> >> > Instead of relying on reputation, the other alternative is just to have >> an upfront payment system, where a relay node doesn't have to account for a >> HTLC issuer reputation to decide acceptance and can just forward a HTLC as >> long it paid enough. More, I think it's better to mitigate jamming with a >> fees-based system than a web-of-trust one, less burden on network newcomers. >> >> Let us consider some of the complications here. >> >> A newcomer wants to make an outgoing payment. >> Speculatively, it connects to some existing nodes based on some policy. >> >> Now, since forwarding is upfront, the newcomer fears that the node it >> connected to might not even bother forwarding the payment, and instead just >> fail it and claim the upfront fees. >> >> In particular: how would the newcomer offer upfront fees to a node it is >> not directly channeled with? >> In order to do that, we would have to offer the upfront fees for that >> node, to the node we *are* channeled with, so it can forward this as well. >> >> * We can give the upfront fee outright to the first hop, and trust that >> if it forwards, it will also forward the upfront fee for the next hop. >> * The first hop would then prefer to just fail the HTLC then and there >> and steal all the upfront fees. >> * After all, the offerrer is a newcomer, and might be the sybil of a >> hacker that is trying to tie up its liquidity. >> The first hop would (1) avoid this risk and (2) earn more upfront >> fees because it does not forward those fees to later hops. >> * This is arguably custodial and not your keys not your coins applies. >> Thus, it returns us back to tr\*st anyway. >> * We can require that the first hop prove *where* along the route errored. >> If it provably failed at a later hop, then the first hop can claim more >> as upfront fees, since it will forward the upfront fees to the later hop as >> well. >> * This has to be enforcable onchain in case the channel gets dropped >> onchain. >> Is there a proposal SCRIPT which can enforce this? >> * If not enforcable onchain, then there may be onchain shenanigans >> possible and thus this solution might introduce an attack vector even as it >> fixes another. >> * On the other hand, sub-satoshi amounts are not enforcable onchain >> too, and nobody cares, so... >> >> On the other hand, a web-of-tr\*st might not be *that* bad. >> >> One can say that "tr\*st is risk", and consider that the size and age of >> a channel to a peer represents your tr\*st that that peer will behave >> correctly for fast and timely resolution of payments. >> And anyone can look at the blockchain and the network gossip to get an >> idea of who is generally considered tr\*stworthy, and since that >> information is backed by Bitcoins locked in channels, this is reasonably >> hard
Re: [Lightning-dev] Making (some) channel limits dynamic
Good morning Antoine and Zman, Thanks for your answers! I was thinking dynamic policy adjustment would be covered by the dynamic > commitment mechanism proposed by Laolu I didn't mention this as I think we still have a long-ish way to go before dynamic commitments are spec-ed, implemented and deployed, and I think the parameters I'm interested in don't require that complexity to be updated. Please forget about channel jamming, upfront fees et al and simply consider the parameters I'm mentioning. It feels to me that these are by nature dynamic channel parameters (some of them are even present in `channel_update`, but no-one updates them yet because direct peers don't take the update into account anyway). I'd like to raise `htlc_minimum_msat` on some big channels because I'd like these channels to be used only for big-ish payments. Today I can't, I have to close that channel and open a new one for such a trivial configuration update, which is sad. There is no need to stop the channel's operations while you're updating these parameters, since they can be updated unilaterally anyway. The only downside is that if you make your policy stricter, your peer may send you some HTLCs that you will immediately fail afterwards; it's only a minor inconvenience that won't trigger a channel closure. I'd like to know if other implementations than eclair have specificities that would make this feature particularly hard to implement or undesirable. Thanks, Bastien Le mar. 6 oct. 2020 à 18:43, ZmnSCPxj a écrit : > Good morning Antoine, and Bastien, > > > > Instead of relying on reputation, the other alternative is just to have > an upfront payment system, where a relay node doesn't have to account for a > HTLC issuer reputation to decide acceptance and can just forward a HTLC as > long it paid enough. More, I think it's better to mitigate jamming with a > fees-based system than a web-of-trust one, less burden on network newcomers. > > Let us consider some of the complications here. > > A newcomer wants to make an outgoing payment. > Speculatively, it connects to some existing nodes based on some policy. > > Now, since forwarding is upfront, the newcomer fears that the node it > connected to might not even bother forwarding the payment, and instead just > fail it and claim the upfront fees. > > In particular: how would the newcomer offer upfront fees to a node it is > not directly channeled with? > In order to do that, we would have to offer the upfront fees for that > node, to the node we *are* channeled with, so it can forward this as well. > > * We can give the upfront fee outright to the first hop, and trust that if > it forwards, it will also forward the upfront fee for the next hop. > * The first hop would then prefer to just fail the HTLC then and there > and steal all the upfront fees. > * After all, the offerrer is a newcomer, and might be the sybil of a > hacker that is trying to tie up its liquidity. > The first hop would (1) avoid this risk and (2) earn more upfront > fees because it does not forward those fees to later hops. > * This is arguably custodial and not your keys not your coins applies. > Thus, it returns us back to tr\*st anyway. > * We can require that the first hop prove *where* along the route errored. > If it provably failed at a later hop, then the first hop can claim more > as upfront fees, since it will forward the upfront fees to the later hop as > well. > * This has to be enforcable onchain in case the channel gets dropped > onchain. > Is there a proposal SCRIPT which can enforce this? > * If not enforcable onchain, then there may be onchain shenanigans > possible and thus this solution might introduce an attack vector even as it > fixes another. > * On the other hand, sub-satoshi amounts are not enforcable onchain > too, and nobody cares, so... > > On the other hand, a web-of-tr\*st might not be *that* bad. > > One can say that "tr\*st is risk", and consider that the size and age of a > channel to a peer represents your tr\*st that that peer will behave > correctly for fast and timely resolution of payments. > And anyone can look at the blockchain and the network gossip to get an > idea of who is generally considered tr\*stworthy, and since that > information is backed by Bitcoins locked in channels, this is reasonably > hard to fake. > > On the other hand, this risks centralization around existing, long-lived > nodes. > *Sigh*. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Making (some) channel limits dynamic
Good morning Antoine, and Bastien, > Instead of relying on reputation, the other alternative is just to have an > upfront payment system, where a relay node doesn't have to account for a HTLC > issuer reputation to decide acceptance and can just forward a HTLC as long it > paid enough. More, I think it's better to mitigate jamming with a fees-based > system than a web-of-trust one, less burden on network newcomers. Let us consider some of the complications here. A newcomer wants to make an outgoing payment. Speculatively, it connects to some existing nodes based on some policy. Now, since forwarding is upfront, the newcomer fears that the node it connected to might not even bother forwarding the payment, and instead just fail it and claim the upfront fees. In particular: how would the newcomer offer upfront fees to a node it is not directly channeled with? In order to do that, we would have to offer the upfront fees for that node, to the node we *are* channeled with, so it can forward this as well. * We can give the upfront fee outright to the first hop, and trust that if it forwards, it will also forward the upfront fee for the next hop. * The first hop would then prefer to just fail the HTLC then and there and steal all the upfront fees. * After all, the offerrer is a newcomer, and might be the sybil of a hacker that is trying to tie up its liquidity. The first hop would (1) avoid this risk and (2) earn more upfront fees because it does not forward those fees to later hops. * This is arguably custodial and not your keys not your coins applies. Thus, it returns us back to tr\*st anyway. * We can require that the first hop prove *where* along the route errored. If it provably failed at a later hop, then the first hop can claim more as upfront fees, since it will forward the upfront fees to the later hop as well. * This has to be enforcable onchain in case the channel gets dropped onchain. Is there a proposal SCRIPT which can enforce this? * If not enforcable onchain, then there may be onchain shenanigans possible and thus this solution might introduce an attack vector even as it fixes another. * On the other hand, sub-satoshi amounts are not enforcable onchain too, and nobody cares, so... On the other hand, a web-of-tr\*st might not be *that* bad. One can say that "tr\*st is risk", and consider that the size and age of a channel to a peer represents your tr\*st that that peer will behave correctly for fast and timely resolution of payments. And anyone can look at the blockchain and the network gossip to get an idea of who is generally considered tr\*stworthy, and since that information is backed by Bitcoins locked in channels, this is reasonably hard to fake. On the other hand, this risks centralization around existing, long-lived nodes. *Sigh*. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Making (some) channel limits dynamic
Hello Bastien, As a first note , I was thinking dynamic policy adjustment would be covered by the dynamic commitment mechanism proposed by Laolu as it presents the same trade-offs, you need to stop channel HTLC processing before upgrading, otherwise it might falsify your whole in-flight HTLC accounting. > Recent discussions around channel jamming [1] have highlighted again the > need to think twice when > configuring your channels parameters. I'm still dubious that straighter channel parameters are the best solution to solve channel jamming. As a routing node evaluating a HTLC, I think the question you're trying to answer is : "Is this a _honest_ HTLC to relay ?", where honest is defined both as paying more fees that the liquidity lock and with high odds of a positive settlement, otherwise you won't get paid. The first predicate is easy to evaluate, just verify that the HTLC is paying more as an incoming packet that you have to send forward. On the other hand, the second predicate is hard to evaluate. A first lead of a solution is to evaluate the packet forwarder instead of the packet itself. You may have a web-of-trust/reputation system with a one-level rank of trust which would be enforced at the channel opening layer, i.e don't open/accept channels with random nodes. A less constraining version is still a reputation system but where you statically attribute a HTLC forwarding policy based on counterparty reputation (~today). The more evolved reputation system version you implicitly seem to argue for is adapting the forwarding policy based on counterparty past behavior, e.g like relaxing channel parameters for a counterparty upstreaming a lot of successful HTLCs. IMO, this is still presenting hurdles. If you have 1 BTC of outgoing bandwidth but your counterparty is enforcing a `max_htlc_value_in_flight_msat` of 0.5 BTC, it means you have a "sleeping" outgoing liquidity. Rationally, you should only open a channel with a capacity somehow equivalent to what is authorized by your counterparty relay policy. A lesson would be to negotiate first a policy then an opening, as of today they're still bundled in one message flow. I don't think you can reduce the capacity once you learn acceptor policy ? Don't overstake liquidity more than you can actually gain from. That said, if you have a dynamic policy model, at policy relaxation, you need to increase channel capacity to profit from relaxation, let's say through some kind of splice-in. But now you have on-chain fees at each policy/liquidity adjustment. Under a dynamic policy model based on accumulated reputation, it sounds like there is some kind of trade-off between useless off-chain liquidity and on-chain fees. Instead of relying on reputation, the other alternative is just to have an upfront payment system, where a relay node doesn't have to account for a HTLC issuer reputation to decide acceptance and can just forward a HTLC as long it paid enough. More, I think it's better to mitigate jamming with a fees-based system than a web-of-trust one, less burden on network newcomers. This doesn't prevent hybrid models where you might reward your good behaving peers with a discount on your upfront payment policy. What's your opinion ? Antoine Le lun. 5 oct. 2020 à 07:54, Bastien TEINTURIER via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > 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 > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Making (some) channel limits dynamic
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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
