The BIP-110 Split
Block 961,632, 8 August 2026. Nodes enforcing BIP-110 rejected blocks that did not signal bit 4, and followed a branch of their own.
THE BRANCH
b10c, 11 Aug: two blocks on the branch, 961,632 and 961,633, with the main chain more than 400 blocks ahead. Lopp, 17 Aug: four blocks, all from a miner calling itself Roughnecks, and OCEAN refunded miners whose hashrate had been pointed at that chain. bitcoinbip110.org lists 961,639 as the last SHA-256d block, so eight in all.
BIPS REPO
BIPs #2245, merged 10 Aug, sets BIP-110 to Closed. Sjors Provoost writes that the activation criteria were not met. SatsAndSports writes that no height on the heaviest chain ever enforced its rules.
BIP EDITORS
BIPs #2248, merged 10 Aug, removed Luke Dashjr as a BIP editor. Murch's motion cites BIP-110's handling, including a number assigned on X before list discussion and a merge within minutes, and little editorial work since 2024. Luke, on X on 10 Aug, called it "an abuse of power by Core" and said they have no authority to do so.
Knots 29.4.1: A New Proof of Work
Released 2 September. A hard fork: SHA-256d miners cannot extend the chain it follows. bitcoinbip110.org dates the first BLAKE2b block, 961,640, to 30 August at 06:14 UTC.
WHAT CHANGES
A BLAKE2b proof of work (knots#359), a temporary 800,000 weight-unit block limit, BIP-110's reduced-data rules active from that flag day, and opt-in
SIGHASH_UNIFIED. The notes say a backward-incompatible change was required. Header JSON gains new fields, including header_version, nonce2, nonce3, and xor_key.WHICH CHAIN
The release notes say that on 8 August most former miners abandoned Bitcoin and have been promoting a new altcoin as Bitcoin, and that the proof-of-work change mitigates that attack. bitcoinbip110.org calls the BLAKE2b chain Bitcoin BIP110. Bitcoin Core implements neither BIP-110 nor the new proof of work.
REPLAY
Coins from before 8 August exist on both histories. A transaction signed for one can also be valid on the other, unless the signer uses
SIGHASH_UNIFIED, which bitcoinbip110.org presents as the chain's opt-in replay protection.Sztorc's eCash (ECX) Schedule
Paul Sztorc, 7 August: the BIP-300 hard fork launches in three stages instead of one. This is not Chaumian ecash and not XEC. Bitcoin's rules are unchanged.
THREE DATES
Alpha on 23 August at block 963,648, with practice coins (pECX) credited 1 per BTC. Beta on 20 September at block 967,680. The permanent release on 31 October at block 973,728, four weeks after this meetup. Practice coins can be redeemed for ECX after that.
REPLAY RISK
Replay protection is opt-in, and official ECX wallet software applies it. Without it, an ordinary Bitcoin spend can be replayed on the ECX chain, so the ECX follows the bitcoin to its new owner. Sztorc, quoted by bitcoin.com: "If you ignore us, we will replay your txns."
REPLAY DESIGNS
Optech #420, after a minority chain was hit by replayed transactions. Moonsettler sketches committing the previous block hash in the taproot annex, 34 bytes. Anthony Towns suggests a block height plus a hash suffix, 6 bytes, and an
nLockTime so a reorg cannot mine the transaction early.Lightning on x402
HTTP 402 means Payment Required. x402 is a standard for answering with a price, taking a payment, and then serving the request. The Lightning scheme for that merged on 23 September.
THE SCHEME
benthecarman, x402 #2861, merged 23 Sep 2026. The
exact scheme on lnbtc. The client pays a fresh BOLT11 invoice and returns the 32-byte preimage. The facilitator checks that SHA-256 of the preimage is the invoice payment hash, and that the invoice signing key matches payTo. The check needs no access to the receiver's Lightning node.THE INVOICE
The amount is an integer number of millisatoshis. The server hashes the request and puts that hash in the invoice description, so the proof is for this request. A replay store records the payment hash. The flow is upfront: the resource is served only after
/settle accepts the proof.BLOCK
24 Sep 2026: Block says it joined the x402 Foundation and contributed Lightning payments to the protocol. Steve Lee, head of Spiral, is quoted in the post. The merged scheme above is benthecarman's pull request.
THE PROOF
The preimage does not show how much was received, and Lightning can pay more than the invoice. The spec accepts the proof at the invoice amount, so the extra buys nothing more. The scheme has no refund path.
Stale Blocks, Address Spam, and a zkVM
Network observations from August, and a draft BIP for relaying stale tips.
SPIDERPOOL
24 Aug, height 963,853: SpiderPool mined two blocks. The winner ends
542c (11:28:27Z), the stale one a108 (11:25:04Z). mononaut: the stale block was built later and carried newer, higher-feerate transactions. Anthony Towns saw the winner 0.36 seconds before the loser.STALE TIP RELAY
BIP332 (Anthony Towns, w0xlt, Ram), merged as a draft on 9 Sep: an optional
staletip message announcing recent stale branch headers, and whether the sender will serve the blocks. Its case: stale-block rates track how fast blocks reach miners, and a node already holding a stale block reorgs faster.ADDRESS RELAY
mzumsande and stratospher, BNOC, 14 Aug. From mid-April to about 14 July an entity flooded address gossip; they report a tenfold rise. The spam met Core's relay rules: at most 10 addresses per
addr message, each timestamped within 10 minutes. It ended when the spammer stopped refreshing timestamps.CORE IN A ZKVM
defenwycke, Delving, 15 Aug: Bitcoin Core v28's own consensus code, including
interpreter.cpp and libsecp256k1, run in a RISC0 zkVM to produce STARK proofs of mainnet blocks. Block 962,000, with 8,006 inputs, took about 9.7 hours on one L40S GPU. The two-hour future-time rule cannot be proven: the guest has no clock.Invalid Blocks
deadmanoz, bitcoin-data/invalid-blocks. A header that meets proof of work and fails a named consensus rule. A stale block is the other case: it passes the rules and loses the race.
THE FILE
Split from stale-blocks. At commit
4fad71d (1 Oct), invalid-blocks.jsonl has 171 records, and reported-blocks.jsonl holds 12 whose failure is not established. The 23 September note counted 143. On 30 September, 27 descendants were admitted under prev_block_invalid. The site is generated from the dataset.TWO IN 2026
946,213 and 957,780, both
/F2Pool/, rule time_below_mtp. Their headers say 15 April and 29 June, but they were mined around 22 April and 13 July: 7 and 14 days behind the median time of the previous 11 blocks. Namecoin AuxPoW proofs bind the coinbases to the headers. b10c found neither in his logs; stratum.work shows forks at the next height, and he says SpiderPool mined on them.2012 P2SH
89 records, 1 April to 17 July 2012, all failing on a spend of the same output,
b0539a45…:1. Nodes enforcing the new P2SH rules rejected them. Older nodes accepted them, so the spend kept being mined for months. Four have reconstructed bodies; 85 are admitted from a proof of the transaction and the block's ordered txids.WHAT COUNTS
CI checks the named failure. A body failure needs a complete block, or a proof that reproduces the merkle root. Pool tags and payout addresses are read from bytes the header commits to. A report with no header or no body stays in the reported file. The checks do not replay every historical consensus rule.
App Store Wallet Binaries
@overtorment, 6 September 2026. He compared Apple App Store builds that advertise themselves as non-custodial with what those binaries do.
THE COUNT
He lists 904 apps marketed as non-custodial wallets and analysed 494 of the binaries. Forty-five raised a flag: 23 he rates critical and 22 high. He was looking for private-key exfiltration and weak entropy. He says a flag can be a false positive, and that an app missing from the list is not evidence it is safe.
THE METHOD
ipatool downloaded the store binaries, and Grok 4.6 analysed them. JavaScript bundles are easy for an LLM to read; native code is not, and he says a deeper pass would need decrypted binaries from a jailbroken device. The public source repository, when one exists, was not treated as the same artefact as the store build.
TWO BUILDS
Aura: Bitcoin Wallet, store build v27.27.60, posts the mnemonic, a WIF, and vault phrases to coffer.agency. He says the public GitHub code is local-only. "Bitcoin Wallet : BTC,ETH,USD" says it never has access to keys. He says its store build posts the recovery phrase and an EVM private key to xcryptowallet.org, in a field named
encryptedMnemonic, with no encryption step.HIS LIMIT
App Store search, ads, reviews, and the project's reputation do not establish what the binary sends. He says a single device should not be the only signer for a meaningful amount. The write-up is one person's static pass, published so the findings can be checked.