I'm going to use Joel's post here as an opportunity to explain why we're doing what we're doing at BSVA and the BRC process (which was started in large part thanks to @ProjectBabbage) Backwards compatibility is a virtue, until what you’re staying compatible with is the bottleneck. Joel’s point is fair in general. New software usually should respect what came before. But the way Bitcoin wallets have always worked is not how Bitcoin was designed to work. It’s a workaround that stopped working the moment BSV got busy. We’ve already tested it at scale. BSV has mined blocks of nearly 4GB. When application traffic peaked, the network kept producing blocks. What fell over was everything around it: indexers, exchanges, explorers, ElectrumX servers, and services that tried to keep up by scanning the whole chain for every address they cared about. Mining scaled. The application layer didn’t. That’s the core problem with the ElectrumX model. A wallet asks a server, “What happened to my addresses?” To answer, that server has to index everyone’s history. Its cost grows with the whole network, not with its users. At 4GB blocks, that design isn’t old-fashioned. It’s broken. Satoshi’s design was different. Payments go directly between the people involved. The original client even let you pay straight to an IP address. The whitepaper describes Simplified Payment Verification (SPV): you keep block headers and check a Merkle proof for the transactions that matter to you. Nobody has to watch the entire chain on your behalf. That’s what the BRC-100 stack is built on. Transactions travel peer-to-peer with their own proofs attached (BEEF), and wallets verify them against headers. Your wallet’s workload grows with your own activity, not the world’s. Does that make us right about everything? No. People raised real criticisms of MessageBox, and that’s directly why work is now underway (Thank you @deggen !) on WebRTC-based peer-to-peer connections. Keep the criticism coming. Better still, contribute. We want this to be the most scalable, usable stack ever built, and that takes people breaking it. But “it’s not compatible with how we’ve always done things” isn’t a reason to stop. How we’ve always done things is what failed under real load. The miners are ready for terabyte blocks. Wallets and apps have to be designed to keep up now, not after the next wave of traffic takes them down again. I think Joel, Cryptorebel, and others are raising good points that require us all to communicate in good faith. I hope to be a part of facilitating that conversation moving forward!

I want to address some of the common responses to this I've seen. The biggest misconception about Bitcoin: “It isn’t real until it’s confirmed.” Yesterday someone sent a transaction over a handheld radio with no internet and no phone signal. The pushback came straight away: “It doesn’t count until it settles on the blockchain.” That objection gets something basic wrong about how commerce works, and about how Bitcoin was designed. Accepting a payment and settling it were never the same thing. When a shop takes a cheque, the money hasn’t moved yet. Card payments settle days later and can be reversed months later. Merchants accept them anyway, because commerce has never run on certainty. It runs on managed risk. The whitepaper says so in its first paragraph: under the existing system, “a certain percentage of fraud is accepted as unavoidable.” Satoshi answered this in 2010. In the “Bitcoin snack machine (fast transaction problem)” thread, he described accepting payments in seconds with “good-enough” checking. When someone pushed back, he wrote: “I didn’t say impermeable, I said good-enough,” and said the loss in practice would be “far lower than with credit cards.” He wasn’t selling a technical utopia. He was describing how real businesses work. What the merchant actually knows offline With Bitcoin (BSV), the customer presents the transaction along with Merkle proofs for its inputs. The merchant checks those against block headers stored on their own device. No internet is needed. In seconds they know the coins exist, they’re in the chain, and the signatures are valid. The only remaining risk is a double-spend. Think about what that means in a physical shop. The customer is standing at your counter, on your cameras, buying something in person. Double-spending you there isn’t a clever attack on the protocol. It’s fraud, it’s a crime, and you know who did it. That’s exactly the same protection that kept cheques working for a century. Confirmations are a dial the merchant sets, not a rule the network imposes. Section 11 of the whitepaper works out double-spend probability as a function of how many blocks you wait. That only makes sense if the recipient chooses how long to wait. So: - A coffee or a bus fare: accept it instantly. - A laptop: maybe wait for the network to see it. - A car: wait for confirmations before you hand over the keys. Same protocol, different decisions, because the economics are different. Where the misconception came from Many people believe “Bitcoin needs confirmations” because BTC changed its relay policy so that unconfirmed transactions can be replaced (Replace-By-Fee). Once replacement became the norm, zero-confirmation payments stopped being trustworthy there, and a generation of users learned that waiting for blocks was the only safe option. That was a policy choice, not part of Bitcoin’s design. BSV kept the original first-seen rule, so the payment that reaches the network first is the one that counts. The bottom line Bitcoin was built for the real world, where there are laws, identities, cameras, reputations and courts. It was never meant to replace all of that with block confirmations. It was meant to make payments cheap, instant and final enough for the risk involved. Offline payments on BSV aren’t a workaround. They’re the system working as Satoshi described it.

BSV is what Bitcoin was always meant to be!