Everything I'm working on right now is designed to push on-chain (control plane) throughput higher, but in a way that scales the data plane to do real world work that people can benefit from. Others are focused on future-facing. I want to solve the many hard problems of today.
Replying to @kurtwuckertjr @BitcoinSvGuide
If we're many years away from dealing with 'high throughput', then what is going to keep the miners alive? Goodwill?
Miners need revenue today. I am hyper focused on this. I want no barriers. This is why I push the scaling path so hard. It is paramount for survival.
Data on Bitcoin can be checked by anyone, whether or not it was ever mined. If a network hands that data to everyone at once, it had better be data nobody can mine: whoever holds a mineable transaction holds the right to settle it.
Bitcoin block headers (80 bytes) are a strong candidate for universal radio transmission broadcast. Multicast can distribute to thousands, or even millions of radio stations at the same time. All the information necessary to perform light-weight small-value verification globally.
Light retweeted
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.
With BSV Layered Multicast, the internet gets divided into a control plane, and a data plane. The same network architecture paradigm that router vendors and major ISPs build on, except this is at a higher conceptual level, above the unicast IP routing and peering topology.
Replying to @JonathanVaage
SPV can only be used to prove the inclusion of a spend, not the absence of one. The only thing that could prove a negative would be an index, and that brings us back to designs that potentially don't scale.
It's an anti-pattern to try and get miners to attest to anything, because that's not in their business model, really. The UTXO store is on the node's hot path. Teranode by default will only remember who spent an output for about 2 days currently.
It could maybe be an adjunct service, but then, again, we're back to an index that becomes harder and harder to maintain as throughput increases.
You could design something like a state lease. In this, if you have seen no spends after the time runs out, then you can concur that there has been no change. The lease would either expire, or need to be renewed.
In case it isn't clear, this is an example implementation of a distributed, competitive, decentralized way to do Identity Access Management (like AWS or GCP IAM), while tying the state to the blockchain, and using SPV.
We're starting to get real cloud service tool capabilities.
Light retweeted
Replying to @BitcoinSvGuide @johncalhooon @cryptorebel_SV @ProjectBabbage @kurtwuckertjr @BitcoinSVtrain @JoelDalais @deggen
It only has a middleman if you have someone else run your messagebox. Run your own, or don’t receive payments while offline.
Some good discussion here on BRC-100, message boxes, and how there is room for many competing solutions as long as they work and scale properly, and benefit users.
Metanet Meetup 10/16/2026 xitter.cf/i/broadcasts/1AGRnZAkp…
Use BRC-100, or implement a comparable solution if you'd like to scale along with BSV into high-throughput territory.
Or, just stick with what you're doing and hope for the best. Maybe someone will come along and fix things when they stop working.
Scaling is paramount in BSV.
In most products, removing a member disables an account and leaves the shared keys unchanged. borg makes removal an on-chain re-key that every host enforces, and records every group change in an order nobody can forge.
Replying to @JoelDalais
I didn't say that at all. I said show the alternative. Show how it scales better, or adequately. If you want to interpret what I say differently, then that's on you. We don't have anything better currently. If we do, then show it.
Why assume I'm telling people to get out?
Don’t like BRC-100? Don’t like Teranode? Don’t believe in SPV? Don’t like message boxes, payment protocols, invoicing, and other artifacts of a professional solution? Then go implement your own. Let’s see how you scale. If you can’t then your opinions may not be very compelling.
Multicast in the real world.
Standard multicast can't acknowledge every packet is received by every subscriber.
I bet they don't use Negative-Acknowledgement retransmission facilities like BSV Layered Multicast.
BSV transmission gaps are repaired automatically by the network.
Every application's objects can ride one multicast plane. No application wants more than a sliver of it. The fix is eight bits of the topic's hash. They turn one firehose into lanes the network itself can shape.
New paper: 1bsv.net/papers/object-plane…
I was already scaling high-traffic internet sites in the mid to late 90's. Those older versions of Linux couldn't handle high traffic web httpd properly. Sun Ultra servers would fall over. The only thing that held up was FreeBSD 2 with custom compiled kernel settings. Moved to Apache mod_perl eventually. Good times.
Replying to @T_o_d_d_P @kurtwuckertjr
I was already deep in tech. Racks of TV broadcast gear at the KDFI Channel 27 studio in Dallas, Texas. My job was all internet-related facilities management, site management, and show production help for NetTalk Live! We'd do millions of page hits in a 2 hour period on Sundays.











