eCash Changed The One Part Of Bitcoin Nobody Touches

eCash is a hard fork of Bitcoin. Its whole pitch is that it changes almost nothing.

It copies Bitcoin's code, keeps the same 21 million coin supply, and keeps the same SHA-256 mining. The one addition is drivechains, which let sidechains hold real coins.

On the night of October 26, 2026, four days before launch, that changed.

Paul Sztorc merged a new difficulty adjustment into the eCash codebase. It is the only rule eCash now changes from Bitcoin, beyond drivechains themselves. He had spent the previous month arguing against doing it.

This article covers what the new rule does, why he did it, and what is still unknown.

What the eCash difficulty adjustment actually does

Bitcoin recalculates mining difficulty every 2,016 blocks. That is about two weeks. Each time, it corrects the full gap between how fast blocks arrived and how fast they should have.

eCash now does something different. We read the change directly from the commit. It is dated October 26 at 23:47. Its title is "Add 288-block dampened retarget after eCash fork."

Two things change.

The clock speeds up. Difficulty recalculates every 288 blocks instead of 2,016. That is about every two days.

The correction shrinks. The code takes six parts of the old difficulty and one part of the new reading, then averages them.

The comment in the source says it plainly: "Target = (6 * old target + measured target) / 7".

We worked out what that means in practice. Difficulty can rise by at most 12 percent in any two day period. It can fall by at most 30 percent.

That gap is on purpose. The rule is slow to rise and quick to fall.

Michael Blowes, an independent developer in the eCash community, called it the "Sawtooth DAA" the morning after it landed. His reading of the numbers matches the code.

Why the old rule broke on the test network

eCash ran two public test networks before launch. Both showed the same problem.

A chain with a small share of the world's SHA-256 mining is easy to game. When difficulty is low, miners rent hashrate and pile in. They finish two weeks of blocks in a day or two. Difficulty then jumps by the maximum amount.

Then the rented hashrate leaves. The chain is stuck at a difficulty nobody wants to mine, and it grinds forward at a crawl.

The beta network ran a full cycle of this in October. Difficulty went from 1G to 4G in a single day. It then fell 33 percent over the next three weeks.

Then it jumped 300 percent to 10.68G in two days. After that, blocks came roughly an hour apart for weeks.

Sztorc described it himself on October 11, while it was happening:

"4.00 G was too high, 2.67 G (current diff) is now much too low. Next, it will (almost certainly) reset to 10 G, which will (obviously) be too high, since it is above 4.00."

He was right. It did.

Nine days later, a community member asked him whether mainnet would hold steady block times. His answer was two words: "as it stands? no."

Why Paul Sztorc says he had to change it

The reason he gave is not really about eCash. It is a claim about Bitcoin.

Here is what he posted on October 26, hours before the merge:

"In general, the L1 is very very simple, it is a clone of Bitcoin Core. Sadly, there is one change, the difficulty adjustment calculation. This is because Satoshi's calculation actually isn't that good, it will (probably) eventually malfunction in BTC, and destroy BTC. This will occur when the BTC security budget falls to less than 50% of total sha256d pow. So, although this change is regrettable, it was necessary."

Read that again. The man who invented drivechains thinks Bitcoin's own difficulty adjustment will eventually break Bitcoin.

His argument runs like this. Bitcoin's block subsidy halves every four years. As it shrinks, Bitcoin's share of all SHA-256 mining shrinks with it.

If Bitcoin ever drops below half of that mining, it faces the same trap eCash hit on beta. Miners come and go, difficulty swings, and blocks stall.

Bitcoin could fix this with a hard fork. Bitcoin is also very unlikely to ever hard fork again.

The algorithm most people wanted was not the one that shipped

eCash ran a public research group on this question for most of October. It had twelve topics and roughly 1,500 messages.

Most people in it landed on ASERT. That is the algorithm Bitcoin Cash has run since 2020, and it has worked. An eCash version of it was submitted as a pull request on September 22. It sat open for a month, with tests, and was never merged.

The objections to Sztorc's own ideas were blunt. One member simulated an earlier version of his idea. It performed four times worse than doing nothing at all. Another told him plainly: "Satoshi is just some guy." Copying Satoshi, he argued, is not a reason on its own.

Sztorc's stated reason for passing on ASERT came down to two things. He does not trust where it came from, and he worries about flaws nobody has found yet. Asked what was technically wrong with it, he said "there's probably something terrible about it that we haven't discovered yet."

What he merged instead is his own design. It is closer to Bitcoin's original shape than ASERT, and it borrows the same core idea of small, frequent corrections.

One member tested Sztorc's version against four other candidates. He reported that all of them fixed the problem. So the choice was less about which one worked, and more about which one Sztorc trusted.

Why this matters more for drivechains than for block times

Slow blocks are annoying. For eCash they are also expensive, and the reason is specific to drivechains.

Drivechain deadlines are counted in blocks, not days.

Moving coins out of a sidechain needs 6,048 miner approvals within 12,096 blocks. At ten minute blocks that is about 84 days. At the 20 minute blocks beta was producing, it becomes about 168 days.

A withdrawal that should take three months takes six. A new sidechain that should activate in a week takes two.

This cuts both ways. In October, fast blocks on beta cleared a batch of 3,155 time-locked transactions three days early, in six blocks. The same mechanism that strands a withdrawal can also rush one.

Stable block times are not a nicety for eCash. They are what makes the deadlines mean anything.

The rule met real hashrate on day one

eCash forked on October 29, 2026, at Bitcoin block 973,728. The new rule got its first live test within hours.

It arrived under heavy load. Miners pointed 12 to 13 exahashes per second at a chain whose starting difficulty was 2.6 billion. That is roughly one percent of Bitcoin's mining, aimed at a target built for far less.

Blocks came about every two seconds.

The first two adjustments both hit the ceiling. Difficulty rose 12 percent at block 974,016, then 12 percent again at 974,304. Those are the first and second 288-block windows after the fork.

The rule did what the code says it does. What people started arguing about is the shape of it.

The slow climb is the point, and also the problem

Zack did the arithmetic in public that afternoon. Seven rises of 12 percent is about double. So difficulty can only double across 2,016 blocks, where Bitcoin's rule allows a four times jump.

His first estimate was 14,000 blocks before block times settle down. He revised it the same afternoon.

The reason is price. The hashrate that showed up implies an ECX price near $1,050. If the real price is closer to $105, most of that mining leaves on its own.

That puts the gap at about 30 times rather than 300, and the catch-up at roughly 8,640 blocks.

Either number carries the same lesson. A rule that is slow to rise takes a long time to absorb a crowd. The crowd leaving does more of the work than the rule does.

The 42 percent figure going around is wrong

Within an hour of the first retarget, a figure of plus 42 percent was circulating in the developer group. Someone asked outright whether it was 12 or 42.

It is 12 up and 30 down. The 42 comes from reading the slow direction in the wrong units.

The code caps the target at 10/7 of its old value. In target terms that is a 42.8 percent move. In difficulty terms it is a 30 percent fall. They are the same event described two ways.

The two live retargets settle it. Both came in at 12 percent.

What is still unknown

Three things are worth watching.

The rule is still young. Bitcoin's rule has 17 years of adversarial testing behind it, and ASERT has six. This one has days. Two correct retargets are a start, not a result.

One timestamp attack is still open. Bitcoin has a known weakness called the timewarp attack. Miners lie about block times to pull difficulty down. Bitcoin has a fix available, known as BIP 94. eCash has it switched off in its settings, as Bitcoin does. The merged commit does fix a related off-by-one error that closes part of the hole.

The starting difficulty was too low. eCash started at a difficulty of 2.6 billion, written into the code. At least one community member argued before launch that it should be higher, and nobody from the project answered. Two second blocks on day one were the answer.

What this means if you hold Bitcoin

Nothing you need to do changes.

If you hold your own Bitcoin keys at the fork, you get 1 ECX for every 1 BTC. There is no claim form and no deadline. The difficulty change does not affect that.

What it does affect is how usable the chain feels in its first months. If the new rule works, blocks stay near ten minutes and sidechain withdrawals land on schedule. If it does not, eCash gets to find out in public, the way the test networks did.

eCash forked on October 29, 2026. Bitcoin's last block before the fork took about two hours to arrive. That pushed the launch later in the day than the project had planned.

eCash difficulty adjustment: common questions

Did eCash change Bitcoin's code?

Yes, in two places. It activates drivechains through BIP 300 and BIP 301, and as of October 26 it uses a different difficulty adjustment. Everything else is a copy of Bitcoin Core.

How often does eCash adjust difficulty?

Every 288 blocks, which is about every two days. Bitcoin adjusts every 2,016 blocks, about every two weeks.

How much can eCash difficulty change at once?

It can rise by up to 12 percent and fall by up to 30 percent per adjustment. Bitcoin allows a 4x rise or a 75 percent fall.

Is eCash using ASERT?

No. ASERT was the favorite inside the project's own research group, and an implementation was ready, but it was not merged. Paul Sztorc wrote and merged his own design instead.

Is eCash difficulty rising 12 percent or 42 percent?

Twelve percent up and 30 percent down, per 288 blocks. The 42 percent figure describes the same downward move counted in mining target instead of difficulty.

Did the new rule work on launch day?

It did what the code says. Difficulty rose 12 percent at block 974,016 and again at 974,304, both at the maximum allowed. Whether that is quick enough to settle block times is still open.

Does this change my airdrop?

No. The 1 ECX per 1 BTC snapshot works the same way. You need to control your own Bitcoin keys at the fork.

Sources

All code claims were read directly from the eCash repository at commit 5bd8690 on October 27, 2026. Launch day observations are from October 29, 2026.

• ecash-com/bitcoin, the eCash node software. Commit 5bd8690, "Add 288-block dampened retarget after eCash fork"

• Withdrawal bundle constants read from the BIP300301 enforcer at release v1.0.1

• Retarget heights are the first two 288-block windows after the fork at block 973,728, and were reported live in the developer group

• Quotes from Paul Sztorc, Michael Blowes and Zack are from the public eCash developer group chats, dated in the text

• ASERT explained, background on the algorithm eCash passed on

• Our own eCash facts page, which tracks the fork parameters as they change