[ANN][BFX] BitFinite — Point your Bitaxe at a chain where it finds blocks

[bitfinitechain]

Web wallet update — wallet.bitfinitechain.org

Rebuilt the wallet and shipped it. Desktop and Android builds too.

New send flow: enter, review, confirm. The review screen shows the exact fee the transaction will pay, read back from the built transaction rather than estimated.
Redesigned home, receive, history and settings. Works properly on phones now.
A sent payment now shows as pending straight away. Our Electrum server doesn't index the mempool, so the wallet previously showed no sign of a send until it confirmed — it looked like nothing had happened. The wallet now tracks what it broadcast itself, and won't reuse those coins for a second send. A server-side fix for the underlying cause is in progress.
Removed the fiat display. BFX isn't listed anywhere, so the wallet was showing Bitcoin Cash's price against your BFX balance — a made-up number. It's gone until there's a real feed, and the wallet no longer contacts any third-party price API.
Security pass: added a content security policy, raised the minimum quick-unlock PIN to 6 digits with slower key derivation, updated a dependency with a known advisory, and fixed an input-handling bug in the wallet-name field.
Non-custodial as before — keys stay in your browser. Existing wallets and PINs keep working; you may need one hard refresh.

The Android APK is signed. Desktop builds (Linux AppImage, Windows) are not yet signed, so Windows SmartScreen will warn — signed desktop releases to follow.

Source: https://github.com/bitfinitechain/bitfinite-webwalletElectrum server update — v1.1.3, unconfirmed transactions now indexed

Following on from the wallet post above: the server-side fix is done and deployed to both Electrum servers.

The cause was that our Electrum server parsed mempool entries using Bitcoin Core's field layout, which BitFinite (BCHN) doesn't emit. Every unconfirmed transaction failed to parse and was silently discarded, so the server reported an empty mempool at all times. It logged nothing at default level, which is why it went unnoticed.

What changes now:

A payment shows as pending as soon as it's broadcast, instead of only after it confirms.
The recipient sees it arriving, rather than nothing at all.
Balances drop on send instead of after the next block.
This affects any wallet pointed at our Electrum servers, not only the BitFinite web wallet — if you use a third-party Electrum wallet and saw this behaviour, it wasn't your wallet.

The wallet-side workaround from the previous post stays in place, so sends stay visible even against a server that hasn't been updated.

Source and binaries: https://github.com/bitfinitechain/electr-bfx/releases/tag/v1.1.3

[bitfinitechain]

Heads up for Coldcard users.

A firmware bug (March 2021 until it was patched) made some Coldcards
generate recovery phrases with far less randomness than they should
have. Attackers started draining those addresses on 30 July. Updating
the firmware doesn't fix a phrase that was already created.

BitFinite's wallets aren't affected — we generate phrases with the
OS/browser secure RNG, and we checked all of them.

But a phrase isn't tied to one coin. If you made yours on an affected
Coldcard and later restored those words into a BitFinite wallet, your
BFX is exposed too.

It's about where your words came from, not which wallet you use.

If that's you: new wallet, move your BFX over, update the payout
address in your miner and your pool username. Same for any other
chain you used those words on.

Details: https://bitfinitechain.org/security

We'll never DM you first or ask for your seed phrase.

[bitfinitechain]

Seed nodes are now on v3.0.2

Done tonight, 2026-08-09, between 16:02 and 16:15 UTC. Both pools paused for
about ten seconds each while their node restarted. If your miner logged a
reconnect in that window, that was us.

What changed
Our three seed nodes had been running a build from July 11 that reported
itself as 3.0.0. That is the same version-reporting bug covered earlier in
this thread. The build already carried the DNS seed and the two IBD trust
anchors that shipped as 3.0.1 — we checked the running binaries rather than
assuming, and the assume-valid hash, the minimum-chainwork value and
seed.bitfinitechain.org were all in there. Only the version string was wrong,
so nobody was peering with a weaker node than advertised.

All three now run the published v3.0.2 binaries, and the installed files
hash to the release checksums exactly.

No reindex, no consensus change, no wallet migration.

Result

Code:

seed-1   /BitFinite:3.0.2(EB32.0)/
seed-2   /BitFinite:3.0.2(EB32.0)/
seed-3   /BitFinite:3.0.2(EB32.0)/

All three agree on the same best block hash, no warnings, and none of them
has restarted since. Blocks kept coming through the checks afterward, and
every worker reconnected to both pools. Electrum, the explorer and the block
indexer are all back up.

If your pool stats look odd for a bit, that is expected: ckpool's lifetime
counters (accepted shares, best share) reset when it restarts, and vardiff
starts low and ramps back up as it re-measures each worker. Your actual
hashrate and share rate are unaffected.

If you run your own node
v3.0.2 is a drop-in from 3.0.0 or 3.0.1. Stop, swap the binaries, start.

https://github.com/bitfinitechain/bitfinite-core/releases/tag/v3.0.2

Code:

e209634baf2acb3eb5395b2954be5ae7e06075b3cac24a48d463ff9407b20eeb  bitfinite-v3.0.2-x86_64-linux.tar.gz
18b10a2b0dccc804a6064f6b8a396dc154f7a130c0ded4c325e050d6954b0071  bitfinite-v3.0.2-x86_64-windows.zip

Those match the SHA256SUMS on the release page — verify with

Code:

sha256sum -c SHA256SUMS

rather than taking the numbers above on trust.

BitFinite
Upstream security sweep, v3.1.0 coming

BitFinite forked from Bitcoin Cash Node v27.0.0 in December 2023. BCHN is now on v29.0.0, so we have been missing two and a half years of their fixes. Time to close that.

We went through the whole gap this week — 439 commits, 262 of them non-merge — and pulled out the ones that actually change how a node behaves under load
or under attack. The full ranked list with reasoning is in the repo:

https://github.com/bitfinitechain/bitfinite-core/blob/master/doc/upstream-security-backlog.md

What is going into v3.1.0:

* Per-peer bandwidth limits (-peerratelimit)
* Log rate limiting, so a noisy peer cannot fill your disk
* A socket descriptor leak fix, and the crash it eventually causes — this one matters on nodes with long uptime, which ours have
* Several undefined-behaviour fixes on the p2p input path, including a  CBloomFilter CVE backport from Bitcoin Core
* DNS seeder thread-safety fixes — that binary runs seed.bitfinitechain.org, so it is worth getting right
* Ignoring timestamps from inbound peers. This one is worth more to us than to BCH: with a handful of peers per node, a couple of hostile inbounds is a meaningful share of the time samples

What is not going in: the four consensus CHIPs from BCHN v29 (P2S,loops, functions, bitwise). Those are Bitcoin Cash's May 2026 network upgrade.
Adopting them here would be a hard fork needing coordinated activation across miners, so it is a separate conversation. It is not something we would slip into a security release, and it is hard to justify while our blocks are still
empty.

Nothing for you to do right now. When v3.1.0 is out we will post the checksums and the usual stop, swap, start instructions. Same drop-in as v3.0.2.

If you read the list and think we have the priorities wrong, say so.

BitFinite

v3.1.0 is out

https://github.com/bitfinitechain/bitfinite-core/releases/tag/v3.1.0

Drop-in from 3.0.x. Stop the node, swap the binaries, start it again. No reindex, no wallet migration, no consensus change. Our three seeds are running it now.

The DNS seeder was the worst of it

Two bugs we could reproduce by running the old and new seeder side by side against the same failure:

• A seeder that could not bind its DNS port printed "done", reported 0 DNS requests, and kept running while answering nothing. It looked healthy.
• It ignored the stop signal and had to be killed, throwing away every peer it had crawled since the last periodic dump.

Both fixed. That binary serves seed.bitfinitechain.org, so it is worth having right.

Also in

• Socket descriptor leak, and the crash it caused once a node ran out of descriptors. Matters if your node stays up for weeks.
• Log rate limiting (-logratelimit, on by default): 1 MiB per hour per message, so a noisy peer cannot fill your disk.
• Control characters stripped from log messages.
• Several undefined-behaviour fixes on the p2p input path.

What did not make it

We said -peerratelimit was coming and it is not in this one. Upstream's version is written against a rewrite of how connections are managed that we have not ported. We could have hand-adapted it, but that means shipping network code in a shape nobody upstream has ever run, and that is not a trade
we wanted on the p2p layer. It is first in line next.

The four May-2026 consensus CHIPs from BCHN are also not in here on purpose. Those would be a hard fork and need miners to coordinate an activation, so they do not belong in a security release.

Verify

Code:

16aed0716ba7dc6e9a94d5e6648cc25694d1eab77710d4755605edc7ccfa8ead  bitfinite-v3.1.0-x86_64-linux.tar.gz
e3a7e962692ae16eda09c92ca5475acf692dbf9fc9551d5c35bac7f740b5955c  bitfinite-v3.1.0-x86_64-windows.zip

Check them against the SHA256SUMS on the release page rather than trusting the numbers here.

Background on what else is queued from upstream is in the repo at doc/upstream-security-backlog.md if you want to argue with our priorities.

BitFinite



v3.1.1 — second batch, undefined behaviour on peer-reachable paths

https://github.com/bitfinitechain/bitfinite-core/releases/tag/v3.1.1

Close on the heels of 3.1.0 because these were ready and there was no reason to sit on them. Drop-in, no reindex, seeds are on it.

• CBloomFilter CVE backport from Bitcoin Core, plus a divide-by-zero guard in the filter hash. Those filters are built from data peers send you.
• UB in CNode::ReceiveMsgBytes — the network input path, every message from every peer.
• UB in SocketSendData above 2 GiB, and in AddToCompactExtraTransactions.
• MSG_FILTERED_BLOCK no longer reads a block off disk when the peer set no filter. Any peer could make your node do that work for nothing.

On -peerratelimit, one correction to what we said this morning: it is not just waiting on that one upstream rewrite. We measured it — roughly 30 net-layer commits sit between our base and it, about 840 lines added and 990 removed. So it is a sequenced port, not a cherry-pick.

We have now said "next release" about it twice. Not saying it a third time.
It ships when it ships.

Code:

4e36c7f1d79cf99c0dd53e6c8dfb49c45b7e8590acdf3080083a9a55aa818d5e  bitfinite-v3.1.1-x86_64-linux.tar.gz
d774703ab6cb7e49abc43b346f604b33e1d462184fddcf5179dab0b2bd0ba8db  bitfinite-v3.1.1-x86_64-windows.zip

Check against SHA256SUMS on the release page, not against these.


BitFinite


Small clarification — the Qt GUI wallet is in 3.1.0 and 3.1.1

We called it out in the 3.0.2 notes and then stopped mentioning it, so if you assumed it had been dropped, that is on our release notes rather than on you.

bitfinite-qt ships in both the Linux tarball and the Windows zip for 3.1.0 and 3.1.1, same as before. Nothing changed except us forgetting to say so.

[bitfinitechain]

BitFinite Node 3.1.2 is out, and two community channels are open.

--- 3.1.2 ---

https://github.com/bitfinitechain/bitfinite-core/releases/tag/v3.1.2

Drop-in upgrade from 3.1.x or 3.0.x. No reindex, no wallet migration, no consensus change - 3.1.1 and 3.1.2 nodes stay on the same chain. All three seeds are running it.

What is in it:

- A checkpoint at the genesis block was missing on five of our six networks.  Upstream ships one everywhere; ours were emptied during the fork and only   mainnet was ever restored. It bans forks that rewrite the genesis block.

- Log lines were being lost on a crash after log rotation. setbuf was applied  to the file handle being closed instead of the newly opened one, so the reopened debug log stayed fully buffered. This is a Bitcoin Cash Node bug from 2018 that BCHN fixed in v29 before we found it independently - the fix is theirs, we backported it.

- An overflow assertion in the difficulty code had been commented out during our genesis work and did not need to be. Put back.

None of these are vulnerabilities and we are not calling them that.

--- how we found them ---

The unit tests had not been run in months. Nothing in our release pipeline built them, so a backport that landed tests for a half-implemented API stopped the suite compiling for two days without anyone noticing - the node itself was fine, which is why it went unseen.

That is fixed. CI now builds and runs the tests on every branch, and 117 of 120 suites pass. The three exclusions are listed with a reason each in scripts/run-tests-docker.sh.

Six suites needed repair. Five had been broken by our own rebranding - a find-replace that landed inside values carrying a checksum or an encoding (address prefixes, a base58 xpub, a client name that never existed). None of them was a defect in the node. Worth stating plainly, because "the rebrand broke the tests" is a different claim from "the code was wrong".

--- verify it yourself ---

The Linux binaries are reproducible. Building locally in Docker produces bytes identical to what the GitHub runner published - we checked again for this release. Windows are not reproducible; PE headers carry a build timestamp.

Code:

  git clone https://github.com/bitfinitechain/bitfinite-core
  cd bitfinite-core && git checkout v3.1.2
  NO_QT=1 scripts/build-core-docker.sh linux
  sha256sum build-linux/src/bitfinited

Compare against scripts/release-checksums.txt, which pins the binary hashes in git rather than trusting the SHA256SUMS inside the archive - that file travels with the artifact and can only attest to itself.

--- community ---

Telegram: https://t.me/bitfinitechain
Discord:  https://discord.gg/8yjGUwQQcF

Organized by topic - network status, blocks found, releases, mining help, and a Chinese-language section on Telegram. The status card and block alerts come from a bot reading the node and the pools directly, so they stay current
without anyone being online.

New members are approved manually on Telegram, and Discord needs a verified phone plus accepting the rules, so expect a short wait after joining.
The only links we use are on bitfinitechain.org, on github.com/bitfinitechain, or posted inside those two servers.

Nobody from the project will message you first, and nobody will ever ask for a seed phrase or a payment.

BitFinite

[bitfinitechain]

Android wallet update — v1.4.1

New build of the BitFinite Android wallet is out. Still experimental, still sideload only.

v1.4.1 — bug fix
Large sends failed at broadcast with tx-size (code 64). If a wallet holds many small coins (mining payouts), a large send has to spend hundreds of them. Each input adds about 148 bytes, so the transaction goes past 100,000 bytes and no node will relay it. Consensus allows 1 MB, but the relay limit is 100 KB, and the wallet's size check came from a library that only warns above 1 MB. So the transaction passed every local check and was refused by the network after the user confirmed it.

The wallet now checks before you confirm, and tells you how much you can send in one transaction. No funds were at risk; those transactions never left the phone.

If you mine to this wallet and hit it: send in smaller amounts, or consolidate by sending to yourself in batches.

v1.4.0 — design pass

Redesigned wallet home, Send, Receive, transaction and settings screens
Privacy mode: hide balance and amounts with one tap
Fiat is no longer shown. BFX has no market price, and the app was printing 0.00 USD on every transaction, which was a made-up number
Fixed a theme that drew its menu text in the same color as the background
Contrast fixes across buttons, icons and the balance
Download
https://github.com/bitfinitechain/bitfinite-wallet/releases/tag/v1.4.1

Verify with

Code:

sha256sum -c SHA256SUMS

. Signed with the BitFinite release key (CN=BitFinite). Most phones need arm64-v8a.

Warning — experimental test wallet. Not on Google Play or the App Store. Install by hand and use test funds only.

Source: https://github.com/bitfinitechain/bitfinite-core
Explorer: https://explorer.bitfinitechain.org

BitFinite

[bitfinitechain]

A second mining pool showed up on BFX

Two blocks last week, on 15 and 20 August, were found by a pool that is not ours. We did not know about it until we went looking at why some blocks were showing as "Unknown" in our mempool.
It is a small share — two blocks out of about 2,190 — but it means the chain is no longer mined only by the pools we run. That matters more than the number.
If that is you: your blocks show as "Unknown" because upstream ckpool ships with a default coinbase tag, /mined by ck/.

Set your own and you get the credit:

Code:

"btcsig" : "/your pool name/"

Our fork accepts bfxsig as an alias for the same setting, and the example config in the repo uses that name. Either works. Restart ckpool and the next block carries your name. It is a label, nothing to do with consensus.

Anyone can run a pool on BFX. It is SHA-256, the source and an example config are at github.com/bitfinitechain/ckpool-bitfinite,
and the stratum details are at bitfinitechain.org/pools.

BitFinite

[bitfinitechain]

BitFinite Node v3.2.1

https://github.com/bitfinitechain/bitfinite-core/releases/tag/v3.2.1

Drop-in upgrade from any 3.x. Stop the node, swap the binaries, start it again. No reindex, no wallet migration, no consensus change.
If your node is running and synced, nothing here affects you. This release is about how a new node joins the network.

Fixed seeds
Until now DNS was the only way in. If the seed hostname failed to resolve, a fresh node with no peers file could not reach the network at all. Four mainnet nodes are now compiled into the binary as a fallback.
They are a fallback, not a shortcut: the node only uses them if it still has no peers 60 seconds after startup. In normal operation DNS answers first and you will never see them used.

Faster initial sync
The assume-valid block moved from height 2,639 to 16,640. A syncing node now skips signature checks below that point instead of re-verifying about 14,000 blocks it had no need to.

Checking your download
Both builds are unsigned, so SHA256SUMS is the trust mechanism:

Code:

sha256sum -c SHA256SUMS --ignore-missing

The Linux build reproduces. Build it yourself with scripts/build-core-docker.sh in the same container and you get the same binaries, we checked all six against this release before publishing, so the hashes are something you can confirm rather than take our word for.

The Windows build does not reproduce, and Windows will warn you it is unsigned. That warning is about the missing signature, not about anything found in the binary.

Full notes are in the release.

BitFinite

[bitfinitechain]

BitFinite Wallet v2.1.0 is out.

New coin: Bellscoin ($BELLS). Send, receive, view-only watching, live prices, same as $BFX and $PEP. No public Electrum server exists for Bells (the chain is about 365 GB), so the wallet uses the Bellscoin team's esplora API through an adapter.
Note on seeds: we use the registered derivation path (SLIP-44 762). The Nintondo extension uses Bitcoin's, so a seed restored across the two wallets looks empty. Nothing is lost, they just derive different addresses.

Also fixed: three bugs inherited from our Stack Wallet fork. Each was a network request with no deadline, so a server that went silent could freeze the wallet at "Syncing" until restart. Every request now times out and fails over to the next server. This hardens BFX and PEP syncing too. Two of the three bugs are still in upstream Stack Wallet today.

Downloads and checksums:
https://github.com/bitfinitechain/bitfinite-wallet/releases/tag/v2.1.0

BitFinite

[bitfinitechain]

BitFinite Wallet v2.2.0 is out.
The wallet home is redesigned for all three coins.

• The price chart gained 24H, 7D and 30D ranges, with the change figure always computed from the chart on screen so the two can never disagree.
• The fiat line shows what your holding gained or lost today.
• Transactions group under day headers and lead with their direction.
• The old floating dock became big Receive and Send buttons, on the wallet home and the transfer pages, with the page you are on highlighted. On a watch-only wallet the Send button shows a lock and says why when tapped.
• Every coin keeps its face now. Text and buttons adapt their ink to the coin's colour, so light brands are finally readable: Bellscoin wears its official Bell Bag Gold, Pepecoin's green passes contrast checks for the first time, and BitFinite looks exactly as before. All three coins keep their brand colours and icons under every theme, including the downloadable ones, which used to repaint BFX in their own colour.

On reliability: every Electrum request now has a deadline. A server that accepted a connection and then went silent used to freeze the wallet at "Syncing" until you restarted the app. Now it times out and moves to the next server. Pepecoin also gains a fourth failover server relayed through our own infrastructure.

Update by installing the new APK over the old one. Wallets and settings are kept. Verify the checksums first.

Downloads and checksums:
https://github.com/bitfinitechain/bitfinite-wallet/releases/tag/v2.2.0

BitFinite

[bitfinitechain]

BitFinite Wallet v2.3.0

https://github.com/bitfinitechain/bitfinite-wallet/releases/tag/v2.3.0

New in this release:

• Bitcoin and Dogecoin, alongside BitFinite, Pepecoin and Bellscoin. Send, receive, and watch-only. Neither is swappable or buyable in the app.
• Wallets watching a busy address get their balance back. The fetch that sums an address's unspent outputs used to fail outright on a pool address, so the wallet showed zero. It completes now.
• Watching a busy address no longer freezes the app.
• 132 text fields cropped their own labels in half. Fixed.
• Maximum precision is bounded. A negative value used to crash every amount on screen, and the check meant to prevent it was compiled out of release builds.

Limits, stated plainly. Watch-only works, including on a mining pool payout address, and the balance is always exact, because it is the sum of unspent outputs rather than a total derived from the rows on screen. History is capped at the most recent 1,000 transactions per sync, and the wallet says so on screen. Some very large addresses cannot be read at all, because public Electrum servers refuse to enumerate very large unspent-output sets. This is a personal wallet, not a treasury monitoring tool. It is not recommended for exchange vaults or large institutional addresses. Use an indexer or a block explorer for those.

Android APKs are attached to the release with SHA256SUMS. Install over the old version; wallets and settings are kept.

Source: https://github.com/bitfinitechain/bitfinite-wallet

BitFinite

[bitfinitechain]

BitFinite is now listed on NestEx.

Pair is BFX/USDT: https://trade.nestex.one/spot/BFX

Deposits and withdrawals are both open. We tested the full round trip with real coins before announcing, so the integration is confirmed working rather than assumed.
Before depositing, note the withdrawal fee. NestEx sets it to $1 worth of BFX and recalculates every ten minutes, so it moves with the price. It is about 39 BFX at the moment. If you deposit less than the fee you will not be able to withdraw it again.
The opening price was set at 0.025, chosen from what it costs to mine one BFX on the hardware our miners actually use, and from where comparable chains trade on that same exchange. It is a starting reference, not a promise.

NestEx does not do KYC, so there is no formal recourse if anything goes wrong there. Keep on the exchange only what you are comfortable having on it.

BitFinite

[bitfinitechain]

BitFinite Node v3.2.2 is out, and it is a security release. If you run a node, upgrade it.


https://github.com/bitfinitechain/bitfinite-core/releases/tag/v3.2.2

Two of the five fixes let an unauthenticated peer crash a node or drive it out of memory. Both are reachable by anyone who can open a TCP connection to the P2P port, so this one matters to a node that is already running and synced,unlike 3.2.1.

The short version of what was wrong:

• A duplicate blocktxn message could abort the process. Rebuilding a compact block consumes an internal object, and a second copy of the same reply hit an assertion. Our released binaries are built without NDEBUG, so that assertion is a crash and not a debug warning. Same class as CVE-2024-35202, fixed upstream after our fork point and never carried across.
• Block headers were stored with no bound on how many. The only check that ties an incoming header to our chain is skipped until a block has been finalized, which is two hours after every process start, and that state is not written to disk, so every restart re-opens the window. Same class as CVE-2019-25220.
• The other three are in the DNS seeder: its chain check could be passed by a peer that simply claimed a block height, a user-agent field was read with no length cap, and the address database had no size limit.

The findings came from OpenVuln, an automated vulnerability analysis project: https://huggingface.co/spaces/zai-org/OpenVuln

Worth saying plainly, because it is the useful part: the report was specific and it was right, and several of these had been sitting in the code since the fork. Every finding was reproduced against our own source before anything was changed, and every fix has a regression test that was run against the unpatched code first to prove the test actually catches the bug.

Two of the fixes raise the cost of an attack rather than ending it, and the release notes say so rather than leaving you to find out. Header storage is still unbounded for a node in initial sync, because the real answer is headers pre-synchronization and that is a much larger change. The seeder's chain check is now expensive instead of sound: powLimit here is difficulty 1, so a determined attacker can still mine a qualifying header, and the seeder holds no chain of its own against which to judge whether that header's difficulty is plausible. Closing those properly needs a design change, not another check.

Upgrading is a binary swap. No reindex, no wallet migration, no consensus change, no configuration change. Stop the node, replace the binaries, start it again.

Verifying: the Linux binaries are reproducible. Build the tag yourself in the same container and you get the same bytes, so the published checksums are something you can confirm rather than trust. Ours are pinned per binary in git at scripts/release-checksums.txt, not only in the SHA256SUMS that travels inside the archive, because a file inside an archive can only vouch for itself.
The Windows build does not reproduce, since the PE header carries a build timestamp.

Our own four mainnet nodes and the DNS seeder are on v3.2.2 as of today, all agreeing at the same height.

BitFinite

[mining38]

Yes — if About says 3.0.2, you're running 3.0.2.

The version bug I mentioned hardcoded it to 3.0.0, so affected builds always
reported *lower* than they really were (that's how v3.0.1 shipped calling itself
3.0.0). It couldn't report anything newer, so nothing older can fake "3.0.2".

If you want to double-check: `bitfinite-qt --version` prints the same string, and
the SHA256SUMS on the release page now matches the actual files — the old one
didn't, so it passed without really checking. Fixed.

Hope that helps

https://imgur.com/a/WoD2a1G

Hello BitFinite team,

I am writing to report an issue I encountered while solo mining BFX with my own node and a ckpool fork.

On [14/10/2026], I successfully solved block #[31554].

However, the 50 BFX block reward was sent to a different address than the one I configured in my ckpool's config file. My configured address is bfx:fpewaawe20ntc3qaahn52mnwvezut02f2yjx4hac96, but the coinbase transaction was sent to bfx:ffeqknuchyl9spfmuruqtksh7gvjfcv33gqp3uat2m.

I later discovered that my ckpool configuration required the "bchaddress" parameter instead of the "btcaddress" parameter, and that I needed to restart ckpool for the change to take effect.

Could you please confirm if there is any way to recover this block reward, or if this is a known issue?

Thank you for your time and for creating this project.

Best regards,
[mining38]

[solarsurfer]

Checked on my BitFinite node: block 31554 paid 50 BFX to bfx:ffeqknu…, so it's as you say. Sadly the chain can't reverse that. Your best chance is asking the author of that ckpool fork, since that's likely their default address. Worth double-checking any pool config by mining a test share and looking at the coinbase address before leaving it running.

Or mine it on our site !

[mining38]

[SOLVED] Solo mining BFX with ckpool sends block rewards to wrong address — use ASICSeerPool instead**

Hi everyone,

I want to share a solution to a problem I ran into while solo mining BitFinite (BFX) with my own node and a ckpool-based pool. I hope this saves someone else from losing a block reward the way I did.

**The problem**

I set up a BitFinite full node (v3.0.1, later updated to v3.2.2) with RPC on port 8332, and configured ckpool with my BFX address:

```
"btcaddress": "bfx:fpewaawe20ntc3qaahn52mnwvezut02f2yjx4hac96"
```

The pool connected fine, my Bitaxe 601 mined, and I actually solved a block (height 31554). But the 50 BFX reward was sent to a completely different address:

```
bfx:ffeqknuchyl9spfmuruqtksh7gvjfcv33gqp3uat2m
```

My configured address was ignored entirely.

**The diagnosis**

I checked the actual coinbase transaction of block 31554 with `getblock`. The scriptPubKey hash160 was:

```
329b4f98b93e58041be0f895da17f2192061918a
```

But my own address, verified with `validateaddress`, has hash160:

```
72eef5d953e6bc453dede7456e6e6645c5bd4051
```

Completely different. So ckpool was not just ignoring my address — it was **mis-decoding it**.

**Root cause: address alphabet mismatch**

BitFinite uses a CashAddr alphabet that is **not identical to Bitcoin Cash**. Specifically, BitFinite swaps the characters `q` and `f`. Real BFX addresses always start with `bfx:f` (not `bfx:q`, which would be a BCH-style address).

Standard ckpool binaries — even BCH forks of ckpool — are compiled against the standard BCH alphabet. When such a binary decodes a `bfx:f...` address, it interprets `f` using BCH rules and produces a completely different hash160. Result: your reward goes to an address whose private key nobody has.

This is not a config mistake. It is a **binary-level incompatibility**. No amount of editing `btcaddress` / `bchaddress` / `single_payout_override` will fix it.

**The solution: use ASICSeerPool, not ckpool**

ASICSeerPool is a BCH-focused pool implementation (originally based on ckpool-splns by Con Kolivas, reworked by Calin Culianu) with proper CashAddr support. Once I switched to it, my BFX address was accepted and registered correctly.

Here is the exact setup that works.

**1. BitFinite node config (`bitfinite.conf`)**

```
server=1
rpcuser=bitfinite
rpcpassword=YourStrongPassword
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
rpcport=8332
port=8333
zmqpubhashblock=tcp://127.0.0.1:28332
```

Note: the official docs list rpcport=19769 and port=19768 as defaults. I used 8332/8333 because that is what the pool config expects, and it works fine as long as the two match. The ZMQ line is **mandatory** for the pool to receive new-block notifications.

**2. Build ASICSeerPool**

```bash
git clone https://github.com/cculianu/ASICseer-pool
cd ASICseer-pool
mkdir build && cd build
cmake -DCMAKE_POLICY_VERSION_MINIMUM=3.5 ..
make -j$(nproc)
```

On Arch/CachyOS the dependencies are:

```bash
sudo pacman -S --needed base-devel cmake zeromq curl jansson
```

**3. ASICSeerPool config (`asicseer-pool-BFX.conf`)**

```json
{
  "btcd": [
    {
      "url": "http://127.0.0.1:8332",
      "auth": "bitfinite",
      "pass": "YourStrongPassword",
      "zmq": "tcp://127.0.0.1:28332"
    }
  ],
  "disable_dev_donation": true,
  "upstream": "",
  "bchaddress": "bfx:YOUR_REAL_BFX_ADDRESS",
  "single_payout_override": "bfx:YOUR_REAL_BFX_ADDRESS",
  "pool_fee": 0.0,
  "bchsig": "solo",
  "blockpoll": 100,
  "blocking_timeout": 63,
  "noncelength": 4,
  "nonce2length": 8,
  "update_interval": 30,
  "version_mask": "1fffe000",
  "serverurl": ["0.0.0.0:3340"],
  "nodeserver": [],
  "trusted": [],
  "mindiff": 1,
  "startdiff": 42,
  "maxdiff": 0,
  "logdir": "/home/YOUR_USER/asicseer-pool/logs-bfx"
}
```

Important points:
- Do **not** include a `btcaddress` line. This version of ASICSeerPool will refuse to start with `"btcaddress key has been renamed to bchaddress"`.
- `bchaddress` and `single_payout_override` must be identical and must start with `bfx:f`, never `bfx:q`.
- `bchsig` is used, not `btcsig` (some forks accept both, but `bchsig` is correct here).

**4. Start the pool**

```bash
./build/src/asicseer-pool -c asicseer-pool-BFX.conf
```

**5. Verify it is using your address**

Before you ever find a block, you can confirm the pool is bound to your address:

```bash
cat logs-bfx/pool/pool.miners
cat logs-bfx/pool/pool.status
```

The worker entry will literally be your BFX address:

```
bfx:fpp849f...:{"hashrate1m":"1.26T", ...}
```

And in `asicseer-pool.log` you will see:

```
Added new user bfx:YOUR_ADDRESS as address based registration
```

If you see that line, your rewards will go to you.

**6. Point your miner at it**

In AxeOS / Bitaxe settings:

- Stratum URL: your machine's LAN IP
- Port: 3340 (or whatever you put in `serverurl`)
- User: `bfx:YOUR_ADDRESS.worker1`
- Password: `x`

**Conclusion**

- ckpool cannot handle BitFinite's `bfx:f...` addresses because it uses a standard BCH alphabet. Do not use it for BitFinite solo mining.
- ASICSeerPool handles BitFinite CashAddr correctly and will pay block rewards directly to your configured address in the coinbase transaction.
- Verify with `pool.miners` and the "address based registration" log line before you waste hashrate.

I lost one block (height 31554, 50 BFX) to this before I figured it out. Hopefully this post saves someone else.

If anyone from the BitFinite team wants to weigh in — it might be worth shipping an official pool binary built against the BitFinite alphabet so people don't run into this at all.

Good luck and happy mining.

[mining38]

After switching to asicseerpool, I found a new block today, and the block reward arrived in my wallet instantly. You can run a node and engage in solo mining on asicseerpool with complete peace of mind.