You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you find a bug in your client implementation due to this project, please be so kind as
to add it here to the trophy list. It could help prove that hive is indeed a useful tool
for validating Ethereum client implementations.
go-ethereum:
Genesis chain config couldn't handle present but empty settings: #2790
Data race between remote block import and local block mining: #2793
Bug in p2p with bonding nodes algorithm found by Hive: #1894
Difference in return value for 'r' parameter in getTransactionByHash: #2372
CREATE/CREATE2 behavior when account already has max nonce #3698
Blake2 performance issue with non-vectorized code #3837
Contributions
This project takes a different approach to code contributions than your usual FOSS project
with well ingrained maintainers and relatively few external contributors. It is an
experiment. Whether it will work out or not is for the future to decide.
We follow the Collective Code Construction Contract (C4), code contribution model,
as expanded and explained in The ZeroMQ Process. The core idea being that
any patch that successfully solves an issue (bug/feature) and doesn't break any existing
code/contracts must be optimistically merged by maintainers. Followup patches may be used
for additional polishes – and patches may even be outright reverted if they turn out to
have a negative impact – but no change must be rejected based on personal values.