Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically setting hard-deposits with peers #43

Closed
Eknir opened this issue Jul 5, 2019 · 1 comment
Closed

Automatically setting hard-deposits with peers #43

Eknir opened this issue Jul 5, 2019 · 1 comment
Labels
attack-vector simpleSwap Related to SimpleSwap.sol

Comments

@Eknir
Copy link
Collaborator

Eknir commented Jul 5, 2019

When reviewing the SimpleSwap.sol code with @holisticode , we came up with a potential vulnerability of SimpleSwap. If exploited, an attacker can lock the funds of the checkbook owner for a given period (equal to the hardDeposit timeout), resulting in the checkbook owner not being able to economically engage with other nodes for this period.

Assuming:

  • Harddeposits are the only way to guarantee solvency of the checkbook for a node
  • A node requires solvency of a checkbook to in order to engage in the SWAP protocol (start delivering chunks back and forth)*

Then:
For a honest node who expects to receive a check (A) and does not want a profit that approaches zero, this node first wants to see a hard-deposit guaranteed for him in the checkbook of a peer (B).
As B wants to start using SWARM, he has to commit himself to funding set a hard deposit aside for at least one (but probably multiple peers).

Attack:
Evil node C tricks B into believing that he/she needs a hard-deposit. C can have multiple nodes and the cumulative hard-deposits to all C's can be sufficiently high such that B cannot engage in Swarm anymore without the expected service of C, without topping up again. When this point is reached (can be a very little time if C sets up the attack well), C can stop providing services for B and B has to wait for a period equal to the hardDepositTimeout until she can engage again in SWAP with other nodes. This circle can repeat ad-infinitum.

Consequence:
The attack can disrupt the usability of SWARM for B as it will diminish the resources that B has available from his deposit to spend on rewarding honest nodes at any given time.

*If there is no solvency guarantee, a node should always expect a bankrun on the checkbook of the peer as there is no way of knowing about other outstanding checks. Therefore, once a node has a cheque that is worth a positive sum of money, he should immediately cash out this cheque. A cheques worth is the cumulative value of the check - the gas costs of the cheque. We expect the worth to be negative initially and when the worth is marginally above zero it should be cashed out due to the logic above.

@Eknir
Copy link
Collaborator Author

Eknir commented Jul 5, 2019

@ralph-pichler @zelig , would such an attack be mitigated by with soft deposits?

@Eknir Eknir added the simpleSwap Related to SimpleSwap.sol label Jul 5, 2019
@Eknir Eknir closed this as completed May 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
attack-vector simpleSwap Related to SimpleSwap.sol
Projects
None yet
Development

No branches or pull requests

1 participant