-
Notifications
You must be signed in to change notification settings - Fork 264
EIP-55 checksummed addresses not supported #73
Comments
Due to problem with launch-kit-backend, documented at 0xProject/0x-launch-kit-backend#73
Due to problem with launch-kit-backend, documented at 0xProject/0x-launch-kit-backend#73
Previously these teses were using 0xorg/launch-kit-ci, but that was a one-off thing created just for CI, back before there was a regularly maintained docker image of Launch Kit. Changed to use 0xorg/launch-kit-backend since it's regularly maintained/updated. Because the -backend image is using a different Linux distribution (Alpine), the commands used to wait for ganache startup also had to change. The tag used, 74bcc39, is provisional due to the pending Issue at 0xProject/0x-launch-kit-backend#73 . When that issue is resolved, the tag suffix on the imag name should be removed.
Testing against that PR #74 (as published to dockerhub
At the moment, this is enough to unblock the work I'm doing. I changed my SRA client example to just do |
Previously these teses were using 0xorg/launch-kit-ci, but that was a one-off thing created just for CI, back before there was a regularly maintained docker image of Launch Kit. Changed to use 0xorg/launch-kit-backend since it's regularly maintained/updated. Because the -backend image is using a different Linux distribution (Alpine), the commands used to wait for ganache startup also had to change. The tag used, 74bcc39, is provisional due to the pending Issue at 0xProject/0x-launch-kit-backend#73 . When that issue is resolved, the tag suffix on the imag name should be removed.
Due to problem with launch-kit-backend, documented at 0xProject/0x-launch-kit-backend#73 , we need to checksum the makerAddress, in the order retrieved from the relayer, before filling it, otherwise Web3.py gives this error: InvalidAddress('Web3.py only accepts checksum addresses. The software that gave you this non-checksum address should be considered unsafe, please file it as a bug on their platform. Try using an ENS name instead. Or, if you must accept lower safety, use Web3.toChecksumAddress(lower_case_address).', '0x5409ed021d9299bf6814279a6a1411a7e866a631')
* Install Py packages in dep. order, not in parallel Install Python packages in dependency order, not in parallel. * sra_client.py: Add `./setup.py clean` * Fix python package dependency ordering... ...and include a script to produce the proper ordering. * sra_client.py: reformat whitespace in doctest * contract_wrappers.py: don't auto-import wrappers This was discovered while minimizing CircleCI steps to dianose a problem with running the Launch Kit Backend in CircleCI. These classes should be imported via the zero_ex.contract_wrappers.exchange and zero_ex.contract_wrappers.erc20_token modules, respectively. We permitted importing them from just zero_ex.contract_wrappers back when they were the only wrappers we had, but now that we have so many different contracts being wrapped, this is just another list to keep manually updated (which, obviously is error prone, since it slipped through the cracks already), so it's better to just not support this type of import. * abi-gen/Py: doc contract method attributes Without this, generated documentation was not including the class members that represent the contract methods, rendering the usage unclear. * sra_client.py: disable tests in CI * abi-gen/Py: strip repeated spaces from devdoc * contract_wrappers.py: gen docs for all wrappers... ...except for the dummy tokens. * sra_client.py/test: change launch kit docker image Previously these teses were using 0xorg/launch-kit-ci, but that was a one-off thing created just for CI, back before there was a regularly maintained docker image of Launch Kit. Changed to use 0xorg/launch-kit-backend since it's regularly maintained/updated. Because the -backend image is using a different Linux distribution (Alpine), the commands used to wait for ganache startup also had to change. The tag used, 74bcc39, is provisional due to the pending Issue at 0xProject/0x-launch-kit-backend#73 . When that issue is resolved, the tag suffix on the imag name should be removed. * Migrate from Web3.py 4.x to 5.x * sra_client.py: checksum address in doctest Due to problem with launch-kit-backend, documented at 0xProject/0x-launch-kit-backend#73 , we need to checksum the makerAddress, in the order retrieved from the relayer, before filling it, otherwise Web3.py gives this error: InvalidAddress('Web3.py only accepts checksum addresses. The software that gave you this non-checksum address should be considered unsafe, please file it as a bug on their platform. Try using an ENS name instead. Or, if you must accept lower safety, use Web3.toChecksumAddress(lower_case_address).', '0x5409ed021d9299bf6814279a6a1411a7e866a631') * Update CHANGELOGs * sra_client.py: make CHANGELOG be REVESE chrono. Formerly CHANGELOG was in chronological order. Now it's in reverse chronological order. * abi-gen/Py: fix missing space in sanitized devdoc
In publishing the latest versions of the 0x Python packages, we're migrating from v4 to v5 of Web3.py. v5 will not accept any non-checksummed addresses for any inputs to any contracts.
We have an end-to-end tested example of the Python SRA client, which creates an order, posts it to the Launch Kit backend, retrieves the order from the order book, and then fills the order. After migrating this example to v5 of Web3.py, this test is failing with the following output:
The reason for the failure is that the example is sending a checksummed (mixed case) address for the
makerAddress
, and this build of Launch Kit is verifying that address against an old version of@0x/json-schemas
. In version 3.1.1.1 the schemas were updated to allow for mixed case addresses.However, simply accepting mixed case addresses in posting an order will not be sufficient to get these Python SRA client example working, because after posting an order, the example retrieves the order and fills it. So Launch Kit must also be changed to store the orders in mixed case as well, such that the retrieval will yield the case given in the posting.
The text was updated successfully, but these errors were encountered: