Prevent another node from tricking us into sending a cheque after receiving a cheque

[ralph-pichler]

Right now a node can trigger one of its peers to send a cheque simply by sending a cheque and thereby putting that peer into debt. We should probably prevent this as this might be used for attacks. (e.g. sending a cheque that would bounce to get a real cheque to steal funds).

[mortelli]

let's discuss the possible ways to do this.

1. go back to cheque request messages. doesn't seem like the best idea, since it caused us enough trouble in the first place to abandon it. as standard (non-malicious) behavior, nodes should probably take the initiative to settle their own debts. but maybe this is worth re-discussing.
2. upon receiving a cheque, check that the balance with the issuer is positive on the receiving end before cashing it. this means: before you cash a cheque, make sure that the issuer owes you something. seems like a good approach, although somewhat naive; this only rules out victims with negative balances towards the attacker. as @ralph-pichler mentioned, if the victim is owed 10 units, an attacker could send a cheque for 10,000 units—which could bounce after the attacked node has already sent a valid cheque back to the attacker in order to offset this gross imbalance.
3. upon receiving a cheque, check that the balance matches the cheque amount before cashing it. this is more robust, but doesn't take into consideration that balances can be—in the best case, slightly—out of sync. seems too rigid a rule to me, it's an arguably hard condition to be met.
4. upon receiving a cheque, check that the balance matches the cheque amount, but with a certain slack. this seems like the more reasonable solution, but it raises the question of exactly how much difference we will be willing to tolerate.

the problem with option # 4 is that once nodes are out of sync with a big enough difference, it seems like they won't be able to settle it through cheques any longer; only through exchanging chunks in the debt-reducing direction.

[ralph-pichler]

I am for a modified version of 2. We allow cheques only if after the balance adjustment we still don't owe anything (or only a tiny amount). If a cheque is rejected due to asymmetric balances it's still ok. After all, the pending cheque is still created and will be resent at a later date when more traffic has occurred.

[mortelli]

I am for a modified version of 2. We allow cheques only if after the balance adjustment we still don't owe anything (or only a tiny amount). If a cheque is rejected due to asymmetric balances it's still ok. After all, the pending cheque is still created and will be resent at a later date when more traffic has occurred.

you're right, i hadn't thought about how pending cheques fit into this whole thing. i think this completely discards option # 3 then.

so if i understand this correctly: you're saying nodes should accept cheques if their balance towards the issuer minus the cheque amount is either any positive number or a "small" negative number.

example scenarios:

• i'm owed 10,000, i receive a cheque for 10,000 → cash the cheque.
• i'm owed 10,000, i receive a cheque for 2,000 → cash the cheque.
• i'm owed 10,000, i receive a cheque for 10,500 → cash the cheque. (suppose 500 is small, although in principle this isn't evident)
• i'm owed 10,000, i receive a cheque for 20,000 → don't cash the cheque.
• i owe 1,000, i receive a cheque for 1,000 → don't cash the cheque.
• i owe 1,000, i receive a cheque for 10 → don't cash the cheque.

[ralph-pichler]

Yes, if by "cash" you mean accept / confirm.

[mortelli]

Yes, if by "cash" you mean accept / confirm.

Yes, good clarification. A more correct term would be "accept and be willing to cash".

[mortelli]

Can we start talking about the balance tolerance in concrete numbers then?

Maybe it should be a percentage of the payment threshold... something like 5%, 10%? At least to start with; we can adjust it empirically later, I think.

[mortelli]

The current implementation is causing a problem in some of the simulation tests, in particular the TestPingPongChequeSimulation and TestMultiChequeSimulation functions.

In the case of TestPingPongSimulation, a message which will trigger the sender to also write a cheque to the receiver is sent, but the cheque message is received before the message that triggered it.

Since both nodes start out at a balance of 0, the node which receives the cheque will reject it, as it would put it into debt. This causes the simulation test to fail.

[Eknir]

#1983 is already open for quite a while, but seems to have issues being merged. I reached out to @mortelli , offering him help to get it merged.

[mortelli]

#1983 has been merged.

however, we need to follow up on these issues:

• investigate rare TestMultiChequeSimulation bug #2078
• iterate debt cheques prevention #2093