Why Nostr? What is Njump?
2023-06-09 13:12:40
in reply to

ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-14 🗒️ Summary of this message: The Lightning ...

📅 Original date posted:2023-02-14
🗒️ Summary of this message: The Lightning Network's reputation system relies on first-hand and inferred experience, but repeat interactions are rare. Wallet vendors can provide live network views, but this is ultimately hearsay. Altruistic nodes could provide scoring data, but LSPs can be bought out.
📝 Original message:
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.

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.

Ultimately the network gets healthier if flows are bidirectional, swaps are essential to bootstrapping from the starting state where there are distinct "customers" and "merchants", but current one-hop-only peerswaps are too local for the blockchain cost, and multi-hop source-routed swaps have the same issue as standard payments.
The advantage of forwardable peerswaps is that it is specifically not source routed --- intermediate nodes make decisions of where to forward, and they are thus incentivized to benefit the network because they benefit themselves.


I think it should be a principle of protocol design to embrace a capitalistic mindset, by which I mean: ensuring the rules make "beneficial for me" the same as "beneficial to everyone".
Certainly I can take a common knife from my kitchen and stick the pointy end into my neighbor, then take all their belongings, which would be very beneficial to me, but would not be beneficial to everyone, which is why laws against manslaughter and theft exist.
Ultimately, protocol design is the laying down of laws, and the proper function of this lawmaking position is to ensure that "beneficial for me" will be something that is "beneficial to everyone".
Indeed, the entire point of having a punitive Poon-Dryja is to ensure that "beneficial for me" does not include theft of the channel funds by using old state, and is exemplary of this principle.
"Greed is Good" might not be true, but perhaps: "We should strive to MAKE Greed Good".

Forwardable peerswaps are beneficial to every participant, and thus beneficial to the network, and thus should be part of the law of Lightning Network protocol.
It *creates* high availability of channels and routing, without self-assertions or hearsay; it only requires local reputation (a forwarding node will forward a peerswap only if it knows it can benefit from whichever hop it is forwarding to: the locality avoids the issue where a node may never interact with another node again, since the node has a channel with them and is expected to repeatedly interact with them in the close future, and thus has very good local information).

Regards,
ZmnSCPxj
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l