 |
Today at 12:01:41 AM |
|
Something we ran into while testing a RandomX + ASERT chain on an isolated testnet. Posting in case it helps anyone else running ASERT.
Our test genesis is dated well before the chain actually started, so ASERT’s schedule was far behind and difficulty sat at the floor. At that difficulty the miner was producing dozens of blocks a second, so block timestamps raced ahead of the real clock until they hit Bitcoin Core’s 2-hour future limit (time-too-new).
Once that happened, building a new block template failed, and our built-in miner treated that as fatal and stopped for good, while the node itself kept running fine. We changed the miner to wait a second and retry, logging one warning a minute. At the limit it now keeps mining at a few hundred blocks a minute until the chain catches up with the schedule.
A couple of questions for anyone who’s run ASERT chains:
-Did you regenerate genesis right at launch to avoid this backlog, or just accept a period at the floor?
-Once the chain catches up while timestamps are still about 2 hours ahead, how did ASERT behave for you? We’re expecting block times to overshoot the target for a while, and we’re measuring it now.
OpalBit Project
|
