{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-02-13\n🗒️ Summary of this message: The Lightning Network may require routing nodes to operate flawlessly or face penalties, to ensure competitiveness with centralized payment systems. A proposed solution is to extend the `channel_update` field with a new bit to signal `highly_available` channels, allowing payers to prefer them during pathfinding, but with a stronger penalty for failure. This creates an opportunity for routing nodes to attract more traffic but also comes with the responsibility to deliver.\n📝 Original message:\nHi,\n\nFor a long time I've held the expectation that eventually payers on the\nlightning network will become very strict about node performance. That they\nwill require a routing node to operate flawlessly or else apply a hefty\npenalty such as completely avoiding the node for an extended period of time\n- multiple weeks. The consequence of this is that routing nodes would need\nto manage their liquidity meticulously because every failure potentially\nhas a large impact on future routing revenue.\n\nI think movement in this direction is important to guarantee\ncompetitiveness with centralised payment systems and their (at least\ntheoretical) ability to process a payment in the blink of an eye. A\nlightning wallet trying multiple paths to find one that works doesn't help\nwith this.\n\nA common argument against strict penalisation is that it would lead to less\nefficient use of capital. Routing nodes would need to maintain pools of\nliquidity to guarantee successes all the time. My opinion on this is that\nlightning is already enormously capital efficient at scale and that it is\nworth sacrificing a slight part of that efficiency to also achieve the\nlowest possible latency.\n\nThis brings me to the actual subject of this post. Assuming strict\npenalisation is good, it may still not be ideal to flip the switch from one\nday to the other. Routing nodes may not offer the required level of service\nyet, causing senders to end up with no nodes to choose from.\n\nOne option is to gradually increase the strength of the penalties, so that\nrouting nodes are given time to adapt to the new standards. This does\nrequire everyone to move along and leaves no space for cheap routing nodes\nwith less leeway in terms of liquidity.\n\nTherefore I am proposing another way to go about it: extend the\n`channel_update` field `channel_flags` with a new bit that the sender can\nuse to signal `highly_available`.\n\nIt's then up to payers to decide how to interpret this flag. One way could\nbe to prefer `highly_available` channels during pathfinding. But if the\nrouting node then returns a failure, a much stronger than normal penalty\nwill be applied. For routing nodes this creates an opportunity to attract\nmore traffic by marking some channels as `highly_available`, but it also\ncomes with the responsibility to deliver.\n\nWithout shadow channels, it is impossible to guarantee liquidity up to the\nchannel capacity. It might make sense for senders to only assume high\navailability for amounts up to `htlc_maximum_msat`.\n\nA variation on this scheme that requires no extension of `channel_update`\nis to signal availability implicitly through routing fees. So the more\nexpensive a channel is, the stronger the penalty that is applied on failure\nwill be. It seems less ideal though, because it could disincentivize cheap\nbut reliable channels on high traffic links.\n\nThe effort required to implement some form of a `highly_available` flag\nseem limited and it may help to get payment success rates up. Interested to\nhear your thoughts.\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230213/adf0c913/attachment.html\u003e"}