BitDevs 29_

Current-events framing for the seminar. Miner signaling is stuck under 1% — nowhere near the 55% lock-in bar — and Saylor and Adam Back both publicly came out against BIP-110 this past weekend. Saylor's line — "there are 110 things more dangerous to Bitcoin than spam" — captures the tone of mainstream opposition. The article also lays out the UASF mechanics: mandatory signaling window opens near block 961,632 in early August, and nodes running BIP-110 software start rejecting non-signaling blocks after that regardless of miner participation. Discussion hook: if the miners don't come along, does a UASF that produces a minority chain still count as "Bitcoin changing"?

The most complete neutral BIP-110 explainer we found. Walks through all seven consensus rules (34-byte output cap, 83-byte OP_RETURN, 256-byte data pushes, etc.), the UASF activation timeline (mandatory signaling ~block 961,632, lock-in 963,648, activation ~block 965,664 near Sep 1), and the one-year auto-expiry. Also notes the eCash hard fork (Paul Sztorc, block 964,000 around Aug 21) is a completely separate August event that keeps getting confused with BIP-110. Good reference to hand members who want the full picture in one page.

Live signaling data. BGeometrics publishes a daily block count for BIP-110 via a public API, so members can watch signaling in real time as we approach the flag day. Latest data has signaling hovering around 2–3% — far from the 1,109-out-of-2,016-block threshold needed for miner lock-in, but the value here is you can check yourself instead of trusting anyone's framing. Discussion hook: the more decisive signal to watch isn't the daily count, it's whether Foundry USA or Antpool ever moves.

The proponents' side, all in one place. Hodlonaut's three-part CAPTURE series argues Bitcoin Core's informal power structure got captured by the OP_RETURN uncap merge, Melvin Carvalho's code walkthrough audits the Knots reference implementation, and Kyle Santiago's "eviction notice" pieces make the moral case for BIP-110. Worth reading even if you disagree — the seminar shouldn't be one-sided, and this is where the pro-BIP-110 argument is best laid out. Discussion hook: is a soft fork that produces a chain split still a "soft" fork in any meaningful sense?

Short community argument that the soft-fork label is misleading when activation happens under 55% hashrate. Compares to SegWit (upgraded miners still accepted non-SegWit blocks) and points out BIP-110-enforcing miners will reject blocks containing large OP_RETURN transactions — which is the chain-split trigger. Sets up the reason our members should care: what looks like a soft fork on paper can produce a persistent split in practice.

The primary visual for the talk. Walks through Bitcoin's hard fork history and shows what a replay attack actually does with diagrams. Play this after the UTXO refresher so the mechanics land visually before we get into the specifics.

The 2018 Poloniex post-mortem. Cleanest explanation on the internet of why replay attacks happen — Alice has identical UTXOs on both chains after the split, her signature is valid on both, so a transaction meant for chain A gets rebroadcast to chain B and moves the matching output there too. Also documents the post-fork-output mixing technique exchanges used to protect withdrawals when SV shipped without replay protection. Directly relevant because BIP-110 explicitly includes no replay protection — if a persistent minority chain forms, we're in the same position as August 2017.

The technical grounding for the UTXO segment. Song's UTXO explainer is the clearest short-form intro you can point a member at, and his replay-protection techniques (post-fork coinbase-descended UTXOs, simultaneous submission, locktime tricks) show why moving coins during a fork is genuinely dangerous rather than just theoretically risky. We're not teaching members to actively split coins — we're using this to make the case that if you don't understand what's on the page here, you have no business trying to trade the split.

Calle's thread frames the whole situation in one place: after BIP-110 and BIP-300 fork off you'll technically hold fork coins on both chains, they're most likely worthless, and the ways members actually lose funds are (1) seed-phrase-stealing "splitter" wallets that show up during every fork promising to help you claim your coins, and (2) the privacy leak — because the fork mirrors Bitcoin's history, whichever fork UTXO you connect to your identity also doxxes your entire real BTC stack. Both risks disappear the moment you decide to do nothing. This thread is the tone of our talk: the coins will exist, they don't matter, and the temptation to touch them is the actual threat.

The 2017 playbook, written for the Bitcoin Unlimited threat but every rule still applies. Move coins off exchanges before the window (exchanges freeze withdrawals during forks and may or may not credit you on both chains). Control your own keys. If you don't need to transact during the window, don't — the safest response to a chain split is to do nothing until the situation stabilizes.

The hardware-wallet reference for what a well-executed fork response looks like. Trezor explained what would happen, shipped firmware before flag day, used separate BIP44 derivation paths (BCH on m/44'/145'/) so fork addresses couldn't overlap with BTC ones, and required users to explicitly "claim" fork coins into a new wallet before spending. Two takeaways for members: check your hardware wallet vendor's fork plan before August, and don't touch fork coins until your vendor has told you how.