Lightweb Inc. 🇺🇸 Infrastructure Engineering Unbounded Solutions for a Small World (TM)

Texas, USA
Joined February 2011
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.
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.
2
20
482
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.
1
2
27
535
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.
3
2
33
710
BEEF is the other half of this, of course, and is required for placing transaction data on the overlay object multicast plane, and is propagated outwards. Consumers preserve these proofs to verify via the Merkle root hash in the headers. Headers distribute widely. SPV is cheap!
1
6
225
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!
24
63
10
211
5,560
Light retweeted
You don't store or move data in the control plane. You don't control from the data plane. Mine the state, not the data.
2
7
174
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.
2
1
25
740
Scalable BSV Bitcoin at the settlement layer with wide BEEF distribution and SPV validation for application/service layers above provides the substrate for this to form and be a viable solution.
1
2
187
You don't store or move data in the control plane. You don't control from the data plane. Mine the state, not the data.
2
7
174
Light retweeted
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.
1
1
9
558
Light retweeted
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.
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.
1
1
4
271
It only has a middleman if you have someone else run your messagebox. Run your own, or don’t receive payments while offline.
1
2
6
368
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.
2
7
328
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.
BRC-100 is the most professionalized wallet scaling solution standard there is. It's been adopted by BSVA as the architectural basis of their wallet work. BSVA is in the best position currently to know what BSV needs to actually be able to scale to high throughput.
2
1
16
666
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.
1
7
545
Light retweeted
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?
2
1
5
285
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.
5
3
1
40
1,485
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.
Nasdaq breaks: *NASDAQ CURRENTLY EXPERIENCING A NETWORK DISRUPTION *NASDAQ: DISRUPTION AFFECTING MULTIPLE MULTICAST GROUPS *NASDAQ: DISRUPTION ORIGINATING FROM CARTERET
1
4
27
677
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…
21
539
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.
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.
1
33
810