Contributed Article
BSV TIMES — Featured Post
Billion-TPS Scale Needs Better Roads, Not Louder Shouting
Featured source: Craig Wright’s paper, Multicast Within Multicast: Anycast, Sharded Resends, and Hierarchical Distribution for Transaction and Block Propagation.
BSV Blockchain has always carried a larger scaling ambition than ordinary blockchain systems. The goal is not merely to process a few more transactions, or to make blocks a little larger. The goal is global-scale utility: payments, data, records, applications, enterprise systems, machine activity, and high-volume digital commerce operating on one stable ledger.
Craig Wright’s paper focuses on one of the least discussed but most important parts of that ambition: how the information actually moves across the world.
At small scale, a network can survive by passing transactions around from one machine to another, hoping that everyone eventually receives the same information. That is the old “gossip” model. One node tells another. Then another repeats it. Then another repeats it again.
For a small network, this may be enough.
For a billion-transactions-per-second world, it is not.
A global blockchain cannot depend on digital rumour-spreading. It needs a professional delivery system.
The Real Bottleneck Is Not Only the Blockchain
The paper’s larger message is important for the BSV community:
Billion-TPS scale is not only a blockchain-engineering problem. It is also a global communications-infrastructure problem.
BSV Blockchain may provide the ledger and processing model. But the surrounding delivery system must also become structured enough to carry that scale.
That means the future scaling conversation cannot only be about block size, node software, or transaction processing. Those matter, but they are not the whole picture.
At very large scale, the system also depends on how well the wider communication environment works: internet routing, IPv6 deployment, multicast support, anycast infrastructure, packet repair systems, and professional data-distribution networks.
In plain terms, BSV Blockchain may be the ledger.
But the world still needs the roads.
Why Ordinary Transaction Sharing Is Not Enough
The paper criticizes three old habits: gossip, one-to-one sending, and mempool flooding.
In plain terms, these are all versions of the same weakness: too much repeated traffic, too little structure, and no clean way to know what was missed.
If every node keeps sending the same transaction to many other nodes, bandwidth is wasted.
If miners receive transactions in different orders, synchronization becomes harder.
If some data is missed silently, the system may not know immediately where the gap is.
At BSV scale, these are not minor technical details. They affect transaction ordering, mempool synchronization, block propagation, miner coordination, missing-data detection, and consensus-facing data completeness.
That last phrase matters.
Consensus does not happen in a vacuum. Miners need the right data, in the right order, with a reliable way to know whether anything is missing. A miner cannot properly validate what it has not received.
The Better Idea: Send Transactions Into the Right Lanes
The paper’s core idea can be understood simply:
Do not shout every transaction everywhere. Send each transaction into the correct lane.
Think of a modern road system.
A serious road system does not throw every vehicle onto every road. It uses highways, lanes, junctions, exits, and delivery routes. Traffic is not solved by noise. It is solved by structure.
The same idea applies here.
A transaction should enter the network through the nearest practical entry point. From there, it should be placed into the correct stream, based on its own identity. Miners who need that stream receive it. If something is missing, the gap should be visible. If only one piece is missing, only that piece should be resent.
This is a much cleaner model than flooding the network and hoping everything arrives.
The Nearest Door Into the Network
One important part of the paper is the idea of using the nearest suitable entry point.
A wallet or app should not have to know which miner, node, or relay to contact. It should be able to send a transaction to a common entry address, and the internet routing system should deliver it to a nearby entry point.
In plain terms:
The transaction enters through the nearest door.
This matters because distance creates delay. A user in Bangkok, London, Nairobi, or São Paulo should not have to think about network routing. The system should handle that intelligently.
This is one reason the paper points toward technologies such as anycast and IPv6. These are not just technical decorations. They are part of the surrounding communications infrastructure that may be needed for true global scale.
Every Transaction Finds Its Own Lane
After the transaction enters, the next step is sorting.
The paper proposes that a transaction can be assigned to a specific delivery lane based on its transaction ID. That ID works like a fingerprint. From it, the network can determine where the transaction belongs.
This is important because the decision is not arbitrary.
No committee needs to decide where a transaction goes. No miner needs to guess. No central operator needs to assign a route.
The transaction’s own identity determines its path.
In plain terms:
Every transaction carries the information needed to place it into the right lane.
That makes the system easier to check, easier to organize, and harder to confuse.
Main Roads, Smaller Roads, Specialized Roads
The paper describes a layered system. In plain terms, it can be imagined as a road network.
There is a main road that all miners watch. This carries the essential information: block headers, key ordering information, and the signals everyone must see.
Then there are many transaction lanes. These carry the main flow of transactions, divided into manageable streams.
Then there can be more specialized lanes for particular applications, data types, or transaction categories.
So the structure becomes:
main road → transaction lanes → specialized lanes
This matters because not every piece of information needs to be shouted to everyone in the same way. A miner that wants full visibility can listen broadly. A service that only needs certain flows can listen selectively. But the structure remains predictable.
That is the key balance:
flexibility without chaos.
Missing Data Must Not Be Silent
At global scale, some data will occasionally fail to arrive. That is normal in any large network. The issue is not whether loss can happen. It will.
The real question is:
Can the system see what is missing?
In an unstructured gossip system, missing data can be hard to detect. A miner may silently miss a small part of the transaction flow and not immediately know it.
That is unacceptable for infrastructure.
The paper’s answer is to number the pieces of information in each lane. If the sequence goes:
1, 2, 3, 5
then everyone can see that 4 is missing.
That is a simple but powerful idea. Loss becomes visible. Once visible, it can be repaired. The miner does not need to ask for everything again. It only asks for the missing piece.
This is where packet repair systems become important. A serious data network must not merely send information. It must also detect gaps and repair them efficiently.
For billion-TPS scale, that may be one of the most important parts of the design.
Blocks Need the Same Discipline
The same logic applies to blocks.
A large block should not be treated as one giant object that must be pushed clumsily across the network. The block can be understood as organized data made from many transaction flows.
The block header goes through the common channel that all miners watch. The larger transaction data can move through the structured lanes. Miners can then check that the pieces they have match the block commitment.
In plain terms:
The network does not need to resend what miners already have. It needs to help them confirm that what they have is complete, ordered, and correct.
This is where block propagation and miner coordination become deeply connected. The issue is not only moving big blocks. It is making sure miners can reconstruct the same complete picture from the same ordered data.
That is what makes consensus-facing data completeness so important.
Why This Matters for BSV Blockchain
For the BSV community, this paper fits into a much larger theme.
Scaling is not just about capacity inside the blockchain. It is also about the world around the blockchain becoming capable of carrying that capacity.
BSV Blockchain can provide the ledger, the processing model, the economic incentive system, and the low-fee transaction environment. But if the surrounding communication layer remains noisy, wasteful, and unstructured, global scale becomes harder than it needs to be.
This is why internet routing, IPv6, multicast support, anycast infrastructure, packet repair systems, and professional data-distribution networks matter.
They are not separate from the scaling conversation.
They are part of it.
A billion-TPS system is not built by making one part larger while leaving everything around it primitive. It requires the ledger, miners, applications, and communications infrastructure to mature together.
The Plain Message
The paper’s message can be reduced to this:
Bitcoin at global scale cannot work like a crowd repeating rumours. It must work like a well-designed delivery network.
Each transaction should enter through the nearest door.
Each transaction should be placed into the correct lane.
Each lane should be ordered.
Missing pieces should be visible.
Only missing pieces should be resent.
Blocks should be assembled from the same ordered structure.
Miners should be able to stay coordinated without wasting bandwidth.
And the broader internet infrastructure must be capable of carrying this level of organized data flow.
This does not weaken the BSV scaling thesis. It strengthens it by making the challenge clearer.
BSV Blockchain may be the ledger.
The world still needs the roads.
Plain-Term Glossary
Multicast
One-to-many delivery. Information is sent once into a shared channel, and many receivers can receive it.
Anycast
A way of sending data to the nearest suitable entry point. In the essay’s road metaphor, it is like entering through the nearest door into the network.
Unicast
One-to-one delivery. One machine sends the same information separately to each receiver. At very large scale, this becomes inefficient.
Gossip
A network style where information spreads by repeated sharing from node to node, like a rumour moving through a crowd.
Shouting louder
Your essay’s plain-language metaphor for repeating the same transaction everywhere instead of improving the delivery structure.
P2P gossip
Peer-to-peer spreading by repetition. Useful at small scale, but not ideal for billion-TPS infrastructure.
Transaction propagation
How a transaction moves across the network after it is created.
Block propagation
How a completed or proposed block is distributed so miners can see, check, and respond to it.
Mempool synchronization
Keeping miners’ pools of waiting transactions aligned, so they are not working from very different views of the network.
Transaction ordering
The order in which transactions are received, arranged, and included. At scale, order cannot be left to chance.
Missing-data detection
The ability to know when a piece of information did not arrive.
Packet repair
A method for requesting only the missing piece of data instead of resending everything.
Consensus-facing data completeness
A more technical phrase meaning miners need enough complete data to validate blocks and maintain agreement.
Internet routing
The way data travels across the public internet from one place to another.
IPv6
The newer internet addressing system, important because it allows far more addresses and more advanced network design.
Professional data-distribution networks
Industrial-grade systems for delivering large amounts of information reliably, rather than relying on casual peer-to-peer spreading.
Teranode
BSV Blockchain’s scaling node architecture.
Restored base protocol
The stable foundation of BSV Blockchain after returning Bitcoin’s base rules to their intended form.
Transaction ID
The unique fingerprint of a transaction.
Block header
The compact summary of a block that miners and nodes can use to identify and verify it.
Billion-TPS
Billion transactions per second.
BSV TIMES 
Leave a comment