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
As an Ethereum user, I want to sync Besu on Kintsugi to the tip of the chain so that I can help test the merge
Acceptance Criteria
Besu should finish syncing to the latest block height, when running against the parameters in the Kintsugi testnet guide
Steps to Reproduce (Bug)
Download source and compile Besu with Java 11 against the c6eddef39fabdf2cf5ea98cf0b8d98402c5b9147 commit in the "merge" branch (listed below)
Run Besu with the parameters listed in the Kintsugi testnet guide (linked earlier). I also set the --miner-coinbase flag to the zero address because of this bug
Expected behavior: Besu should finish syncing at some point, and the block height should match the block height in the Kintsugi block explorer.
Actual behavior: Besu thinks it is done syncing, but the block height it reports over HTTP RPC is pretty far behind the actual tip
According to the Besu RPC server, the node thinks it is done syncing and the block height is much lower than what it should be.
I assume 0x2824E is the hexadecimal block height (which is 164,430 in b10). Meanwhile, the actual blockheight is in the 242k range
Detailed logs at the bottom of this issue
Frequency: [What percentage of the time does it occur?]
This happened 2/2 for me. After the first time, I deleted my VM and started over, same result the 2nd time
Description
As an Ethereum user, I want to sync Besu on Kintsugi to the tip of the chain so that I can help test the merge
Acceptance Criteria
Steps to Reproduce (Bug)
c6eddef39fabdf2cf5ea98cf0b8d98402c5b9147
commit in the "merge" branch (listed below)Expected behavior: Besu should finish syncing at some point, and the block height should match the block height in the Kintsugi block explorer.
Actual behavior: Besu thinks it is done syncing, but the block height it reports over HTTP RPC is pretty far behind the actual tip
According to the Besu RPC server, the node thinks it is done syncing and the block height is much lower than what it should be.
I assume 0x2824E is the hexadecimal block height (which is 164,430 in b10). Meanwhile, the actual blockheight is in the 242k range
Detailed logs at the bottom of this issue
Frequency: [What percentage of the time does it occur?]
This happened 2/2 for me. After the first time, I deleted my VM and started over, same result the 2nd time
Versions (Add all that apply)
Software version: [
besu --version
]besu/v22.1.0-RC2-dev-c6eddef3/linux-x86_64/openjdk-java-11
Java version: [
java -version
]openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment (build 11.0.13+8-Ubuntu-0ubuntu1.20.04)
OpenJDK 64-Bit Server VM (build 11.0.13+8-Ubuntu-0ubuntu1.20.04, mixed mode, sharing)
OS Name & Version: [
cat /etc/*release
]DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.3 LTS"
NAME="Ubuntu"
VERSION="20.04.3 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.3 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
uname -a
]Linux kintsugi-vm 5.11.0-1025-azure #27~20.04.1-Ubuntu SMP Fri Jan 7 15:02:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
vmware -v
] N/Adocker version
] N/AAdditional Information
More logs
The text was updated successfully, but these errors were encountered: