by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 03 04:25
    dfinzer commented #1629
  • Jul 03 01:23
    pipermerriam commented #1634
  • Jul 03 01:04
    pipermerriam commented #1678
  • Jul 01 22:59
    njgheorghita review_requested #1652
  • Jul 01 22:59
    njgheorghita review_requested #1652
  • Jul 01 22:59
    njgheorghita commented #1652
  • Jul 01 22:57
    njgheorghita edited #1652
  • Jul 01 22:54
    njgheorghita edited #1652
  • Jul 01 22:54
    njgheorghita ready_for_review #1652
  • Jul 01 22:54
    njgheorghita edited #1652
  • Jul 01 22:40
    njgheorghita synchronize #1652
  • Jul 01 22:36
    njgheorghita synchronize #1652
  • Jul 01 22:34
    njgheorghita synchronize #1652
  • Jul 01 22:29
    njgheorghita synchronize #1652
  • Jul 01 22:27
    njgheorghita synchronize #1652
  • Jul 01 22:21
    njgheorghita synchronize #1652
  • Jul 01 22:19
    njgheorghita commented #1652
  • Jul 01 21:38
    njgheorghita synchronize #1652
  • Jul 01 21:38
    njgheorghita synchronize #1652
  • Jul 01 21:36
    njgheorghita synchronize #1652
Jason Carver
@carver
You're trying to manually build a message in solidity, but you're building it a different way than eth_sign does, so the hash doesn't match.
Forget about the signature for now, and just try to get the message hash to match. Specifically try to get message from withdraw() to match messageHash from signed_message. To do that, first understand eth_sign as I mentioned here: https://stackoverflow.com/a/62141323/8412986
Abhishek Kumar
@kuabhish
Yes @carver that is exactly what is happening: the messagehash created in solidity matches sig value mentioned above but it doesn’t match the messagehash from the signed message.
Jason Carver
@carver
Right, so you need to build message in solidity with the extra content of the prefix I mentioned in the link above
Abhishek Kumar
@kuabhish

@carver As you said I used the prefix

    function prefixed(bytes32 hash) internal pure returns (bytes32) {
        return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash));
    }

and

bytes32 message = prefixed(keccak256(abi.encodePacked(recipient , amount)));
        emit Message(message);

Still the message is different.

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> Looks like maybe an un-needed extra hash in there before prefixing? I can't dig in deeper to help you debug right now. But you have the right test now. You'll know when you've got it working, because the message hashes will match.
Abhishek Kumar
@kuabhish

@carver @Eth-Gitter-Bridge

        bytes memory something = abi.encodePacked(recipient , amount);
        bytes32 message = keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n",something.length ,something));
        emit Message(message);

I don't know if this is right way to pack the arguments or not. But the output doesn't match

Abhishek Kumar
@kuabhish
The value generated by the keccak256(abi.encodePacked(recipient , amount)) and Web3.soliditySha3( [ 'address' , 'uint256' ] , [ Web3.toChecksumAddress("0x516510e3B61F3D425Fe5F52D7492E8950C8647D7") , 500 ]) are same ..
Abhishek Kumar
@kuabhish

@carver

msg = Web3.soliditySha3( [ 'address' , 'uint256' ] , 
                   [ Web3.toChecksumAddress("0x516510e3B61F3D425Fe5F52D7492E8950C8647D7") , 500])

message = encode_defunct(text=msg.hex())
message_hash = Web3.keccak(
    b"\x19Ethereum Signed Message:\n" +
    bytes(f"{len(message.body)}", encoding='utf-8') + message.body
)
message_hash
HexBytes('0xbf8efb471491d386f2121dda534d499aa84043532aad52af5ee0deb6e74a7c86')

I found this message_hash == signature.messagehash..

So, I tried using the same params in the solidity like :

keccak256(abi.encodePacked( "\x19Ethereum Signed Message:\n" , "66" , hash ))

But then I checked the values :

b"\x19Ethereum Signed Message:\n" +bytes(f"{len(message.body)}", encoding='utf-8') + message.body == b'\x19Ethereum Signed Message:\n660xbccf9f6664ef1f771e15d448d5cccf44e50b6c71a510dc2cb13935e316685e22'

but

abi.encodePacked( "\x19Ethereum Signed Message:\n" , "66" , hash ) == 0x19457468657265756d205369676e6564204d6573736167653a0a3636bccf9f6664ef1f771e15d448d5cccf44e50b6c71a510dc2cb13935e316685e22
So, is this abi.encodepacked causing problem?? If yes how can this be solved...
Or are these byte values equal.. ?
Jason Carver
@carver

Okay, so now we're starting to run into the reason that this warning is in the docs:

Consider the w3.eth.sign() approach be deprecated.

Different implementations actually implement this in different ways
How the length is implemented is a little sketchy
So this is why I was recommending using the "intended validator" approach
Abhishek Kumar
@kuabhish

Hey @carver
As you had suggessted I tried

from eth_account.messages import encode_defunct, encode_intended_validator
msg = Web3.soliditySha3( [ 'address' , 'uint256' ] , 
                   [ Web3.toChecksumAddress("0x516510e3B61F3D425Fe5F52D7492E8950C8647D7") , 500])
message = encode_intended_validator(Web3.toChecksumAddress("0x09c1814a3c53c025f354a9d7b88e28a084d0f162"),
                                    hexstr=msg.hex())
print("message" , message)
signed_message = w3.eth.account.sign_message(message, private_key=private_key)

But this time the signed_message.messagehash and what i got from solidity are diffrent :(

Voith Mascarenhas
@voith
@kuabhish If I had to figure this out then I would read the source code of eth-accounts:
https://github.com/ethereum/eth-account
Abhishek Kumar
@kuabhish
ohh great .. thanks ..
Abhishek Kumar
@kuabhish
@voith checked the code a little ,, but couldn't figure out where the difference is..
Voith Mascarenhas
@voith
did you go through the tests?
Abhishek Kumar
@kuabhish

@carver I also used this https://eips.ethereum.org/EIPS/eip-191

and so made a little code change :

keccak256(abi.encodePacked(byte(0x19),byte(0),address(this),destination, value, data, nonce));

Still didn't match

did you go through the tests?

I forgot .. i ll check tyhe tests now ..

Abhishek Kumar
@kuabhish
@voith the tests gave a good insight hoe it works ,, thanks man
Ben Hauser
@iamdefinitelyahuman
hey web3py team.. right now you're raising a ValidationError when a POA network returns >32 bytes of extraData and the geth_poa_middleware isn't active. I want to handle this automatically in Brownie.. when connecting to a new network, query an endpoint and if this error is raised, add the middleware. I can do so by examining at the string of the ValidationError but that feels brittle. Wondering if you'd be open to instead raising a new exception, POAValidationError or ExtraDataError? This exception can subclass ValidationError so the change won't break anything, and this way there is a much stronger approach for catching the specific error.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> Yup, something like an ExtraDataLengthError that subclasses ValidationError seems reasonable 👍
Ben Hauser
@iamdefinitelyahuman
@carver thanks! i'll make a PR shortly
Abhishek Kumar
@kuabhish

Hi, guys

var hash = "0x" + abi.soliditySHA3(
        ["address", "uint256"],
        ["0x516510e3B61F3D425Fe5F52D7492E8950C8647D7", 500]
    ).toString("hex");
var signature = web3.eth.accounts.sign( hash , privateKey );

I was able to solve my issue by using nodejs .. using this code the signature.messagehash == solidity message hash.. But I wanted to write the Api in python only.. Why can't i solve it with python??

Marc Garreau
@marcgarreau
glad you have some form of solution @kuabhish. we’re all juggling a few things at once; if you can write up an issue with your best understanding of the problem, we would appreciate it. that makes the history of context easier to track without scrolling through Gitter.

======

web3.py v5.11.0 released :rocket: https://web3py.readthedocs.io/en/latest/releases.html#v5-11-0-2020-06-03

Thanks to contributors @palango @iamdefinitelyahuman @cygnusv @cryptoscopia :muscle:

Abhishek Kumar
@kuabhish
Ok sure @marcgarreau I will write an issue about it properly.
Marc Garreau
@marcgarreau
thanks!
Abhishek Kumar
@kuabhish
Hey @marcgarreau I have written an issue..
ethereum/web3.py#1667
Please review and tell if it is alright
Marc Garreau
@marcgarreau
that looks like a great starting point, thank you for typing it up.
Abhishek Kumar
@kuabhish
no problem bro
Ben Hauser
@iamdefinitelyahuman
ahh wow guys, thanks for pushing a new release right away! @marcgarreau @carver
didn't expect to have that new exception available right away
Marc Garreau
@marcgarreau
You had good timing ;)
Steven Nevins
@dmintercept
I have a quick question about web3.py would using the filter class save me Infura calls if I want to get all transactions for a specific contract vs iterating through each block?
Adam Bavosa
@realadambavosa_twitter
hello, I am the devrel lead at Compound. did someone need help with code?
Ben Scherrey
@scherrey
Is there a consistent mechanism to estimate average gas prices and their quartiles so transactions can be created with optimal gas prices from inside python? Seems many people are relying on Metamask to give them numbers.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> @realadambavosa_twitter -- yeah someone linked an ABI for a contract that looks malformed: it has a several duplicates of the same function, like admin(), which triggers a validation error in web3.py. I can't think of a good reason for there to be such duplicates in the ABI intentionally, it just looks broken. Maybe you could publish one that doesn't have duplicates? https://compound.finance/docs/abi/mainnet/Comptroller
<carver> > Is there a consistent mechanism to estimate average gas prices and their quartiles so transactions can be created with optimal gas prices from inside python? Seems many people are relying on Metamask to give them numbers.
This is a much harder problem than it sounds like, with a lot of intricacies. There is a gas estimator in web3, but I wouldn't bet production code on it. Frankly, I'm kind of hoping/figuring that EIP-1559 will solve it before we get around to writing a more complicated one.
2 replies
Adam Bavosa
@realadambavosa_twitter
ah ok I understand, I will investigate this issue!
Mikko Ohtamaa
@miohtama
The gas estimator coming from Ethereum nodes is crappy at the best
Mikko Ohtamaa
@miohtama
My recommendation is
1) have an app level configuration where devops can adjust the recommended gas price based on a data feed
2) always set gasLimit for the transactions, as often the estimator cannot determine the spent gas, defaults to the max value 9M GWei and then gives you an absurd estimation like $1000/tx
Adam Bavosa
@realadambavosa_twitter
About Compound's Comptroller ABI: We have identified the issue that causes multiple member references. We will deploy the update and fix the ABI in the docs soon. Thank you @miohtama for bringing this issue to our attention!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> 👍
Mikko Ohtamaa
@miohtama
@realadambavosa_twitter Thank so you much. Do you have a Github issue link? If it is some common pattern other projects may suffer this as well.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> Agree, very unlikely to get to Berlin. Some conversation at https://ethereum-magicians.org/t/eip-1559-fee-market-change-for-eth-1-0-chain/2783/76
Stellarize
@Stellarize
hello i'm new to web3.py hope will get beautiful experience here . thanks