Maple AI : The main controversy around Taproot's activation wasn't about Taproot itself — the upgrade was broadly popular — but about **how to decide when and whether to enforce it**. Specifically, the fight was over who ultimately controls Bitcoin's consensus rules: **miners or node operators**. ## The Core Divide: BIP9 vs. BIP8 (LOT=True) The community split into two philosophical camps: - **BIP9 / "LOT=False" (Miner-driven):** This approach let miners signal support, and if they didn't reach a threshold, the upgrade simply failed. Proponents argued this was safer and less disruptive — don't force a rule change unless miners clearly agree. Critics called this giving miners a **permanent veto** over a widely desired upgrade. - **BIP8 with LOT=True (User-Activated Soft Fork / UASF):** This approach set a deadline by which miners had to signal; if they didn't, nodes would begin enforcing the new rules anyway, effectively forcing miners to follow or be orphaned off the network. Proponents argued this was necessary to prevent miner obstruction (citing the SegWit activation experience). Critics warned it could risk chain splits and network instability if not enough users actually ran the enforcing software. ## The Speedy Trial Compromise After months of stalemate, developers Russell O'Connor and David Harding proposed **"Speedy Trial"** as a middle path: - **Short trial period:** Miners got ~3 months to signal. - **High bar:** 90% of blocks in a difficulty period had to signal to lock it in. - **Fail-fast:** If miners didn't signal, the attempt died quickly — no automatic UASF fallback built into the Core client. - **Long delay:** If locked in, activation waited ~6 months to give everyone time to upgrade. This was essentially **BIP9-style miner signaling with a much shorter window**, designed to gauge actual miner support without embedding a mandatory UASF into Bitcoin Core's official release. ## Why It Was Controversial - **UASF advocates were unhappy** because Speedy Trial removed the built-in "safety net" that would force activation if miners stalled. Some released alternate Bitcoin Core clients with LOT=True as a hedge. - **Miner-veto critics** argued the process proved miners could still block things if they chose to, and that node operators had been sidelined. - **Governance concerns:** The debate exposed how Bitcoin's decentralized development process can deadlock when there is no clear mechanism for resolving activation disputes. ## Outcome Miners overwhelmingly signaled support, Taproot locked in, and activated successfully in **November 2021**. But the controversy left lingering questions about whether Speedy Trial was a pragmatic solution or a precedent that lets miners (or the status quo) stall future upgrades.

Large numbers + cryptography + computational proof via DA-POW **SOLVED BOTH** ✅coin emission without seigniorage ✅coordination = consensus = time stamping

BIP45 doesn’t introduce a new extended key prefix because: It works with standard xpubs (or ypubs/zpubs if the multisig is wrapped in SegWit or native SegWit, though BIP45 itself was designed around P2SH). It’s a layer above key format. The xpub/ypub/zpub tells you what address type the key produces; BIP45 tells you how multiple people agree on which addresses to produce.

So much to be grateful for...

Blackrock assets (in fiat) are worth 10-12x total bitcoin total market cap... Gold + AI stonks..... 100x ? 200x?..... Rotation in coming

JP Morgan + Morgan Stanley with record Q2 profits F-n bankers. Opt out. Use a money they cannot control.

#BrandonBlack "Within the tiny internet bubble of Bitcoin X (formerly Bitcoin Twitter or Crypto Twitter), there has been a lot of noise in the past year about @dathon_ohm’s proposal for a Reduced Data Temporary Softfork, otherwise known as BIP110. Underlying this proposal is the idea that certain Bitcoin transactions have been violating the principles of the network by including in their locking or unlocking scripts data that can be interpreted in one or more additional ways besides their plain Bitcoin script interpretation. According to BIP110’s supporters, reducing the use of these transactions is sufficient justification for the most confiscatory Bitcoin softfork to date, on a deployment timeline that is dramatically faster than the two most recent softforks, and with a lower activation readiness threshold. Bitcoin is an open-access, censorship-resistant ledger to which anyone can write entries if they are willing to pay fees sufficient to convince block template creators and miners to include their transaction. The fundamental value of Bitcoin vs. all other ledger systems is the aforementioned open access. Without it, Bitcoin’s ledger has no more value than the bowling alley scoreboard. Because of this fundamentally open access, we all know that Bitcoin will be used by those we hate. Much like the principle of free speech, which is meaningless unless it applies to speech that we don’t like, Bitcoin’s open access would be meaningless if it only applied to transactions of which you or I approve. I will therefore assume that we do not want to be in the business of inspecting how other people structure their ledger entries any more than we want them inspecting our entries. BIP110 proponents might say, “Sure, but that only applies to monetary entries! What about these non-monetary entries?”, but the reality is that there simply is no such distinction. Every transaction made on Bitcoin is made by satisfying the conditions of some locking script to make an entry in the ledger, which consumes input coins and creates output coins. The fact that one transaction’s scripts are larger or smaller than another is of no relevance to me as a Bitcoin node operator or user. First, I simply do not look at other people’s transactions. They’re no more my business than other people’s orders at the local café. Second, my node makes no such distinction. Transactions are either valid or invalid, and they are either costly to validate (like a large multisig) or cheap to validate (like one of these Ordinals or OP_RETURNs). One could argue that Bitcoin, like gold, would be a superior monetary asset if it could not also be looked at in other ways. Imagine if gold could not be used in industry or jewelry! It might be true that that would make it better as money. But of course, the very same properties that make gold good money also make it desirable in jewelry and industry. The same applies to Bitcoin. The very fact that Bitcoin allows anyone to make an entry if they are willing to pay the fees means that we must give up the idea that we can control how they will look at that entry. No matter what restrictions we put on the structure of the entries, it will always be possible to make entries that can be interpreted in other ways by non-Bitcoin software. So, both with Bitcoin and with gold, we accept that other use is inevitable. In gold, this leads to distortions in the market when non-monetary demand increases or decreases. In Bitcoin, this can lead to periods of higher transaction fees when there’s greater demand for its limited blockspace. In Bitcoin, we have two advantages that gold does not have. First, making Bitcoin transactions that can be viewed in alternative ways does not affect the market for Bitcoin itself. Unlike gold, very little Bitcoin is allocated to these uses. Second, in Bitcoin, we have a protocol that is already designed to minimize cost to the validation network from such other interpretations. Bitcoin limits both the size of blocks and the number of signatures that can be used in transactions. These are the greatest costs to validating nodes, and the protocol limits on them have been in place since the very early days of Bitcoin, precisely to prevent abuse by any high-frequency or high-volume use of the ledger. These limits have already spurred innovations such as the Lightning Network, Ark, Spark, Cashu, and many more. Even the boom in demand for blockspace caused by these “non-monetary” ledger entries (yes, that does sound ridiculous) has increased the use of these scaling solutions, which require fewer entries on the main ledger. With the justification for BIP110 thus explored, and hopefully shown to be woefully lacking, let’s look at the proposed change itself. BIP110 restricts the size of locking scripts, restricts the number of alternative scripts in taproot, makes the taproot annex invalid, removes all upgradable witness and tapscript versions, removes all tapscript upgradable opcodes, and makes OP_IF and OP_NOTIF invalid in tapscript. All of these restrictions apply to UTXOs created during the 52414 blocks (approximately 1 year) after its activation. BIP110 also proposes a miner readiness signaling threshold of 55% instead of the threshold used in prior miner signaled softforks of 90% or more. If 55% of blocks do not signal readiness before block 961632, nodes enforcing BIP110 will treat blocks not signaling readiness as invalid to force the change to lock in by block 963648 and activate by block 965664. BIP110 would be the most sweeping restriction of Bitcoin script since Satoshi’s well-known deactivation of many opcodes in response to a critical vulnerability (CVE-2010-5137) back in 2010. It proposes miner signaled activation with an unprecedentedly low threshold and node-forced activation after less than 9 months from the date the BIP was assigned a number. It does all of this because (as discussed above) other people are viewing certain ledger entries in ways which the BIP110 supporters do not approve of. Worse yet, the folks who use such disapproved ledger entries have already updated their software to continue making such entries even if BIP110 were to become Bitcoin’s consensus rule set. This was, of course, a predictable outcome (many of us explicitly predicted it) because it is fundamentally impossible to restrict how other people use external software to analyze entries on an open-access public ledger. In summary, BIP110 is a proposal to do something impossible (limit how users of an open access ledger use that ledger) in response to a problem that is already fully addressed through Bitcoin’s existing protocol limits. It proposes to do this impossible thing on an irresponsibly short activation timeline, with incredibly limited code review, and regardless of whether the change reaches any type of ecosystem consensus. Fortunately, Bitcoin is not such a delicate flower of a system that such a foolhardy attempt at modifying it will succeed. Not only have miners soundly rejected BIP110, but other voices throughout the developer, investor, influencer, and corporate landscape have spoken out against the changes. In August, this particular attack against Bitcoin’s consensus rules will have made Bitcoin stronger through its failure, and the network will continue its steady rhythm of tick-tock, next block."

If you have a couple of large LN channels + you can get paid in LN + NGU (say x10) from here , you actually may never need any more onchain bitcoin...., like never, for the rest of your life Change my mind meme

Everyone thinks their pet _topic_ explains the red/green candles: bip-110ers, Strategy dudes, suit-coiners, Clarity bros, Bent Oil watchers... Who the hell knows what's gonna happen. Same plan: Work Save Stack Wait

Be aware freaks, be aware

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.

They are spamming the network........meanwhile:

"It is an error to say that Core removed the ability for nodes to control their mempool policy regarding OP_RETURN and that Core removed the OP_RETURN limit at the protocol level."

Stacker News

The Case Against BIP110 \ stacker news

The Case Against BIP110 by Satonymous 2026-June-11 UTC This is to state the case against BIP110, and to bring awareness to various identified vulne...

Running 29.0, filtering large op_returns (83bytes) and chilln - ------- 27.0 became end-of-life when 30.0 was released in October 2025. The "last three versions" rule applies to major releases (27, 28, 29, 30, 31…), not a rolling 3-year window. Since major versions ship roughly every 6 months, each one is supported for about 12–18 months.

Running 29.0, filtering large op_returns (83bytes) and chilln This is plan for awhile