From antoine.riard at gmail.com Thu Oct 8 15:56:33 2020 From: antoine.riard at gmail.com (Antoine Riard) Date: Thu, 8 Oct 2020 11:56:33 -0400 Subject: [Lightning-dev] Making (some) channel limits dynamic In-Reply-To: References: Message-ID: > 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 to fake. >> >> On the other hand, this risks centralization around existing, long-lived >> nodes. >> *Sigh*. >> >> Regards, >> ZmnSCPxj >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: