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

[RFC] What to do about Bad Behavior? #38

Open
1 of 3 tasks
wtogami opened this issue May 3, 2022 · 1 comment
Open
1 of 3 tasks

[RFC] What to do about Bad Behavior? #38

wtogami opened this issue May 3, 2022 · 1 comment

Comments

@wtogami
Copy link
Contributor

wtogami commented May 3, 2022

This is a Request for Comments.

There are some corner cases in which PeerSwap swap requesters can be lied to by swap providers into paying more fees than necessary. Such bad behaviors are easy to detect. The code should be able to detect these cases and notify via logs and maybe also a flag within the swaps database. This could be inputs into a later node reputation tracker or something.

Note: These bad behavior situations are not considered "exploits" per se because they 1) only affect the requester, not automated providers 2) only by a tiny amount per swap 3) and once you know a peer is misbehaving the software can easily stop future swaps with that peer 4) there are potential designs for transferable lie proofs signed by the misbehaving node's pubkey.

Examples of bad behavior:

  • check onchain balance on swap-out request #34 the swap provider can lie to the swap-out requester it has sufficient UTXO's available thereby inducing them to pay the LN prepayment invoice only to immediately cancel. The requester's peerswap code should detect this pattern of misbehavior. DONE peerswap prints a warning.
  • This could happen very rarely by a legitimate provider in rare cases like a race condition (?), in which case if it happened by accident there could be an immediate refund invoice. Consider for the next version of the protocol spec.
  • The swap provider could ask for an excessive amount of sats far in excess of the actual after-the-fact on-chain cost. To an extent this is unavoidable due to normal variations in the feerate estimator however the requester's node should log the discrepancy each time it happens in order to detect a pattern of behavior.

Other examples possible?

@wtogami
Copy link
Contributor Author

wtogami commented May 10, 2022

Proposal:
Print warnings when bad behavior is detected and auto-disable further swaps from that particular pubkey. So they can cause you to waste some tx fees but only once. Given that they paid onchain fees to open the channel it isn't costless to grief attack in this manner so this protection should be sufficient.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant