Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
In partnership with Protocol Labs, we’re excited to welcome builders from everywhere to APOLLO, your mission control to engage with the builder…
We’re excited to publically announce that Matic Network is partnering with Gitcoin to launch the Build-n-Earn Program – assisting dApps t…
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
Geth returns 0x0 in the mixHash field when running against Rinkeby (also POA). Parity connected to Kovan doesn't return the field at all. While you could argue that parity Kovan should be fixed, I think doing such a fix on the server is more involved than doing it on the client side. However this is a discussion that should be had.
It would be great if the go-ethereum ethclient would gracefully ignore the field not being present (i.e. treat it as a null value). I don't know if there's an easy way to distinguish between POA/POW chains and only error out when interacting with a POW chain and the field is missing.
Please also refer to the parity-ethereum issue where this is discussed: https://github.com/paritytech/parity-ethereum/issues/8841
#### System information
Geth version: 1.8.15
OS & Version: Linux
#### Expected behaviour
I should be able to use ethclient to communicate with a parity node connected to the kovan POA testnet.
#### Actual behaviour
Geth returns 0x0 in the mixHash field when running against Rinkeby (also POA). It would be great if the go-ethereum ethclient would gracefully ignore the field not being present (i.e. treat it as a null value). I don't know if there's an easy way to distinguish between POA/POW chains and only error out when interacting with a POW chain and the field is missing.
#### Steps to reproduce the behaviour
Submit a transaction to a parity node connected to kovan. The implications of this bug are identical to #3230 but #3230 was due to an incompatibility of the parity client in general when this field was added to the endpoint in the first place.