Jim Posen [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-15 📝 Original message: > > You're forgetting the ...

📅 Original date posted:2018-05-15
📝 Original message:
>
> You're forgetting the failure cases, where now I can profit.
>
> If I disconnect from another node, I now have a disincentive to tell
> others. At the moment we send an update disabling the channel (though
> we should give a few seconds for reconnect first, but whatever).
>
> Similarly, the rewards aren't proportional: being cheaper than other
> routes gets you all the traffic, but now you profit even if you can't
> service the payments. In fact, once a channel becomes hard to use (low
> capacity, transient disconnect, whatever), I *should* advertize it as
> cheaper route than anyone else: free money!
>
> I'm sure there are other ways to game it, but the underlying reason is
> clear: it misaligns user and node incentives.


If the system is sufficiently decentralized, managing to cheat everyone
> once is very profitable though.
>

I still don't agree with the conclusion.

What are the incentives currently for a node to advertise disabled
channels? Firstly, it reduces computational effort of performing an
unnecessary channel update. The main incentive though is that it is the
recommended spec compliant behavior, and makes the link appear more
reliable to the sender. I think this has to be analyzed as a repeated game,
where senders will prefer links that not only advertise lower fees, but
have a history of being reliable (or at least don't have a history of being
unreliable). So with a fee of 0 on failed payments, we think that there's
probably sufficient reason for nodes to advertise when channels are
disabled. I'll grant, obviously, that if that there is high fee on failed
payments that it would create incentive problems, but not if the
unconditional fee is low enough. Note also the unconditional fee is also
visible to senders, who will choose not to route through such links for
this exact reason. So your example of a node advertising cheap fees on
disabled links, it would only make sense to lower the success-conditional
fee, not the unconditional fee. Ultimately, I think this will reach an
equilibrium assuming senders have good route selection algorithms.

Now, that said, if this unconditional fee were the only (or even main)
protection against loop attacks, it would probably require them to be so
high as to create incentive problems. I am proposing the unconditional fee
as a spam fee to punish senders who just send a bunch of failing payments
in order to collect routing information, and put load on the network in the
process for no good reason. With this as the purpose, I think this
unconditional spam fee can be low enough to avoid the issues you raise.

One of my beliefs in structuring incentives it that it's far more
acceptable for senders to get cheated by nodes they route through than for
routers to be attacked. The reason is that senders collect a lot more
information in failure cases and can avoid repeated occurrences by
selecting routes differently. Routers, on the other hand, have far more
limited information and choices and their operation is critical to the
efficiency and decentralization of the system, so they should be protected
by the protocol to a greater degree.


> But I can make you look like a delaying node whenever I want. The only
> way to ensure that I lose more reputation than you do is to leak
> information about route length for *everyone*. And even then, it's just
> a matter of numbers. I can make successful payments to myself through
> the same peers (but not you!) to stay above their threshold so my
> reputation is intact.
>
> So it's basically a question of how expensive is it for me to throw you
> off the network? You have to tune that number carefully.
>

Remember, reputation is local to each node, so the only way you can raise
your reputation with me is by participating in successful circuits *with
me*. If you route successful payments on circuits with other peers, you may
raise your reputation with them, but will do nothing to convince me to send
more payments through you. So it is not true that you can make me look like
a delaying node whenever you want; after a few bad interactions, I will
stop routing through you until you participate in enough successful
payments *with me* as the downstream to earn back your reputation.

I agree this number needs to be tuned carefully, but ideally this (the
reputation rate loss) is something that can be tuned individually by
routers according to their risk tolerance and history of attacks on the
network. I think it's far preferable to have a number that can be tuned in
the face of DoS attacks than being caught with no protection whatsoever.

But we're busy trying to remove all the methods of deanonymizing the
> network, and you seem to be adding a new one, *and* providing an
> incentive to deanonymize.
>
> Yes, which is why we have mitigations in place (which are still probably
> insufficient). I really don't want to add another vector.
>

This gets to the heart of the tradeoff between network efficiency and
privacy. I admit that my proposal sacrifices on privacy, and I personally
find it acceptable given the added protection against DoS attacks, but I
understand the counterargument as well.

One additional thing to consider, though, is that if DoS attacks are
problematic and there is no protection, many nodes may stop routing
payments entirely. Onion routing through a network with very few possible
circuits certainly is less private than revealing additional circuit
information on a decentralized routing network.


> So now I'll try to deanonymize all payments so I can determine this.
> Those who do this best will be rewarded, and those who don't try will be
> knocked off the network, probably by those who can!
>

I'm not following, how are you deanonymizing payments? Having more
information about downstream hops can help one make better routing
decisions, but if the reputation system works properly, you should only
need to care about the reputation of the next hop.


> So I'd like to see a real design of the reputation system. If it's
> practical (which is a significant hurdle), we then need to carefully
> evaluate whether we're creating significant disincentives to
> neighbourliness.
>

I tried to mostly describe the design in the first email, but it's kind of
disorganized. I'll try to sketch it out here more succinctly.

Each node has a local configuration of its "reputation loss rate" per
channel in units of Hz. This configured rate is not explicitly advertised
to peers. Each update_add_htlc has an additional field the "reputation loss
rate" in units of satoshis per second, calculated as the reputation loss
rate of the upstream HTLC plus the local reputation loss rate times the
offered HTLC value. This value can be obfuscated somewhat by the origin of
the payment and at each hop with some amount of noise, subject to the
concerns raised in my discussion with ZmnSCPxj. When forwarding an HTLC,
the upstream hop measures the elapsed time between delivery of a commitment
signature on the add and receipt of the fail/update.

For each peer node, keep a reputation score in units of satoshis. For each
peer, when a payment completes where they are the upstream or downstream
hop, add the amount collected in fees to their reputation score. For each
payment where they are the downstream hop, subtract from their reputation
score the reputation loss rate on the offered HTLC times its elapsed time.
Reputation score is not explicitly shared between peered nodes, but can be
estimated to within differences in elapsed time measurements.

When you receive an HTLC to be forwarded to some downstream node, compare
their current reputation score with the offered reputation loss rate times
10 minutes times the CLTV on the HTLC. If their reputation is sufficient,
forward the HTLC and place a hold on their total reputation for that amount
(so that concurrently forwarded HTLCs can't exceed their reputation
"balance"). New, unknown, peers should get some initial reputation,
presumably greater for channels that one initiates vs channels one receives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180515/35dedefc/attachment-0001.html>;