Topological Graphic of “Sink” attack, afaiu.
------------------------
| |
----------| direct neighbor #1 |---------
| |______________________| |
| |
| ------------------------ |
| | | |
|---------| direct neighbor #2 |--------|
| |______________________| |
| |
--------------- | ------------------------ |
| | | | | |
----------------| target node |---------|---------| direct neighbor #3 |--------|
| |_____________| | |______________________| |
| | |
| | ------------------------ |
| | | | |
| |---------| direct neighbor #4 |--------|
| | |______________________| |
| | |
| | ------------------------ |
| | | | |
| |---------| direct nighbor #5 |--------|
| |______________________| |
| |
----------------- |
| | |
| attacker node | |
|_______________| |
| |
| |
| |
| |
| ---------------------------- |
| | | |
|---------------| indirect neighbor * #15 |--------------------------------------|
|__________________________|
Afaiu, a “sink” attack in the absence of outgoing reputation exploiting the lack of outgpoing reputation works in the following way, there is a target node A connected to a number of direct neighbor, which are themselves connected to a large indirect neighbor. A HTLC from a target node’s direct neighbor at destination of an indirect neighbor is withheld for few hours during which there is no resolution.
The attacker node might already general jam the channel links between the target node’s direct neighbor and the indirect neighbor to provoke the traffic re-direction from the target node’s peers links to the “destination” large node to the attacker carried links.
In that simulation outline, still afaiu, the attacker should get a drop of the incoming reputation of the target node’s peers links and hypothetically the target revenue has dropped below its revenue as time of no jam.
What is not said in presenting the simulation results is if it is encompassing in the attack cost computation, the subsidiary cost of jamming the links between the direct neighbor and indirect neighbor to provoke the traffic re-direction.
While for simulation reproducibility, one can go to collect channel_announcement signed by the acinq node pubkey, this is only for pub channel and it doesn’t display the private chan, which by design are not announced on the gossip network.
I think it’s an interesting research question if there is bootstrapping asymmetries in the design of local ressource conservation that an attacker could exploit by spawning of a lot of spikes nodes to a high-“pub-chan”-density routing node to downgrade the incoming or outgoing reputation of a node.
If there is a repository somewhere for the traffic patterns samples that have been already run, that it’s interesting for reproducibility. Alternatively the fuzz targets should be good enough as it’s verbose to indicate what should be the traffic patterns yield.
Apart of the pub-chan vs private-chan as pointed above, another “worst case” topologies scenario, where the attacker could have a great advantage, if its the attacker is “allowed” to open links during the simulation or if the simulation is only considering a static chan graph.
We began to look at outgoing reputation after the observation from @ProofOfKeags and > @morehouse that a slow jamming attack requires a malicious downstream node, but not > necessarily a malicious upstream node. Fast jamming attacks are perpetrated by upstream > nodes, but we have unconditional fees to protect against this type of spam so perhaps we > don’t need to worry about incoming reputation.
I think this is a correct observation that you do not necessarily need a malicious upstream node. Going even further in the world of lightning today, one could use invoice r routing hints to inject jamming in the graph, with neither upstream or downstream node at all (-- i believe there is an astucious trick here). Leveraging peerswap style flow both as traffic entries and exists can be an interesting point to study.
I believe this is mostly correct, that you have to doubly compensate reputation-wise both incoming and outgoing links (or negatively downward their reputation) though I believe there might be a thorny case where both incoming and outgoing links are malicious and holding the resolution (i.e not signing commitment_signed on time) to break the transitivity. Somehow, I think the bi-directional reputation might have to be ticked by the same clock for a same HTLC transit, though still treaded in isolation for the viewpoint of the target node. I have not given more thoughts to it.