{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-10-08\n📝 Original message:\nGood morning Antoine and Zman,\n\nThanks for your answers!\n\nI was thinking dynamic policy adjustment would be covered by the dynamic\n\u003e commitment mechanism proposed by Laolu\n\n\nI didn't mention this as I think we still have a long-ish way to go before\ndynamic commitments\nare spec-ed, implemented and deployed, and I think the parameters I'm\ninterested in don't require\nthat complexity to be updated.\n\nPlease forget about channel jamming, upfront fees et al and simply consider\nthe parameters I'm\nmentioning. It feels to me that these are by nature dynamic channel\nparameters (some of them are\neven present in `channel_update`, but no-one updates them yet because\ndirect peers don't take the\nupdate into account anyway). I'd like to raise `htlc_minimum_msat` on some\nbig channels because\nI'd like these channels to be used only for big-ish payments. Today I\ncan't, I have to close that\nchannel and open a new one for such a trivial configuration update, which\nis sad.\n\nThere is no need to stop the channel's operations while you're updating\nthese parameters, since\nthey can be updated unilaterally anyway. The only downside is that if you\nmake your policy stricter,\nyour peer may send you some HTLCs that you will immediately fail\nafterwards; it's only a minor\ninconvenience that won't trigger a channel closure.\n\nI'd like to know if other implementations than eclair have specificities\nthat would make this\nfeature particularly hard to implement or undesirable.\n\nThanks,\nBastien\n\nLe mar. 6 oct. 2020 à 18:43, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning Antoine, and Bastien,\n\u003e\n\u003e\n\u003e \u003e Instead of relying on reputation, the other alternative is just to have\n\u003e an upfront payment system, where a relay node doesn't have to account for a\n\u003e HTLC issuer reputation to decide acceptance and can just forward a HTLC as\n\u003e long it paid enough. More, I think it's better to mitigate jamming with a\n\u003e fees-based system than a web-of-trust one, less burden on network newcomers.\n\u003e\n\u003e Let us consider some of the complications here.\n\u003e\n\u003e A newcomer wants to make an outgoing payment.\n\u003e Speculatively, it connects to some existing nodes based on some policy.\n\u003e\n\u003e Now, since forwarding is upfront, the newcomer fears that the node it\n\u003e connected to might not even bother forwarding the payment, and instead just\n\u003e fail it and claim the upfront fees.\n\u003e\n\u003e In particular: how would the newcomer offer upfront fees to a node it is\n\u003e not directly channeled with?\n\u003e In order to do that, we would have to offer the upfront fees for that\n\u003e node, to the node we *are* channeled with, so it can forward this as well.\n\u003e\n\u003e * We can give the upfront fee outright to the first hop, and trust that if\n\u003e it forwards, it will also forward the upfront fee for the next hop.\n\u003e   * The first hop would then prefer to just fail the HTLC then and there\n\u003e and steal all the upfront fees.\n\u003e     * After all, the offerrer is a newcomer, and might be the sybil of a\n\u003e hacker that is trying to tie up its liquidity.\n\u003e       The first hop would (1) avoid this risk and (2) earn more upfront\n\u003e fees because it does not forward those fees to later hops.\n\u003e   * This is arguably custodial and not your keys not your coins applies.\n\u003e     Thus, it returns us back to tr\\*st anyway.\n\u003e * We can require that the first hop prove *where* along the route errored.\n\u003e  If it provably failed at a later hop, then the first hop can claim more\n\u003e as upfront fees, since it will forward the upfront fees to the later hop as\n\u003e well.\n\u003e   * This has to be enforcable onchain in case the channel gets dropped\n\u003e onchain.\n\u003e     Is there a proposal SCRIPT which can enforce this?\n\u003e   * If not enforcable onchain, then there may be onchain shenanigans\n\u003e possible and thus this solution might introduce an attack vector even as it\n\u003e fixes another.\n\u003e     * On the other hand, sub-satoshi amounts are not enforcable onchain\n\u003e too, and nobody cares, so...\n\u003e\n\u003e On the other hand, a web-of-tr\\*st might not be *that* bad.\n\u003e\n\u003e One can say that \"tr\\*st is risk\", and consider that the size and age of a\n\u003e channel to a peer represents your tr\\*st that that peer will behave\n\u003e correctly for fast and timely resolution of payments.\n\u003e And anyone can look at the blockchain and the network gossip to get an\n\u003e idea of who is generally considered tr\\*stworthy, and since that\n\u003e information is backed by Bitcoins locked in channels, this is reasonably\n\u003e hard to fake.\n\u003e\n\u003e On the other hand, this risks centralization around existing, long-lived\n\u003e nodes.\n\u003e *Sigh*.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201008/22e78ab2/attachment-0001.html\u003e"}