Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-09 📝 Original message: Jim Posen <jim.posen at ...
📅 Original date posted:2018-05-09
📝 Original message:
Jim Posen <jim.posen at gmail.com> writes:
> There are two directions of solutions I have heard: 1) protocol support for
> decrypting the onion route if the HTLC is kept in-flight for too long 2)
> requiring fees even if the payment fails as a cost to the attacker 3) some
> sort of reputation system for nodes.
>
> Option 1 I'm afraid may be quite complex. Say this mechanism kicks in and
> all nodes in the circuit deobfuscate the route and are able to see the
> delays at each hop. The outcome we hope for is that there is one node
> clearly to blame and the prior hop in the route fails all channels with
> them. However, the attacker can of course control multiple successive hops
> in the route, one that looks innocent in front of one that looks guilty,
> then keep the channel alive and try again. So then all nodes need to keep a
> record of the full circuits and iteratively shift blame up the chain if bad
> HTLCs keep going through those channels.
You missed the vital detail: that you must prove channel closure if you
can't unpeel the onion further. That *will* hit an unresponsive party
with a penalty.[1]
> Option 2 is also problematic because it only protects against the case
> where the sender is colluding with the receiver, and not where a routing
> node is opportunistically delaying payments. This would, however, likely be
> successful against nodes being annoying and sending tons of payments with
> randomly generated payment hashes in order to "ping" a circuit.
The models we tried in Milan all created an incentive to fail payments,
which is a non-starter.
> Option 3 has become my preferred solution. The idea is that that for each
> node that one has channels with, it only forwards payments through them if
> they have a good history, otherwise it fails the payment. Notably, we
> ignore whether the downstream hop is directly responsible for delaying a
> payment or whether they are simply willing to forward to another node that
> is intentionally delaying -- both should be considered bad behavior. In my
> opinion, this type of solution fits best into the Lightning model of
> independent, linked channels where each node has private contracts with its
> direct peers. It also is the simplest in the context of onion routing
> because if you are offered an HTLC to route, the only decision you can make
> is whether to forward it or fail it based on the amount, previous hop, and
> next hop. When I refer to "reputation" hereafter, I do not mean a global
> reputation that is gossiped about -- just a local view of a peer's history.
This seems like we'd need some serious evaluation to show that this
works, because the risks are very high.
I can destroy your node's reputation by routing crap through you; even
if it costs me marginaly more reputation than it does you, that just
means that the largest players can force failure upon smaller players,
centralizing the network. And I think trying to ensure that it costs me
more reputation than the sum of downstream reputation loss leaks too
much information
If the system doesn't work perfectly, it creates incentive to
de-anonymize payments so you can determine which are likely to fail, and
also means nodes are safest not forwarding payments, lest they ruin
their reputatation. But nodes which don't forward have much less
privacy.
But I agree, all solutions I've seen to this problem are bad in
different ways.
Cheers,
Rusty.
[1] Proving that you've committed to a particular HTLC in a channel is
difficult, because of dust HTLCs[2] and partially-committed ones[3].
[2] We could have an OP_RETURN output which was a merkle tree of trimmed
HTLCs to cover the dust case.
[3] You committed to an HTLC but the peer didn't respond; you have no
proof. So you also need to present a merkle tree of uncommitted
HTLCs (limited, say, to 16) otherwise you can create 1M HTLCs, then
claim they were all in that one channel close.
📝 Original message:
Jim Posen <jim.posen at gmail.com> writes:
> There are two directions of solutions I have heard: 1) protocol support for
> decrypting the onion route if the HTLC is kept in-flight for too long 2)
> requiring fees even if the payment fails as a cost to the attacker 3) some
> sort of reputation system for nodes.
>
> Option 1 I'm afraid may be quite complex. Say this mechanism kicks in and
> all nodes in the circuit deobfuscate the route and are able to see the
> delays at each hop. The outcome we hope for is that there is one node
> clearly to blame and the prior hop in the route fails all channels with
> them. However, the attacker can of course control multiple successive hops
> in the route, one that looks innocent in front of one that looks guilty,
> then keep the channel alive and try again. So then all nodes need to keep a
> record of the full circuits and iteratively shift blame up the chain if bad
> HTLCs keep going through those channels.
You missed the vital detail: that you must prove channel closure if you
can't unpeel the onion further. That *will* hit an unresponsive party
with a penalty.[1]
> Option 2 is also problematic because it only protects against the case
> where the sender is colluding with the receiver, and not where a routing
> node is opportunistically delaying payments. This would, however, likely be
> successful against nodes being annoying and sending tons of payments with
> randomly generated payment hashes in order to "ping" a circuit.
The models we tried in Milan all created an incentive to fail payments,
which is a non-starter.
> Option 3 has become my preferred solution. The idea is that that for each
> node that one has channels with, it only forwards payments through them if
> they have a good history, otherwise it fails the payment. Notably, we
> ignore whether the downstream hop is directly responsible for delaying a
> payment or whether they are simply willing to forward to another node that
> is intentionally delaying -- both should be considered bad behavior. In my
> opinion, this type of solution fits best into the Lightning model of
> independent, linked channels where each node has private contracts with its
> direct peers. It also is the simplest in the context of onion routing
> because if you are offered an HTLC to route, the only decision you can make
> is whether to forward it or fail it based on the amount, previous hop, and
> next hop. When I refer to "reputation" hereafter, I do not mean a global
> reputation that is gossiped about -- just a local view of a peer's history.
This seems like we'd need some serious evaluation to show that this
works, because the risks are very high.
I can destroy your node's reputation by routing crap through you; even
if it costs me marginaly more reputation than it does you, that just
means that the largest players can force failure upon smaller players,
centralizing the network. And I think trying to ensure that it costs me
more reputation than the sum of downstream reputation loss leaks too
much information
If the system doesn't work perfectly, it creates incentive to
de-anonymize payments so you can determine which are likely to fail, and
also means nodes are safest not forwarding payments, lest they ruin
their reputatation. But nodes which don't forward have much less
privacy.
But I agree, all solutions I've seen to this problem are bad in
different ways.
Cheers,
Rusty.
[1] Proving that you've committed to a particular HTLC in a channel is
difficult, because of dust HTLCs[2] and partially-committed ones[3].
[2] We could have an OP_RETURN output which was a merkle tree of trimmed
HTLCs to cover the dust case.
[3] You committed to an HTLC but the peer didn't respond; you have no
proof. So you also need to present a merkle tree of uncommitted
HTLCs (limited, say, to 16) otherwise you can create 1M HTLCs, then
claim they were all in that one channel close.