Suggestion: ASERT difficulty adjustment for mainnet — alphanet's 2016-block rule ratcheted 4× four periods in a row #4

Activity

1. Wired4ncer commented on Sep 21, 2026

   

   Wired4ncer

   on Sep 21, 2026

   Author

   More actions

   Follow-up with a PR and two things the original post left thin.

   PR: ecash-com/bitcoin#2 — ASERT as an opt-in rule (EcashAsertAnchorHeight, 0 = off on every network as merged), with the arithmetic kept bit-for-bit to the BCH aserti3-2d spec, unit tests, and a fuzz target. Independently reviewed before filing; the review's findings and what changed are in the description.

   Why Bitcoin's rule is right for Bitcoin and wrong here, in one line: Bitcoin owns its SHA-256 hashrate, so a 2016-block window sees a stable population. A minority chain on the same algorithm borrows it — hashrate that can arrive and leave 100× inside an hour — and a window that long only ever measures the burst.

   The other half of the ratchet, measured on both current networks (explorer data, read 2026-09-21 14:28 CST). The original table showed difficulty chasing bursts up. This is what happens after the burst leaves, which is the part that hurts:

   	betanet	alphanet
   Period start	967,680 (the fork block), 2026-09-19 01:09 CST, difficulty 1.0e9	993,888, 2026-08-24 18:21 CST, difficulty 1.07e9
   2016 blocks took	10.2 h (~18 s/block)	14.9 h (~26 s/block)
   Retarget	×4.00, the cap → 4.0e9 at 969,696	×4.00, the cap → 4.29e9 (2^32) at 995,904
   Block time since	683 s avg over 270 blocks; 772 s over the last 144; 936 s over the last 9	1,349 blocks in 27 days (~29 min avg); last 9 blocks 156 min each; tip 35 h old
   Next retarget	971,712 — 1,746 blocks away, 2–3 weeks at this pace	997,920 — 667 blocks away; ~10 weeks at the recent pace

   Betanet is the cleaner case: the hashrate that mined the first 2016 blocks in ten hours is gone, the residents run 15–55 % slower than the 600 s target, and nothing in the rule can respond for another two to three weeks. Alphanet's exit was partly deliberate (miners moved to betanet at the fork), but the mechanism does not care why hashrate leaves — it is stuck on a difficulty set for a population that isn't there, for as many weeks as 667 blocks take.

   On the two resident-hashrate figures in the original post: 40 PH/s was measured in a lull between bursts on 08-24; ~8 PH/s was the post-order measurement on 08-25 once the rented hashrate had fully left. Different days, both real; the lower one is the number that matters for recovery time.

   Under ASERT with a one-day half-life, betanet's 4.0e9 would have decayed back toward its real hashrate within about a day of the burst leaving, block or no block.
2. dims8948-hub commented on Oct 4, 2026

   

   dims8948-hub

   on Oct 4, 2026

   More actions

   Suggestion, not a bug report. Filed here because issues are disabled on ecash-com/bitcoin.

   Summary

   betanet (ca64033) keeps Bitcoin's difficulty rule unchanged apart from the reset at EcashHeight: retarget every 2016 blocks, clamped to 4× either way. On a minority SHA-256 chain that shares its algorithm with Bitcoin, this rule ratchets. Alphanet showed it live. Worth considering ASERT (the aserti3-2d design BCH has run since Nov 2020) for mainnet, anchored at the fork block.

   What alphanet measured

   Four consecutive retargets after the alpha fork, every one pinned at the 4× cap (public chain data):

   Period avg block time difficulty factor
   985824–987840 7.2 s 4,194,304 → 16,777,216 4.00×
   987840–989856 18.3 s 16,777,216 → 67,108,864 4.00×
   989856–991872 39.8 s 67,108,864 → 268,435,456 4.00×
   991872–993888 14.3 s 268,435,456 → 1,073,741,824 4.00×
   Between bursts the resident hashrate was roughly 40 PH/s (~115 s/block). Each burst mined a full period in hours and left; the cap meant difficulty only ever chased up. Once the bursts stop, the residents inherit a difficulty set for 100× their hashrate and a 2016-block period that takes weeks to months to work off. At ~8 PH/s a period at 2^34 is ~115 days.

   That is the normal case for a chain next to Bitcoin, not an edge case: rented SHA-256 hashrate can move in and out 100× within an hour.

   Why ASERT

   • No window, so no ratchet. Difficulty is a function of how far the chain is ahead of or behind its ideal schedule since the anchor. After a burst leaves, difficulty decays back on the clock, whether or not blocks are found. The 4×-per-period trap cannot occur.
   • The fork reset is already the anchor. EcashHeight + EcashForkBits are exactly ASERT's two anchor parameters, so this is a replacement CalculateNextWorkRequired, not a redesign, and pre-fork Bitcoin history stays under the old rule untouched.
   • Proven in the same situation. BCH is a minority SHA-256 chain beside Bitcoin; ASERT has run there for five years without the daily oscillation its earlier 144-block average had.
   • Integer-only reference implementation with test vectors exists (BCH aserti3-2d spec), so it can be ported and checked, not reinvented.

   Suggested parameters: half-life around 1 day (BCH uses 2; ECX's hashrate is smaller and burstier, so faster recovery matters more), and MAX_FUTURE_BLOCK_TIME cut from 2 h to ~10 min, since any per-block DAA makes timestamps a lever.

   Second choice if simplicity wins: LWMA (N≈144). Things I'd avoid: an EDA-style emergency trigger (BCH 2017 — miners stalled it on purpose then burst at low difficulty) and a plain moving average (oscillates under hashrate switching).

   Trade-off, stated plainly

   A fast DAA shortens the low-difficulty window at each fork, which some miners (us included) currently benefit from. I'd still rather mine a chain whose difficulty tracks its real hashrate.

   Happy to put together a PR against betanet/mainnet if that would be useful.