Bitcoin Forum
August 12, 2026, 07:53:57 AM *
News: Latest Bitcoin Core release: 31.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [OPEN SOURCE] Pure-Python miner for Bitfury BF1 + BFL Jalapeño (solo lottery)  (Read 20 times)
hydraxcoin (OP)
Newbie
*
Offline

Activity: 3
Merit: 0


View Profile
August 07, 2026, 03:47:19 PM
 #1

Hi all,

I've been in Bitcoin since 2013 and recently pulled my old USB miners out of my retro collection: two Blue Fury sticks (Bitfury BF1) and a Butterfly Labs Jalapeño (BFLSC, FW 1.2.9). Most of the software from that era is dead links by now, so I wrote a miner for them from scratch — in pure Python, nothing to trust but readable code.

What it does
- Solo mining via Stratum V1 (public-pool.io by default) straight to your own address
- Bitfury BF1 driver: multi-stick, hotplug, per-stick watchdog
- BFLSC driver: job queue, result polling, queue flush on new blocks, temperature guard (pauses above 80 C)
- Optional CPU mining and a browser miner — the dashboard has a PLAY button, so a phone joins the game with a midstate-optimized SHA-256 in JS
- Retro CRT web dashboard (hashrate per device, shares, "lottery-o-meter", live block height)
- Single dependency: pyserial. No binaries anywhere, GPLv3.

Measured on my hardware
- Blue Fury: ~1.6-1.8 GH/s each
- Jalapeño: ~5.5 GH/s sustained (the 6.8 GH/s on paper is optimistic; a few dead cores leave permanent holes in the nonce coverage)
- Fleet total: ~9-10 GH/s as credited by the pool

Protocol notes, in case anyone else revives this hardware
Both drivers were written by reading the bfgminer/cgminer sources, then fixed against live hardware. Three things cost me the most time:
1. BF1: the chip returns nonces bit-mangled — decnonce() plus six offsets, and the result has to be byte-swapped before it means anything.
2. BF1: feed it work faster than ~1.6 s (cgminer's BF1WAIT) and you truncate its scan. At a 0.8 s pace most jobs came back empty.
3. BFLSC: "INPROCESS:n" in the ZOX reply is not the queue depth — it's how many jobs are being hashed right now. Trusting it made me hammer a full queue and the device dropped to ~0.6 GH/s. Also, poll results more often than ~1x/s and the chip silently loses valid nonces mid-scan.

Honest odds
At ~9 GH/s against a ~1 ZH/s network, the expected time to a block is roughly 2 million years. This is a lottery ticket and a retro-computing hobby, not an investment. Somebody still wins every 10 minutes.

Code, README and screenshots:
https://github.com/03012009BTC/miners-bitcoin-lottery

Dashboard screenshot:
https://raw.githubusercontent.com/03012009BTC/miners-bitcoin-lottery/main/docs/dashboard.png

Happy to answer anything about the protocols. If you have other old sticks in a drawer and want them supported, open an issue — I'm curious what's still alive out there.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!