-
Notifications
You must be signed in to change notification settings - Fork 20.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Geth --dev
does not work with CancunTime
#29564
Comments
Looks like this is related to #29475 but the transaction indexing never actually resolves for me, as one user claims it does in that issue. Also, due to issue #29404, I can't call |
Duplicate of #29475. |
|
@jwasinger yeah I figured that was not intended behavior. Just poked around enough to get it to "work" until it was resolved. Thanks for the attention here. So that fix was not a part of |
You probably have to try the latest master branch. #29469 is not backported to 1.13.15 |
Ok thanks. That makes a lot of sense then. I'm not at my computer but it did work on |
I'll close this if the original issue seems solved. If there's some followup, feel free to open a new issue (or reopen this). |
System information
Geth version:
1.13.11
-1.13.15
CL client & version:
--dev
(simulated beacon)OS & Version: OSX Ventura 13.5.2
Commit hash : (if
develop
)Expected behaviour
I wouldn't expect
Invalid parameters
when performing sealing work and for transaction indexing to not get stuck.Actual behaviour
Logs that differ from Shanghai rules:
Indefinite indexing:
Steps to reproduce the behaviour
At the present moment, I need to set
terminalTotalDifficulty
in genesis to-1
anddifficulty
to0
in order to trick it to even trigger Shanghai rules. Nothing else seems to work. Since there's a check fordifficulty > terminalTotalDifficulty
and difficulty seems to need to be0
at the genesis for the rules to trigger, I had to try to setterminalTotalDifficulty
to-1
and that somehow seems to work.All other fork rules are set as expected, as you can see from the logs below they are picked up. I just don't believe they are being triggered.
I am using
dev.period
==1
. Sending any transaction and attempting to get the receipt does not work as it gets stuck indexing forever. But theinvalid parameters
when performing sealing work also aren't present under the working Shanghai rules. Turning on Cancun time seems to trigger all of this.Backtrace
... polling
eth_getTransactionReceipt
never leaves indexing statusThe text was updated successfully, but these errors were encountered: