Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow `taker` to be different from `sender` with optional `taker` signature #18
In the current implementation of the
This change would allow for much easier implementations of
In addition, this change greatly simplifies logic for relayers using the matching strategy. There is now a clear distinction between the
For the purposes of this proposal it makes sense to rename the
The above approach is a naive solution to this issue. Realistically, the taker needs to be able to choose which method is being called in order to have the full range of functionality that a taker calling the Exchange contract directly would have. This is slightly tricky because all of the Exchange functions take different arguments (this could be solved with #16).
A slightly different approach (and replacement for #16) involves creating a new message type: a 0x transaction message. This would be represented as two (probably tightly packed) byte arrays. The first would contain the methodId and function arguments of the desired function to call, and the second would contain a signature of the hash of the data (from the taker in this case). It could look something like the following:
We discussed the potential for a Relayer (or anyone if the sender is not set) to mount a replay attack with this proposed improvement.
In this scenario, a Taker would sign
Any listener (or malicious Relayer if sender is set) could re-submit this transaction N times up until the order is filled.
A simple replay attack prevention scheme would be to store
Here is a simpler to implement version of my last comment using
This has already been implemented and will be included in the next upgrade (scheduled for September).