On 2/13/23 7:05 PM, ZmnSCPxj wrote:
Good morning all,
First of all let's see what types of reputation system exist (and yes,
this is my very informal categorization):
- First hand experience
- Inferred experience
- Hearsay
The first two are likely the setup we all are comfortable with: we ourselves
experienced something, and make some decisions based on that
experience. This is probably what we're all doing at the moment: we
attempt a payment, it fails, we back off for a bit from that channel
being used again. This requires either being able to witness the issue
directly (local peer) or infer from unforgeable error messages (the
failing node returns an error, and it can't point the finger at someone
else). Notice that this also includes some transitive constructions,
such as the backpressure mechanism we were discussing for ariard's
credentials proposal.
Ideally we'd only rely on the first two to make decisions, but here's
exactly the issue we ran into with Bittorrent: repeat interactions are
too rare. In addition, our local knowledge gets out of date the longer
we wait, and a previously failing channel may now be good again, and
vice-versa. For us to have sufficient knowledge to make good decisions
we need to repeatedly interact with the same nodes in the network, and
since end-users will be very unlikely to do that, we might end up in a
situation were we instinctively fall back to the hearsay method, either
by sharing our local reputation with peers and then somehow combine that
with our own view. To the best of my knowledge such a system has never
been built successfully, and all attempts have ended in a system that
was either way too simple or is gameable by rational players.
In lightning we have a trivial solution to this - your wallet vendor/LSP is
already extracting a fee
from you for every HTLC routed through it, it has you captive and can set the
fee (largely)
arbitrarily (up to you paying on-chain fees to switch LSPs). They can happily
tell you their view of
the network ~live and you should generally accept it. Its by no means perfect,
and there's plenty of
games they could play on, eg, your privacy, but its pretty damned good.
If we care a ton about the risks here, we could have a few altruistic nodes
that release similar
info and users can median-filter the data in one way or another to reduce risk.
I just do not buy that this is a difficult problem for the "end user" part of
the network. For
larger nodes its (obviously, and trivially) not a problem either, which leaves the
"middle nodes"
stranded without good data but without an LSP they want to use for data. I
believe that isn't a
large enough cohort to change the whole network around for, and them asking a
few altruistic (let's
say, developer?) nodes for scoring data seems more than sufficient.
But this is all ultimately hearsay.
LSPs can be bought out, and developers can go rogue.
Neither should be trusted if at all possible.
You're missing the point - if your LSP wants to "go rogue" here, at worst they can charge you more
fees. They could also do this by...charging you more fees. I'm not really sure what your concern is.
Which is why I think forwardable peerswaps fixes this: it *creates* paths that
allow payment routing, without requiring pervasive monitoring (which is
horrible because eventually the network will be large enough that you will
never encounter the same node twice if you're a plebeian, and if you're an
aristocrat, you have every incentive to lie to the plebeians to solidify your
power) of the network.
No, this is much, much worse for the network. In order to do this "live" (i.e. without failing a
payment) you have to establish trust relationships across the network (i.e. make giving your peers
credit a requirement to be considered a "robust node" and, thus, receive fee revenue).
Doing splicing/peerswap as a better way to rebalance is, of course, awesome, but it doesn't solve
the issue of "what do I do if I'm just too low on capacity *right now* to clear this HTLC".
Matt
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
