Satoshi had a Vision
What Satoshi Nakamoto wrote about scaling on one chain, about money for everyday commerce, and about what bitcoin was not, in his own posts, reproduced as they first appeared.
The V in BSV stands for Vision: Bitcoin Satoshi Vision. The name is a claim about what bitcoin was meant to be, and the clearest way to see what it means is to read what Satoshi Nakamoto wrote while he was building it.
Most of the imagery and the vocabulary a designer inherits from bitcoin came later: digital gold, laser eyes, a badge of membership. Satoshi's own posts describe something plainer. Electronic cash, cheap enough to pay a few cents with, on one chain that grows as it is used, offered as a better way to pay rather than a way around the law.
Each post below is reproduced as it looked where he posted it: the Cryptography mailing list, the bitcointalk forum, or the P2P Foundation forum. The words are his and unedited, spelling included. Where a post is cut, the cut is marked with an ellipsis, and every one links to the original.
One chain that grows
The first objection to bitcoin, two days after the paper was posted, was that it could not scale. Satoshi's answer was arithmetic. He took the busiest payment network he could name and worked out what carrying all of it would cost.
Bitcoin P2P e-cash paper
Satoshi Nakamoto satoshi at vistomail.com
Sun Nov 2 20:37:43 EST 2008
If hundreds of millions of people are doing transactions, that is a lot of bandwidth - each must know all, or a substantial part thereof.
Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware.
The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.
He said the same on the forum two years later, more bluntly: a network where every user runs a full node was the starting point, not the design.
satoshi
Founder
Sr. Member
Activity: 364
Merit: 9152
Re: Scalability and transaction rate
July 29, 2010, 02:00:38 AM
#17
The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.
The block size limit that later became the centre of the argument was added quietly in July 2010. When somebody posted a patch to raise it that autumn, Satoshi told people not to run it, because it would split them from the network, and said how the limit would be raised instead.
satoshi
Founder
Sr. Member
Activity: 364
Merit: 9152
Re: [PATCH] increase block size limit
October 04, 2010, 07:48:40 PM
#8
It can be phased in, like:
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.
And he was clear that the rules underneath should not keep changing. A protocol that people build businesses on has to hold still.
satoshi
Founder
Sr. Member
Activity: 364
Merit: 9152
Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
June 17, 2010, 06:46:08 PM
#2
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of.
…The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
What this means for a design. BSV took these posts at their word: the block size limit is gone, the original protocol is restored and held still, and most people use light clients rather than full nodes. That is why a BSV product can treat a payment of a fraction of a cent as normal, and why it should never ask an ordinary user to run a node. See Payments.
Money for everyday commerce
The software was announced to a general audience on the P2P Foundation forum, and the post leads with a cost problem, not an ideology: trusted middlemen are expensive, and the expense rules out small payments.
Bitcoin open source implementation of P2P currency
The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.
…It's time we had the same thing for money. With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.
The complaint is about cost and trust, not about banking itself. The headline Satoshi put in the very first block makes the same distinction: it reports a government bailout of the banks, not a failure of banking. See Common misconceptions.
A month earlier, on the mailing list, he had described what that would make possible.
Bitcoin v0.1 released
Satoshi Nakamoto satoshi at vistomail.com
Fri Jan 16 11:03:14 EST 2009
…Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine.
When forum members worried that waiting for a block made bitcoin useless at a till, he did not point to a second network. He described a business: a payment processor, watching the network closely enough to accept a payment in seconds.
satoshi
Founder
Sr. Member
Activity: 364
Merit: 9152
Re: Bitcoin snack machine (fast transaction problem)
July 18, 2010, 01:59:15 AM
#21
I didn't say impermeable, I said good-enough. The loss in practice would be far lower than with credit cards.
…No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants. Think something like a credit card processor with a new job. They would have many well connected network nodes.
He was honest that very small payments were not practical yet in 2010, and said why they would be.
satoshi
Founder
Sr. Member
Activity: 364
Merit: 9152
Re: Flood attack 0.00000001 BC
August 05, 2010, 04:03:21 PM
#43
Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.
What this means for a design. Design for spending. A BSV product's ordinary case is a small payment for something specific, made without ceremony, and the interface should feel like paying, not like moving savings. See Charging per use and Amounts and units.
Not a cypherpunk project
Bitcoin is often described as a cypherpunk invention. It was not announced to the Cypherpunks mailing list. The paper went to the Cryptography mailing list, a moderated list for working cryptographers, on 31 October 2008. He did credit two earlier proposals as its ancestors, Wei Dai's b-money, first posted to the Cypherpunks list, and Nick Szabo's bit gold, but he took his own design to the cryptographers.
Bitcoin P2P e-cash paper
Satoshi Nakamoto satoshi at vistomail.com
Fri Oct 31 14:10:00 EDT 2008
I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.
The paper is available at: http://www.bitcoin.org/bitcoin.pdf …
Satoshi was not hostile to readers who cared about freedom; on the same list he called the design "very attractive to the libertarian viewpoint if we can explain it properly." What he would not do is sell it as a tool for hiding or as a way out from under the law. When a forum member drafted a Slashdot announcement for the July 2010 release, he cut both claims.
satoshi
Founder
Sr. Member
Activity: 364
Merit: 9152
Re: Slashdot Submission for 1.0
July 05, 2010, 09:31:14 PM
#6
…I really appreciate the effort, but there are a lot of problems.
We don't want to lead with "anonymous". (I've been meaning to edit the homepage)
"The developers expect that this will result in a stable-with-respect-to-energy currency outside the reach of any government." -- I am definitely not making an such taunt or assertion.
What this means for a design. Present a BSV product as a better way to pay, sign and keep records, for people who follow the law. Do not borrow the language of evasion; it is not what the system was designed for, and it is not what a mainstream user wants to be told.
Do
Describe a BSV payment as an ordinary purchase: what it buys, what it costs, who receives it.
Don't
Describe a BSV product as anonymous or beyond the reach of governments. Satoshi refused both claims, and every transaction is public.
The alert key
Satoshi did not leave the network without a way to act in an emergency. In August 2010 a bug let somebody create over 184 billion coins in a single transaction. A week later he announced an alert system, signed with a key that only he held.
satoshi
Founder
Sr. Member
Activity: 364
Merit: 9152
Development of alert system
August 22, 2010, 11:55:06 PM
#1
I've been working on writing the alert system. Alerts are broadcast through the network and apply to a range of version numbers. Alert messages are signed with a private key that only I have.
Nodes can do two things in response to an alert:
- Put a warning message on the status bar.
- Make the money handling methods of the json-rpc interface return an error.
In cases like the overflow bug or a fork where users may not be able to trust received payments, the alert should keep old versions mostly safe until they upgrade.
He was careful about its limits. "It can't do arbitrary actions remotely," he told the forum: it could warn, and pause a node's money handling until it was upgraded. He called that pause temporary and removed it in December 2010, but kept the alert key.
He had also thought about what makes theft pointless. Arguing about escrow two weeks earlier, he put it this way:
satoshi
Founder
Sr. Member
Activity: 364
Merit: 9152
Re: Escrow
August 11, 2010, 01:30:02 AM
#10
…Imagine someone stole something from you. You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too? If they give it back, you can re-activate it.
Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again.
What BSV does with it
BSV brought the alert system back, in SV Node 1.1.0, under published Network Access Rules (first version February 2024). The BSV Association runs it, and the rules expect every node to process validly signed alerts. Most alerts are notices. A directive can do more: tell nodes to freeze specified coins, reassign coins already frozen, block particular network addresses or invalidate blocks. The rules allow a directive only when a court decision enforceable in England and Wales or in Switzerland requires it, and the Association says it "does not act as a judge".
This is Digital Asset Recovery: stolen coins on BSV can be frozen, gold turned to lead, and then returned to their owner on a court's order. It goes further than anything Satoshi built, whose alerts could only warn and pause, and people disagree about whether it is what he intended. What it shares with his post is the aim: theft that does not pay.
What this means for a design. A BSV wallet can tell somebody who has been robbed that recovery through the courts exists, and where to start. It should not promise it: recovery needs a court order, takes time and money, and is realistic only for larger sums. See Common misconceptions.
Related
Written from: Bitcoin whitepaper, Cryptography mailing list, metzdowd.com archive, 2008 to 2009, bitcointalk.org, Satoshi's posts, 2010, P2P Foundation forum, 11 February 2009, Wayback Machine archive, Satoshi Nakamoto Institute archive, BSV Network Access Rules, version 1, 15 February 2024, BSV Alert System and Digital Asset Recovery documentation.
Checklist
The rules on this page, in a form you can work through.
2 rules