rich1.0npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddhttps://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddnjumphttps://nostr.ae📅 Original date posted:2020-10-08 📝 Original message: > 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 <bastien at acinq.fr> 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 <ZmnSCPxj at protonmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201008/4fe5af26/attachment-0001.html>