{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-02-13\n📝 Original message:\nThanks Christian,\n\nOn 2/13/23 7:32 AM, Christian Decker wrote:\n\u003e Hi Matt,\n\u003e Hi Joost,\n\u003e \n\u003e let me chime in here, since we seem to be slowly reinventing all the\n\u003e research on reputation systems that is already out there. First of all\n\u003e let me say that I am personally not a fan of reputation systems in\n\u003e general, just to get my own biases out of the way, now on to the why :-)\n\u003e \n\u003e Reputation systems are great when they work, but they are horrible to\n\u003e get right, and certainly the patchworky approach we see being proposed\n\u003e today will end up with a system that is easy to exploit and hard to\n\u003e understand. The last time I encountered this kind of scenario was during\n\u003e my work on Bittorrent, where the often theorized tit-for-tat approach\n\u003e failed spectacularly, and leeching (i.e., not contributing to other\n\u003e people's download) is rampant even today (BT only works because a few\n\u003e don't care about their upload bandwidth).\n\u003e \n\u003e First of all let's see what types of reputation system exist (and yes,\n\u003e this is my very informal categorization):\n\u003e \n\u003e   - First hand experience\n\u003e   - Inferred experience\n\u003e   - Hearsay\n\u003e \n\u003e The first two are likely the setup we all are comfortable with: we ourselves\n\u003e experienced something, and make some decisions based on that\n\u003e experience. This is probably what we're all doing at the moment: we\n\u003e attempt a payment, it fails, we back off for a bit from that channel\n\u003e being used again. This requires either being able to witness the issue\n\u003e directly (local peer) or infer from unforgeable error messages (the\n\u003e failing node returns an error, and it can't point the finger at someone\n\u003e else). Notice that this also includes some transitive constructions,\n\u003e such as the backpressure mechanism we were discussing for ariard's\n\u003e credentials proposal.\n\u003e \n\u003e Ideally we'd only rely on the first two to make decisions, but here's\n\u003e exactly the issue we ran into with Bittorrent: repeat interactions are\n\u003e too rare. In addition, our local knowledge gets out of date the longer\n\u003e we wait, and a previously failing channel may now be good again, and\n\u003e vice-versa. For us to have sufficient knowledge to make good decisions\n\u003e we need to repeatedly interact with the same nodes in the network, and\n\u003e since end-users will be very unlikely to do that, we might end up in a\n\u003e situation were we instinctively fall back to the hearsay method, either\n\u003e by sharing our local reputation with peers and then somehow combine that\n\u003e with our own view. To the best of my knowledge such a system has never\n\u003e been built successfully, and all attempts have ended in a system that\n\u003e was either way too simple or is gameable by rational players.\n\nIn lightning we have a trivial solution to this - your wallet vendor/LSP is already extracting a fee \nfrom you for every HTLC routed through it, it has you captive and can set the fee (largely) \narbitrarily (up to you paying on-chain fees to switch LSPs). They can happily tell you their view of \nthe network ~live and you should generally accept it. Its by no means perfect, and there's plenty of \ngames they could play on, eg, your privacy, but its pretty damned good.\n\nIf we care a ton about the risks here, we could have a few altruistic nodes that release similar \ninfo and users can median-filter the data in one way or another to reduce risk.\n\nI just do not buy that this is a difficult problem for the \"end user\" part of the network. For \nlarger nodes its (obviously, and trivially) not a problem either, which leaves the \"middle nodes\" \nstranded without good data but without an LSP they want to use for data. I believe that isn't a \nlarge enough cohort to change the whole network around for, and them asking a few altruistic (let's \nsay, developer?) nodes for scoring data seems more than sufficient.\n\n\u003e I also object to the wording of penalizing nodes that haven't been as\n\u003e reliable in the past. It's not penalizing them if, based on our local\n\u003e information, we decide to route over other nodes for a bit. Our goal is\n\u003e optimize the payment process, chosing the best possible routes, not\n\u003e making a judgement on the honesty or reliability of a node. When talking\n\u003e about penalizing we see node operators starting to play stupid games to\n\u003e avoid that perceived penalty, when in reality they should do their best\n\u003e to route as many payments successfully as possible (the negative fees\n\u003e for direct peers \"exhausting\" a balanced flow is one such example of\n\u003e premature optimization in that direction imho).\n\nYes! Very much yes! I hate this line of thinking.\n\n\u003e So I guess what I'm saying is that we need to get away from this\n\u003e patchwork mode of building the protocol, and have a much clearer model\n\u003e for a) what we want to achieve, b) how much untrustworthy information we\n\u003e want to rely on, and c) how we protect (and possibly prove security)\n\u003e against manipulation by rational players. For the last question we at\n\u003e least have one nice feature (for now), namely that the identities are\n\u003e semi-permanent, and so white-washing attacks at least are not free.\n\u003e \n\u003e And after all this rambling, let's get back to the topic at hand: I\n\u003e don't think enshrining the differences of availability in the protocol,\n\u003e thus creating two classes of nodes, is a desirable\n\u003e feature. Communicating up-front that I intend to be reliable does\n\u003e nothing, and penalizing after the fact isn't worth much due to the\n\u003e repeat interactions issue. It'd be even worse if now we had to rely on a\n\u003e third party to aggregate and track the reliability, in order to get\n\u003e enough repeat interactions to build a good model of their liquidity,\n\u003e since we're now back in the hearsay world, and the third party can feed\n\u003e us wrong information to maximize their profits.\n\u003e \n\u003e Regards,\n\u003e Christian\n\u003e \n\u003e \n\u003e Matt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e\u003e Hi Joost,\n\u003e\u003e\n\u003e\u003e I’m not sure I agree that lightning is “capital efficient” (or even close to it), but more generally I don’t see why this needs a signal.\n\u003e\u003e\n\u003e\u003e If nodes start aggressively preferring routes through nodes that reliably route payments (which I believe lnd already does, in effect, to some large extent), they should do so by measurement, not signaling.\n\u003e\u003e\n\u003e\u003e In practice, many channels on the network are “high availability” today, but only in one direction (I.e. they aren’t regularly spliced/rebalanced and are regularly unbalanced). A node strongly preferring a high payment success rate *should* prefer such a channel, but in your scheme would not.\n\u003e\u003e\n\u003e\u003e This ignores the myriad of “at what threshold do you signal HA” issues, which likely make such a signal DOA, anyway.\n\u003e\u003e\n\u003e\u003e Finally, I’m very dismayed at this direction in thinking on how ln should work - nodes should be measuring the network and routing over paths that it thinks are reliable for what it wants, *robustly over an unreliable network*. We should absolutely not be expecting the lightning network to be built out of high reliability nodes, that creates strong centralization pressure. To truly meet a “high availability” threshold, realistically, you’d need to be able to JIT 0conf splice-in, which would drive lightning to actually being a credit network.\n\u003e\u003e\n\u003e\u003e With reasonable volume, lightning today is very reliable and relatively fast, with few retries required. I don’t think we need to change anything to fix it. :)\n\u003e\u003e\n\u003e\u003e Matt\n\u003e\u003e\n\u003e\u003e\u003e On Feb 13, 2023, at 06:46, Joost Jager \u003cjoost.jager at gmail.com\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e \n\u003e\u003e\u003e Hi,\n\u003e\u003e\u003e\n\u003e\u003e\u003e For a long time I've held the expectation that eventually payers on the lightning network will become very strict about node performance. That they will require a routing node to operate flawlessly or else apply a hefty penalty such as completely avoiding the node for an extended period of time - multiple weeks. The consequence of this is that routing nodes would need to manage their liquidity meticulously because every failure potentially has a large impact on future routing revenue.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I think movement in this direction is important to guarantee competitiveness with centralised payment systems and their (at least theoretical) ability to process a payment in the blink of an eye. A lightning wallet trying multiple paths to find one that works doesn't help with this.\n\u003e\u003e\u003e\n\u003e\u003e\u003e A common argument against strict penalisation is that it would lead to less efficient use of capital. Routing nodes would need to maintain pools of liquidity to guarantee successes all the time. My opinion on this is that lightning is already enormously capital efficient at scale and that it is worth sacrificing a slight part of that efficiency to also achieve the lowest possible latency.\n\u003e\u003e\u003e\n\u003e\u003e\u003e This brings me to the actual subject of this post. Assuming strict penalisation is good, it may still not be ideal to flip the switch from one day to the other. Routing nodes may not offer the required level of service yet, causing senders to end up with no nodes to choose from.\n\u003e\u003e\u003e\n\u003e\u003e\u003e One option is to gradually increase the strength of the penalties, so that routing nodes are given time to adapt to the new standards. This does require everyone to move along and leaves no space for cheap routing nodes with less leeway in terms of liquidity.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Therefore I am proposing another way to go about it: extend the `channel_update` field `channel_flags` with a new bit that the sender can use to signal `highly_available`.\n\u003e\u003e\u003e\n\u003e\u003e\u003e It's then up to payers to decide how to interpret this flag. One way could be to prefer `highly_available` channels during pathfinding. But if the routing node then returns a failure, a much stronger than normal penalty will be applied. For routing nodes this creates an opportunity to attract more traffic by marking some channels as `highly_available`, but it also comes with the responsibility to deliver.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Without shadow channels, it is impossible to guarantee liquidity up to the channel capacity. It might make sense for senders to only assume high availability for amounts up to `htlc_maximum_msat`.\n\u003e\u003e\u003e\n\u003e\u003e\u003e A variation on this scheme that requires no extension of `channel_update` is to signal availability implicitly through routing fees. So the more expensive a channel is, the stronger the penalty that is applied on failure will be. It seems less ideal though, because it could disincentivize cheap but reliable channels on high traffic links.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The effort required to implement some form of a `highly_available` flag seem limited and it may help to get payment success rates up. Interested to hear your thoughts.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Joost\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}