Add refundOnFraud #73
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Future-proofs the comparison. With field-by-field comparison, when a new field is added to the Ticket struct, ticket comparison must be updated.
lalexgap
reviewed
Dec 15, 2021
lalexgap
reviewed
Dec 15, 2021
lalexgap
reviewed
Dec 15, 2021
lalexgap
reviewed
Dec 15, 2021
| import { L2, L2DepositStruct } from "../contract-types/L2"; | ||
| import { TicketsWithIndex } from "../src/types"; | ||
| import { hashTickets, signData } from "../src/utils"; | ||
|
|
||
| const gasLimit = 30_000_000; |
There was a problem hiding this comment.
nit but we could throw this in a common file shared between tests.
There was a problem hiding this comment.
Good call, let's do that once we have more than one test file.
lalexgap
reviewed
Dec 15, 2021
Co-authored-by: Alex Gap <[email protected]>
Comment on lines
+157
to
+159
| bytes32 message = keccak256( | ||
| abi.encode(TicketsWithIndex(fraudStartNonce, fraudTickets)) | ||
| ); |
There was a problem hiding this comment.
This ought to be factored into some common utils library contract, since the exact same computation needs to be computed in both L1 and L2.
| (bool sent, ) = tickets[i].l1Recipient.call{ | ||
| value: tickets[i].value | ||
| }(""); | ||
| require(sent, "Failed to send Ether"); |
There was a problem hiding this comment.
FYI this is a critical security vulnerability. Alice can submit a ticket with a contract address that rejects all incoming eth transfers. This prevents everyone from calling refundOnFraud.
There was a problem hiding this comment.
That's a good call. Contract fund distribution needs to be refactored to:
- Factor out this logic.
- FIx the security concern
- Add erc20 support
This was referenced Dec 16, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #59.
There are 2 cases of fraud:
tis created on deposit. The ticket is authorized as part of a batch. The liquidity provider (LP) also signs another batch that contains a ticket with the same index astbut different data.2. Same as above buttis never authorized.In the second case, a new batch is created on fraud proof. The batch includes all tickets from the last authorized ticket (exclusive) to the ticket that is being "cheated" (inclusive).On more thought, it doesn't seem like we need to take care of the second case. The customer can: