Weekly status update - 2026-11-09 (all facts verifiable on-chain)
Network
- Block height: 18,134
- Difficulty: 3.13, recalculated every block
- Total supply: 1,906,650 BIG of 21,000,000 (~9.1%)
- Block spacing: 5.1 min over the last 144 blocks, 4.0 min over the last 500
- Mempool: 0
v1.7 is published today, and it changes the proof-of-work algorithm
Up to height 19,499 BigCoin uses double SHA-256, exactly like Bitcoin. From
height 19,500 it uses yespower 1.0 instead: N=2048, r=8, personalisation
string "BigCoin/yespower1.0", computed over the same 80-byte block header.
Every hash needs 2 MiB of memory.
Why. This chain's difficulty is about 3.1, which is roughly 44 MH/s of
SHA-256. A hobby single-chip miner, the sort sold as a desk ornament at about
1.2 TH/s, is some 27,000 times that; a second-hand datacentre unit runs 13 to
100+ TH/s, which is one to two further orders of magnitude on top. Either
owner could take every block for as long as they cared to, or rewrite recent
history, for the cost of the electricity - and no difficulty rule fixes that
on a chain this small, because difficulty cannot tell one miner from another.
yespower needs memory that a SHA-256 ASIC does not have, so that hardware
cannot participate at all: a block it produces is invalid, not merely late.
What this is not. It is not a claim that BigCoin is ASIC-proof for ever.
Someone can build hardware for yespower. It would have to carry the memory,
which is most of what makes a general-purpose CPU expensive, so the gap would
be a small multiple rather than the four-to-six orders of magnitude a SHA-256
ASIC enjoys here today. That is the whole claim, and I would rather state it
that narrowly than sell you a guarantee I cannot keep.
What it does not fix either. Heights below 19,500 stay double-SHA256 for
ever, so a fork rooted in that range can always be mined at ASIC speed. The
highest pinned block in v1.7 is 17,750, which caps how far back such a fork
can be rooted; a fork from there would still have to out-work the honest
chain from 17,750 on and would arrive as a reorganisation up to 1,750 blocks
deep by the time the switch happens, which no node applies quietly. That is a
bounded residual risk, not a closed hole, and the only thing that shrinks it
further is a later release pinning into the window.
The difficulty at the switch is set by hand, once
The old nBits measures double-SHA256 work and means nothing under yespower,
so the ASERT schedule restarts from a hand-set target at 19,500: 6,000,031
hashes per block, i.e. one block per ten minutes at 10,000 H/s. For scale, the
16-thread desktop this release was built on works out at roughly 5,000 H/s
across all of its threads, so that target assumes something like two such
machines are mining. Read that as an estimate of my hardware rather than a
benchmark of yours: yespower is bound by memory bandwidth, not clock speed, so
the spread between CPUs is wider than their specifications suggest.
That is deliberately on the hard side, and the asymmetry is the reason:
setting it too easy would mint coins quickly and cannot be undone, because
ASERT can only tighten by 0.24% per block. Setting it too high costs slow
blocks that fix themselves. So expect the first blocks after 19,500 to come
slowly - possibly for a day or two - while difficulty finds the real CPU
hashrate. It eases every block, and faster than that if a gap passes six
hours, which is the other change in this release.
Also in v1.7: the stall rule, from height 18,000
ASERT as shipped in v1.4 fixes the next block's target the moment its parent
exists - the elapsed time it measures runs to the PARENT'S timestamp. So
while the chain sits waiting, nothing eases. A difficulty left behind by a
miner who stopped does not decay; it stays where it was until somebody finds
one block at it. That is why height 17,324 froze for 5 days 3 hours at the
start of this month rather than slowly recovering, and v1.4 only cleared it
because I hand-moved the ASERT anchor. The next time it happens I might be
asleep.
From height 18,000 the elapsed time is max(parent's timestamp, candidate's
timestamp - 6 hours). Below six hours of silence that is byte-identical to
the old rule. Past six hours the target eases with real time on its own,
halving every two days, so a stranded difficulty clears itself. A three-day
visit from an ASIC followed by it unplugging used to leave a difficulty whose
expected wait for the next block was about 140 days; it now recovers in about
11 days with no intervention from anyone, including me.
What it costs you:
- Block timestamps are already capped at 2 hours ahead of real time, so the
most anyone can gain by dating a block forward is 2^(2h / 2 days) = 2.9%
less work. It does not compound, because the ASERT anchor is fixed, and it
is a level shift available equally to everybody rather than a per-block
subsidy to whoever lies hardest.
- Mining software must stop rolling the timestamp while keeping the old
nBits, because from 18,000 the required nBits depends on that timestamp.
getblocktemplate no longer advertises "time" as mutable at that height. Any
miner built on generatetoaddress, including the scripts I publish, needs no
change: it asks for a fresh template each round, which is also how it picks
up the easing during a stall.
Height 18,000 is behind the tip by the time you read this, which is on
purpose: for every gap shorter than six hours the new rule computes exactly
the same nBits as the old one, so v1.7 validates the chain as it already
stands, block for block. I check that before publishing rather than assuming
it - if any gap at or above 18,000 had reached six hours, this release would
have been held back instead of shipped.
Both mining scripts are new, and worth taking
Every version before v1.7 waits for the node to report that its initial block
download has finished. A node started while the chain itself is stalled never
reports that, so the one moment the chain most needs another miner was the one
moment the old script refused to mine. That is fixed.
They also ask the node which algorithm the next block needs instead of
assuming one, and size each mining call by timing the previous one - which
they have to, because a yespower hash takes milliseconds where a double-SHA256
hash takes a fraction of a microsecond, and no fixed setting suits both sides
of 19,500.
One consequence is worth knowing before you judge the switch on per-hash costs
alone. These scripts drive the node's own generatetoaddress, which rebuilds and
re-serialises the block for every nonce it tries. That overhead is trivial
beside a yespower hash and dominant beside a double-SHA256 one, so today the
scripts reach well under what your CPU could do in a tight SHA-256 loop, and
after 19,500 the same code runs at close to the hardware's full yespower rate.
A CPU miner using what I publish therefore gains more at the switch than the
two algorithms' raw costs by themselves imply.
Unlike last week, the scripts are NOT byte-identical to the previous ones.
Replace them. The standalone downloads are versioned from now on
(mine-bigcoin-v1.7.cmd, mine-bigcoin-v1.7.sh) so the older files keep
working for anyone who linked to them; inside the packages the names are
unchanged.
What you have to do
Upgrade to v1.7 before block 19,500. At the pace of the last 144 blocks that
is about five days out, on the order of 14 November, but that estimate moves
with hashrate, so watch the height and not the date:
bigcoin-cli getblockcount
Nodes on v1.5 or older stop at 19,500. Because it is the algorithm that
changes and not a difficulty rule, they do not merely fall behind: the hashes
they compute are no longer the ones consensus asks for, so they can neither
follow the chain nor mine one valid block past that height. The same is true
of any external miner or stratum setup speaking SHA-256d.
Upgrading is a binary swap and nothing else. The chain data on disk does not
change, so there is no reindex and no resync: stop the node, replace the
binaries, start it again. That holds even if you only notice after 19,500. A
node that rejects those blocks rejects them at the header, before anything is
written to its block index, so it has no bad verdict stored to undo - it
simply carries on from where it stopped once the binary understands what it is
being sent. You can read that for yourself in src/validation.cpp,
AcceptBlockHeader().
There is no v1.6 download, and the gap in the numbering is not an oversight.
v1.6 was built with the stall rule but without yespower; publishing it would
have handed you one more binary that dies at 19,500, so it was replaced by
v1.7 before release and never distributed. The published versions are v1.3,
v1.4, v1.5 and v1.7.
Your node will tell you where the switch is and which algorithm it expects
next, so you never have to take my word for it:
bigcoin-cli getblockchaininfo -> pow_algo, yespower_activation_height
The seed node runs v1.7. The source is published with the binaries, so you can
read the change instead of trusting the description: src/pow.cpp,
src/crypto/yespower/ (vendored 1.0.1, with its provenance and local patches in
that directory's README.md) and src/kernel/chainparams.cpp.
Mining distribution
Coinbase addresses over the last 200 blocks, 6 distinct:
179 89.5% one address not mine
15 7.5% one address mine
6 3.0% four addresses none mine
Over the last 500 blocks, 11 distinct addresses: the largest holds 86.6% and I
hold 8.6%. One address therefore accounts for roughly six blocks in seven,
which is enough to reorganise the chain at will. It is not me, and me saying so
does not make it safe. If you are considering mining here, that is the single
most important number on this page, and it is the reason independent hashrate
matters more than anything else I can ship.
I publish no addresses but my own; every figure above is reproducible from the
explorer in a few minutes. From 19,500 every miner needs yespower, whatever
hardware they are using today. I do not know what that will do to this table
and I am not going to pretend otherwise.
My own holdings, unchanged and still disclosed
My wallet holds 1,008,001 BIG, which is 52.9% of everything in existence,
across two addresses:
big1qe2v5u9aqhafy85pxet8cpzzxyqgxxykqykj5gh 101 blocks, heights 1-101
big1qycz9vmq49wuxkvl6v2tdnudglnfaxy7jd84xc3 80 blocks, heights 102-18,132
That total includes 200 BIG of rewards I cannot spend yet, because a coinbase
output matures 100 blocks after it is mined. I count them anyway: the supply
figure at the top of this post counts unmatured coinbases too, and the honest
way to state your own share is the one that does not quietly leave part of it
out of the numerator.
The first address includes the block 1 reward of 1,000,000 BIG, which was
disclosed from day one and is visible to anyone:
http://133.242.139.204/block/1I have mined 1,009,000 BIG in total. The 999 BIG difference is the faucet:
1,000 BIG out to fund it, and 1 BIG back in, which is the single test claim I
made yesterday to confirm it actually pays. Nobody else has used it yet.
Nothing has been sold. Nothing is for sale. There is no exchange, no listing
application, and no mechanism by which I take money from anyone.
New this week - faucet
The explorer now has a faucet:
http://133.242.139.204/faucet pays 1 BIG per
address, once per 24 hours, up to 50 BIG a day across everybody, funded with
the 1,000 BIG noted above - so you can see a transaction land in your own
wallet before you commit a CPU. If it tells you the daily budget is spent,
that is what has happened; it refills the next day.
v1.7 downloads
BigCoin-win64-v1.7.zip 26.1 MB
sha256 501613b628252dfcac7315dd2256332b0388f19ef44970f0e3794d088c9444d8
bigcoin-linux-x64-v1.7.tar.gz 9.6 MB
sha256 753399bf4d183ecc94e17404c475b25c5201bb2b7762fb98600332720691e0cb
bigcoin-source-v1.7.zip 15.4 MB
sha256 954390fb3dd8a3dc6e1feaf0469294ae5ff4957ae8de5117edf01923ba936125
bigcoin-source-v1.7-unix.tar.gz 14.0 MB
sha256 cbae78fca9c0953f3381e6e6d27d7c8dce73fdbb38c1d8e60e780b7d7aa98926
mine-bigcoin-v1.7.cmd 21.6 KB
sha256 b4973f0c5c6a6f59c276f899a21a7453a60e35e3b916d222e55fa27647c4bf26
mine-bigcoin-v1.7.sh 17.4 KB
sha256 67d55214e84a5571358c09d2c875f0b49d94a08307ac32e93e79cc56fec574dd
Ground rules, unchanged: nothing is for sale, no exchange listings are
sought, no price talk. If you want BIG, mine it.
Downloads:
http://133.242.139.204/downloadsMining guide:
http://133.242.139.204/miningExplorer:
http://133.242.139.204/Faucet:
http://133.242.139.204/faucetSeed node: 133.242.139.204:8338
