-
-
Notifications
You must be signed in to change notification settings - Fork 194
Ethereum transaction signature problem #236
Comments
Far as I can tell, your diff is a no-op. The result should be the same. You can check this pretty easily: duplicate the piece of code and print out For a minimal case, you can examine the result of |
Before the conversion sig_r is a bytearray and just an integer after. After rpl.encode I get completely different signature (with and without the change) Can you also try? |
AFAIK rlp is not Py3 compatible. If that's true, the issue needs to be
addressed there and python-trezor requirement set to the fixed version.
|
I'm not sure what behavior the upstream intended, but it's different between py2 and py3, hence ethereum/pyrlp#49 We could also fix this on our side by explicitly converting the bytearrays to bytes when returning the signature. As bytearrays are mutable, that might even be a good idea. |
@matejcik Let's wait if they merge the fix and push it to PyPI (in, let's say, a few days). If not, I propose to fix it in our code like you suggest. |
@prusnak I'll do some refactoring of our code in the meantime, and if it turns out I like returning bytes instead of bytearrays, I'll do that too. Better to be doubly sure :) |
👍 |
Thanks guys! |
A difference is that the integer variant strips leading zeros. I was always under the impression that r and s should be encoded as 32-byte buffers with leading zeros, but checking the yellow paper again it seems I was wrong. Is this a bug in the Trezor code? It should not be too difficult to brute-force a transaction where the signature has a leading zero byte to test his. |
…rray. This makes more sense, because bytes are immutable and callers have no business mutating structures from the wire anyway. Incidentally this should fix issue #236, where rlp library would treat bytes and bytearrays differently and produce invalid structures in our usecase. Also very minor nitpicks and code cleanup for neater typing.
this should now be fixed on our side as well. |
I'm still getting the following error when trying to post signed transactions on Etherscan (http://ropsten.etherscan.io/pushtx) (Ethereum Ropsten). Error! Unable to broadcast Tx : {"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid RLP.","data":"RlpExpectedToBeData"},"id":1} Posting on MyEtherWallet (#offline-transaction) provides a similar error: rlp: expected input string or byte for *big.Int, decoding into (types.Transaction)(types.txdata).R As far as I can tell, all my dependencies are good. I'm using a Raspberry Pi3. I am able to complete this operation successfully on MacOs computer without issues. The main difference i see is the MacBook is running Eth-Hash 0.1.2 instead of 0.1.4 (on the Rasp Pi). Although at second glance, it looks like ethereum reverted back from 2.3.1 to 1.0.8. |
manually installing eth-hash to 0.1.2 and ethereum to 2.3.1 doesn't help. All the packages are the same yet running the exact same command outputs two different Signed Raw Transactions. |
Hi,
It seems like when moving to python3 the ETH signature signed by the code is wrong (at least to me).
Maybe the differences in decode/encoding methods between python2 and python3
I'm referring to this part of the code:
Something like this resolved me the issue
![screen shot 2018-03-13 at 17 16 43](https://user-images.githubusercontent.com/37340769/37350804-5eb079fc-26e2-11e8-9a40-a7ff9f14c632.png)
Did anyone else encounter it or is it just my environment?
Can you please comment?
The text was updated successfully, but these errors were encountered: