Spotify

If MicroStrategy Crumbles Will Bitcoin Fail? | Larry Lepard | Simply Originals

Simply Bitcoin · Episode

High signal + humor for the win

THE BATTLE FOR BLOCKSPACE

A live, satirical visualization of Bitcoin

what is really happening

I wonder how many of the BIP-110ers (maniacal plebs @npub1s33s...252p) actual run LN nodes.... or use bitcoin? LN is helping scaling bitcoin and adds privacy. LN is actively being integrated into on-ramp/off-ramps, businesses, payment processers to the leagacy fiat system. Channel rebalancing via submarine swaps is a key tool for channel management. Taproot allows for better privacy + lower fees compared to P2WSH. BIP-110 activation can (will?) invalidate this swap method. Chance of unknown/inforseen issues of the 110-fork are definitely not zero. Consensus should be hard to change. Very hard. Rationale needs to be compelling + clear to most plebs, not just a self anointed _maniacal_ few...

BIP-110 does not break legacy or pre-existing vaults, but it does break the ability to create new Taproot Miniscript vaults that depend on OP_IF branches. If Taproot miniscript vaults/wallets or its users generate new vault addresses with unupdated software after activation (assumes BIP-110 fork wins), those funds are at risk of being temporarily unspendable. BIP-110 authors disagree on necessity — some argue there is "no known use case" requiring OP_IF in Tapscript, implying the fee increase from using more leaves is acceptable. Critics counter that this ignores real-world vault architectures and security models that rely on composable script-level branching. Bottom line: For simple two-path vaults, yes — you can generally avoid OP_IF by using native Tapleaf disjunction. But some style institutional vaults often involve complex multi-party, time-locked, and threshold policies where decomposition either explodes past the 128-leaf limit or fragments the security model in ways that aren't practically deployable before the August 2026 activation deadline. So while a theoretical workaround exists, "just don't use OP_IF" is not a complete answer for every vault design.

Bitcoin is for everyone/anyone.... This can be quite uncomfortable at times. No alternative. Governed by decentralized rough consensus.

Bitcoin is for everyone/anyone.... This can be quite uncomfortable at times. No alternative. Governed by decentralized rough consensus.

Replay details via Maple AI: Here’s exactly how it works: **Before the split:** Both chains share the identical blockchain history and the identical UTXO set. Your coins live at the same address, with the same txid and output index, on both the Core chain and the BIP-110 chain. **You sign and broadcast on Core:** You create a standard transaction spending your pre-fork UTXO to some new address. You sign it and broadcast it to the Core network. It gets mined into a Core block. **The replay step:** Because BIP-110 is a soft fork, a standard, valid Core transaction is *also* a valid BIP-110 transaction. The transaction format hasn’t changed. The signatures are valid. The inputs exist on both chains. So anyone — it could be the recipient, a miner, or literally any observer — can take the raw transaction hex from the Core block (or mempool), and just re-broadcast it to the BIP-110 network. BIP-110 nodes see it and say, “Yep, that’s a valid transaction spending a valid UTXO,” and mine it into a BIP-110 block. **The result:** Your UTXO moves to the destination address on *both* chains simultaneously. You never intended to move it on BIP-110, but it moved anyway because the transaction was valid there too. **Why this matters:** If you were trying to sell your “BIP-110 coins” to an exchange while keeping your “Core coins,” the replay means both get sent to the exchange. Or if you were trying to split your coins by sending them to different addresses on each chain, replay undoes that — the same transaction executes on both sides. **The exception:** This only works for pre-fork UTXOs. If a UTXO was created *after* the fork on only one chain (like a coinbase reward, or a transaction spending a post-fork UTXO), it can’t be replayed because it doesn’t exist on the other chain. That’s why, without explicit replay protection, a chain split is so messy: every pre-fork coin is entangled across both chains until you deliberately “taint” or split them using techniques like mixing with coinbase outputs or `nLocktime` tricks.

Replay details via Maple AI: Here’s exactly how it works: **Before the split:** Both chains share the identical blockchain history and the identical UTXO set. Your coins live at the same address, with the same txid and output index, on both the Core chain and the BIP-110 chain. **You sign and broadcast on Core:** You create a standard transaction spending your pre-fork UTXO to some new address. You sign it and broadcast it to the Core network. It gets mined into a Core block. **The replay step:** Because BIP-110 is a soft fork, a standard, valid Core transaction is *also* a valid BIP-110 transaction. The transaction format hasn’t changed. The signatures are valid. The inputs exist on both chains. So anyone — it could be the recipient, a miner, or literally any observer — can take the raw transaction hex from the Core block (or mempool), and just re-broadcast it to the BIP-110 network. BIP-110 nodes see it and say, “Yep, that’s a valid transaction spending a valid UTXO,” and mine it into a BIP-110 block. **The result:** Your UTXO moves to the destination address on *both* chains simultaneously. You never intended to move it on BIP-110, but it moved anyway because the transaction was valid there too. **Why this matters:** If you were trying to sell your “BIP-110 coins” to an exchange while keeping your “Core coins,” the replay means both get sent to the exchange. Or if you were trying to split your coins by sending them to different addresses on each chain, replay undoes that — the same transaction executes on both sides. **The exception:** This only works for pre-fork UTXOs. If a UTXO was created *after* the fork on only one chain (like a coinbase reward, or a transaction spending a post-fork UTXO), it can’t be replayed because it doesn’t exist on the other chain. That’s why, without explicit replay protection, a chain split is so messy: every pre-fork coin is entangled across both chains until you deliberately “taint” or split them using techniques like mixing with coinbase outputs or `nLocktime` tricks.

Replay details via Maple AI: Here’s exactly how it works: **Before the split:** Both chains share the identical blockchain history and the identical UTXO set. Your coins live at the same address, with the same txid and output index, on both the Core chain and the BIP-110 chain. **You sign and broadcast on Core:** You create a standard transaction spending your pre-fork UTXO to some new address. You sign it and broadcast it to the Core network. It gets mined into a Core block. **The replay step:** Because BIP-110 is a soft fork, a standard, valid Core transaction is *also* a valid BIP-110 transaction. The transaction format hasn’t changed. The signatures are valid. The inputs exist on both chains. So anyone — it could be the recipient, a miner, or literally any observer — can take the raw transaction hex from the Core block (or mempool), and just re-broadcast it to the BIP-110 network. BIP-110 nodes see it and say, “Yep, that’s a valid transaction spending a valid UTXO,” and mine it into a BIP-110 block. **The result:** Your UTXO moves to the destination address on *both* chains simultaneously. You never intended to move it on BIP-110, but it moved anyway because the transaction was valid there too. **Why this matters:** If you were trying to sell your “BIP-110 coins” to an exchange while keeping your “Core coins,” the replay means both get sent to the exchange. Or if you were trying to split your coins by sending them to different addresses on each chain, replay undoes that — the same transaction executes on both sides. **The exception:** This only works for pre-fork UTXOs. If a UTXO was created *after* the fork on only one chain (like a coinbase reward, or a transaction spending a post-fork UTXO), it can’t be replayed because it doesn’t exist on the other chain. That’s why, without explicit replay protection, a chain split is so messy: every pre-fork coin is entangled across both chains until you deliberately “taint” or split them using techniques like mixing with coinbase outputs or `nLocktime` tricks.

@miljan seems to be a bug when I try to respond to notes. Can't post.

There's actually no difference between personal financial responsibility versus: business, corporate, wall-Street and gov/sovereign finances. They're just trying to confuse us. Don't let them fool you. You (they) can't wiggle your way out of the reality that you have to put in the work to get the reward. You have to work and save. There's no +financial engineering* magic that happens. Work. Save. That's it. They create confusion around financial vocabulary / double speak - but it's just comes down to: Are you gonna work more than you spend or not. Be productive. Be a saver. Save the best money you can acess. This is true for individuals, groups, communities, states, nations, governments, all of us. It's actually not that complicated. ignore the noise.

contentious soft fork, what will exchanges do. Maple AI: Yes, exactly. Listing both sides and letting them trade against each other is the only way to produce a honest economic signal. If exchanges do that, the market immediately tells miners which chain is more valuable, and miners switch to the higher-revenue chain almost mechanically. But here is the reality: exchanges usually do not want to provide that clarity. Why Exchanges Avoid Listing Both 1. Operational and legal risk A contentious fork means replay attacks, address format confusion, deposit/withdrawal exploits, and double-spend attempts. Supporting two "Bitcoins" simultaneously requires engineering work, legal review, and customer support chaos. Most exchanges would rather avoid that entirely. 2. Brand and reputational risk An exchange that lists a forked coin implicitly legitimizes it as a real asset. Many exchanges do not want to be seen as endorsing what they view as an attack on Bitcoin, or conversely, they do not want to anger the community by appearing to validate a contentious rule change. 3. They prefer to act as kingmakers If an exchange pre-announces "we will only recognize the non-signaling chain as BTC," they have effectively short-circuited the market signal. Miners now know that signaling for BIP-110 might win the technical war but lose the economic one — their coinbase rewards will not be spendable at the exchange where they pay bills. This lets exchanges pick winners without ever allowing price discovery. What Actually Happens In practice, most major exchanges will likely: Halt deposits/withdrawals during the activation window Wait to see which chain accumulates more proof-of-work or which one their counterparties recognize Eventually resume trading on one side as "BTC" Maybe, grudgingly, credit the other chain as a separate asset weeks later if it survives This is what happened with BCH and BSV. The delay and confusion actually obscured the signal rather than clarifying it. Why Your Point Matters If exchanges did list both immediately — call them BTC-filter and BTC-spam or whatever — the community would see within hours which one the market values more. Hashrate would follow the price within days. The uncertainty would resolve quickly through actual price discovery instead of Twitter warfare. So yes, listing both coins would make the signal far clearer. The fact that exchanges resist doing so is precisely what makes contentious forks so dangerous — the market is prevented from speaking clearly, and politics fills the void.

Two numbers: ✅21 million fixed by math, energy and human incentives ✅39.4 trillion unbounded by math and human incentives

Two numbers: ✅21 million fixed by math, energy and human incentives ✅39.4 trillion unbounded by math and human incentives

Two numbers: ✅21 million fixed by math, energy and human incentives ✅39.4 trillion unbounded by math and human incentives

Antifragile. Bring it on