I want BSVers, like this guy @beardpappa, to think about the extent to which a system like Bitcoin could have been built without proof-of-work mining, or without blocks being involved at all. Just a system with transaction messages and no blocks. (1/92)
https://x.com/beardpappa/status/1926572950204883126
@beardpappa We could still have a peer-to-peer (P2P) relay network and a globally distributed ledger database. Each node on the network could maintain its own copy of the ledger, and it could update its ledger as new transactions come in. (2/92)
@beardpappa The P2P relay network would be an attempted mechanism to ensure every node learns of every transaction, which "takes advantage of the nature of information being easy to spread but hard to stifle." (3/92)
@beardpappa That way, all nodes can agree on the state of the ledger, even though they're each acting independently. Because all nodes end up knowing all the transactions, they're all basically doing the same updates to their ledgers. Save for one problem, which I will get to later. (4/92)
@beardpappa We could still have a UTXO model, ECC signatures, and smart contracts with Bitcoin Script. In a system like this, these nodes would reject any transactions they see which have scripts that evaluate to false, or which have invalid ECC digital signatures provided. (5/92)
@beardpappa These scripts/sigs are rather trivial to check, and it's the whole point in having them: to verify that the inputs are authorized to be spent by the current owner. Nodes could also reject transactions that are above a certain data size limit that all nodes have agreed to. (6/92)
@beardpappa These are all rules that, in this system, are NOT being enforced by honest miners maintaining a majority of the global hashrate, because there are no miners in this system so far. There is no hashrate. There are no blocks. (7/92)
@beardpappa This could all work BUT for two problems with it. The first and less important one is how to initially distribute the coins in a decentralized and fair manner. You could probably come up with some kind of lottery, but the second problem is the big one... (8/92)
@beardpappa That is the double-spending problem. In the system described so far, one could create two VALID signed transactions that nonetheless spend the same input to two different outputs. The system sees both of these as a-priori VALID, but it needs a way to decide between them. (9/92)
@beardpappa This is not about rejecting straight-up INVALID transactions, which any fully-validating node can do easily and independently. It's about the globally-distributed system as a whole deciding between two EQUALLY VALID states that are mutually incompatible with each other. (10/92)
@beardpappa After all, we don't want it to be the case that anyone can just spend the same coin multiple times. That defeats the whole purpose of a system like this. So we require a way of deciding between two or more equally valid states. What mechanism could we come up with? (11/92)
@beardpappa The most natural one (that won't work) is a simple first-seen rule. When a node receives a valid transaction—with a valid digital signature, etc.—it updates its ledger. Naturally, if it sees another transaction later on that spends the same input, it's already too late. (12/92)
@beardpappa That node has already marked it as spent and it has already updated its ledger, so the second-seen and third-seen transactions don't do anything. They are just ignored. The reason this doesn't work on a global level should be obvious though. (13/92)
@beardpappa Even though you can consistently spread all the information to all of the nodes, you can't make sure that all nodes saw all the transactions *in the exact same order*. That's due to the nature of the speed of light, and propagation delays of messages across a P2P network. (14/92)
@beardpappa In this case, the distributed nodes across the globe—each all acting independently—would not be doing the same updates to their ledgers. Through no fault of their own they wouldn't be agreeing on which of the equally valid states are canon, and so it would all fall apart. (15/92)
@beardpappa This is where Satoshi's primary innovation comes in: proof-of-work (POW) and chains of blocks. A subset of nodes will bundle transactions into blocks and form chains of blocks. They perform computationally expensive POW on top of what it thinks is the current chain tip. (16/92)
@beardpappa For the same reason as before, not all nodes agree on what the current chain tip is, but this time they don't need to. With enough time, all nodes will end up converging on the same shared state in the deeper parts of the ledger (which cannot have double spends in it). (17/92)
@beardpappa Nodes can still be made to flipflop between equally valid but incompatible blocks being chosen as canonical, but it becomes exponentially harder and harder the more blocks are put on top of one. So this is only really a problem for the most recent transactions and blocks. (18/92)
@beardpappa As more time goes by, it get more and more likely that all of the nodes—which are all just doing their own thing independently—have ended up making the same updates to their ledgers (with respect to choosing between the equally valid but mutually incompatible states). (19/92)
@beardpappa It's important to remember a block itself can still be invalid though. E.g. if ANY of the transactions within it are invalid. Any chain of blocks is also invalid if it contains two or more equally valid but mutually incompatible states (e.g. a double spend situation). (20/92)
@beardpappa So any valid chain of blocks cannot contain double spends in it, but chains of blocks by themselves don't solve double spending without POW. That is because we still need a way to decide between two equally valid but incompatible chains. That's what proof-of-work gets us. (21/92)
@beardpappa All nodes are programmed to follow the ONE chain of VALID blocks that has the MOST CUMULATIVE POW it has seen so far. If a totally different chain of valid blocks comes in later with more POW attached, it will flip to that instead. This could reverse some transactions. (22/92)
@beardpappa The deeper parts of the chain are almost impossible to cause nodes to reverse though, because you'd have to redo all the POW that has been done on top of them to make an alternative valid chain with more POW. Typically it's only a few blocks at the tip in natural flux. (23/92)
@beardpappa Invalid blocks are always rejected regardless though—and by all nodes, not just mining ones. All nodes also independently know how much work is required of a given block. If a POW stamp is just invalid (not enough work) then the whole block is just considered invalid too. (24/92)
@beardpappa So chains of blocks with POW (i.e. blockchains) are mostly good for one thing: enabling nodes in our system to converge on the same single VALID state, chosen from two or more equally VALID but mutually incompatible states. This is our source of double-spend protection. (25/92)
@beardpappa We can already easily deal with any INVALID states by just ignoring them. We don't need mining for this and never did. Mining wasn't added into the mix to solve for it, and we don't *need* (or want) to give miners the power to just define what is valid for the rest of us. (26/92)
@beardpappa In a very elegant manner, the first problem with our system (the fair distribution of coins) can also be solved by piggy-backing it to the proof-of-work mining of blocks. You can initially distribute the coins fairly by rewarding them to miners who find valid POW blocks. (27/92)
@beardpappa This also provides an incentive to produce these valid blocks with POW stamps as well. If you produce a valid block, with a valid proof-of-work stamp on it, you are allowed to award yourself some bitcoins out of thin air (in a special 'coinbase' transaction of the block). (28/92)
@beardpappa However, you cannot award yourself ANY number of bitcoins. There is yet another validity rule where if you go above a certain amount, the block itself is just considered to be invalid. This allows us to limit inflation and make the supply of tokens a scarce commodity. (29/92)
@beardpappa The inflation rule is a validity rule like any other. It makes a block invalid if you violate it. Like providing an invalid POW stamp, or like a transaction with an invalid ECC digital signature. It's NOT any kind of valid state, so it's ignored by ALL the 'honest' nodes. (30/92)
@beardpappa Blockchains are good at helping nodes converge between the equally VALID but incompatible states (double spend scenarios). They're not supposed to let miners get away with INVALID states, like arbitrary inflation, so long as they have enough POW (hashpower) behind them. (31/92)
@beardpappa You can hash an invalid block 'till the cows come home. It doesn't matter. Other nodes drop it on the floor. Not *just* honest mining nodes (which you hope have more collective hashpower than the dishonest ones). That's not *supposed* to be the only defense against this. (32/92)
@beardpappa Adding POW mining to the system we were describing at the beginning (all of which could have been done before Bitcoin) doesn't suddenly shift what was once the responsibility of all nodes (i.e. checking for invalidity) to just a small subset we call "honest mining nodes". (33/92)
@beardpappa The whitepaper itself dealt with this misconception back in 2008. It states dishonest miners with more than 50% of the hashrate still cannot just create value out of thin air. Satoshi did NOT intend to shift all validity checking to just 'honest miners' maintaining >50%. (34/92)
@beardpappa Nor can they just take coins that never belonged to them (i.e. they cannot spend arbitrary coins without providing valid digital signatures). The only way this could be true is if POW isn't the be-all and end-all. There are validity rules that take precedence over POW. (35/92)
@beardpappa Indeed, the whitepaper goes on to say "nodes are not going to accept an invalid transaction as PAYMENT". Satoshi is talking of businesses running their own non-mining nodes here, to fully validate all of their incoming PAYMENTS. He uses the word PAYMENT here for a reason. (36/92)
@beardpappa Remember, earlier in the whitepaper when discussing SPV (which IS a kind of trust-the-miners model I will talk about later), Satoshi said BUSINESSES that receive frequent PAYMENTS will probably still want to run their own nodes for independent security, as opposed to SPV. (37/92)
@beardpappa So in these two instances, he's talking about the same thing. Businesses running a fully-validating node will NEVER accept invalid blocks, nor invalid transactions as PAYMENT, regardless of an attacker's POW. You can't trick fully-validating nodes to accept bogus coins. (38/92)
@beardpappa It makes sense just from the whitepaper that this is Satoshi's understanding and vision, and it makes sense conceptually when we think about the system from scratch, like I am doing in this thread. (39/92)
@beardpappa Indeed, this a good thing! It makes Bitcoin more secure from a whole class of attacks that would be possible otherwise! We should be glad that not everything is supposed to be down to miners. Personally, I don't think I would use Bitcoin if that were the case. (40/92)
@beardpappa A common refrain from BSVers is they will just call this concept a 'sybil attack'. Kurt likes to say that non-mining nodes aren't Byzantine generals; they're Byzantine soldiers. Satoshi said it's one-CPU-one-vote, not one-IP-one-vote! Etc. Etc. This is so misunderstood. (41/92)
@beardpappa These validity rules are not subject to a sybil attack because they're not even subject to a vote. Nodes just drop invalid data on the floor. That's not a voting process and it can't be 'sybil attacked'. (42/92)
@beardpappa If nodes reached out to other nodes to check what they're doing, and only dropped data if other nodes are also agreeing to drop the data, then yeah, okay: you could manipulate that by spinning up thousands of fake 'sybil nodes', each injecting their say into that process. (43/92)
@beardpappa That's not what we're talking about though. Each node operates INDEPENDENTLY and can check for itself. It can check if a digital signature is valid, for example. It doesn't need to ask the rest of the network what they think about whether the signature is valid. It sees. (44/92)
@beardpappa If it's not valid, it says 'no thx' to that transaction or block and moves on to the next thing. ALL nodes that check signatures do that, and all end up doing the same thing in unison. That's not voting and it cannot be manipulated by spinning up thousands of sybil nodes. (45/92)
@beardpappa Bitcoiners talk about ECONOMIC full nodes being the important metric, as opposed to just full nodes. Again, "BUSINESSES that receive frequent PAYMENTS will probably still want to run their own nodes" and they "are not going to accept an INVALID transaction as PAYMENT". (46/92)
@beardpappa If you want to buy a product or service from such a business, you'd better send it some valid coins then. If you don't it will just ignore you. You can't spin up fake nodes to confuse it. It doesn't care if 5000 other nodes said the coin is valid (purely internally, LOL). (47/92)
@beardpappa It's not a vote because full nodes don't talk to each other about what they're agreeing to, and it's certainly not one-IP-one-vote. Instead nodes just act INDEPENDENTLY. We just try to design the system so they all INDEPENDENTLY end up doing the exact same thing. (48/92)
@beardpappa All nodes can see for themselves if a block minted too many coins, then throw it on the floor. If a miner with a hashrate majority tried to print money for himself, he couldn't spend those coins at the business because they wouldn't even follow the miner's invalid blocks. (49/92)
@beardpappa The attacker would essentially be on their own hardforked-off blockchain that the Bitcoin economy is ignoring. It's the Bitcoin circular economy with nodes that end up mattering. Thousands of fake nodes that don't receive PAYMENTS anyway can't be used to manipulate this. (50/92)
@beardpappa In our prior system where there was no mining, we talked about how a simple 'first-seen rule' ultimately didn't help us solve the problem of choosing between two equally valid but incompatible states. Different nodes would naturally decide different states were canonical. (51/92)
@beardpappa We talked about how Satoshi introduced proof-of-work mining to solve this. THIS is where Satoshi said it's one-CPU-one-vote, not one-IP-one-vote. The logic is all about the system choosing between double-spends, not about deciding every validity rule in the entire system. (52/92)
@beardpappa We could imagine coming up with chains of blocks that don't use POW stamps, but where nodes on the network just signal their acceptance for one chain over another. Network majority wins. But this makes it trivial to just spin up thousands nodes so you have more votes. (53/92)
@beardpappa Using POW instead makes it costly to participate, which makes it sybil resistant. It's one-CPU-one-vote, not one-IP-one-vote, yes. But remember: it is choosing between two equally VALID but incompatible states where you need sybil resistance. NOT rejecting INVALID states. (54/92)
@beardpappa For INVALID states, all nodes see for themselves easily and INDEPENDENTLY without even conferring. And the circular economy matters. You want it to be the case that you can't easily spend fake coins into the Bitcoin economy, BECAUSE economic actors are checking for it. (55/92)
@beardpappa The lack of nodes needing to confer is where the fundamental misconception lies with BSVers, in my opinion. BSVers seem to think the 'majority decision making'—which the whitepaper talks about—is also used for deciding between invalid vs. valid states. (56/92)
@beardpappa I think BSVers with this misconception have the following false, but somewhat intuitive, understanding. "For all copies of the ledger, we need a way to decide what transactions are valid so that all ledgers across the globe are on the same page." That part is true enough. (57/92)
@beardpappa They continue with the false, but intuitive, logic: "So nodes somehow need to coordinate and confer with each other about tx validity, and share their votes, to enable them to come to the mutual understanding that is needed." This is the intuitive part that is NOT true. (58/92)
@beardpappa The reasoning continues: "But if the voting mechanism was just 'the majority opinion of all the nodes wins', you could cheaply spin up nodes to overwhelm the vote. And so POW mining was invented to solve this. We make it one-CPU-one-vote, instead of one-IP-one-vote." (59/92)
@beardpappa So the misconception: with regard to INVALID states, nodes never needed to confer to reach mutual understanding in the first place. They can decide INDEPENDENTLY, but all decide the same. It's important to understand the difference between this and 'conferring & voting'. (60/92)
@beardpappa As we already explained earlier, for any INVALID transaction you can easily program a rule that rejects that transaction. Each node that independently follows the same programming will reject the same transaction, and that's NOT due to nodes needing to confer in any way. (61/92)
@beardpappa For nodes deciding between two VALID but incompatible states (like double spends), it's not so easy. You cannot just program the first-seen rule for example. We saw that when we did that, each node still decides for itself, but each node ends up deciding different things. (62/92)
@beardpappa For this, there needed to be some conferring/voting mechanism, and one that was sybil resistant. That's where mining was needed. But it's ONLY for this, i.e. for deciding between double spendings. It's not for deciding whether something was straight-up a-priori INVALID. (63/92)
@beardpappa This leads me to SPV. The silver bullet in the BSVers arsenal, or so they seem to think. What does SPV do, fundamentally? It lets you prove that a transaction was included a block using a relatively compact proof, and without needing to download the entire blockchain. (64/92)
@beardpappa How this works is blocks have headers, and each header contains a root hash of a merkle tree comprising all of the transactions in the entire block. The root hash commits to all the transactions (proving that it knows they exist, essentially). The header also has the POW. (65/92)
@beardpappa The block headers are also what form the chains, i.e. by including the hash of its previous block. This allows us to actually think in terms of chains of block headers, AND decide which one chain of block headers has the most cumulative POW amongst all of the chains, etc. (66/92)
@beardpappa Block headers are relatively small, since they don't contain all the transactions in the block: just the fixed-size compact merkle root which commits to all the transactions. (67/92)
@beardpappa The cumulative size grows very manageably for all the block headers in the entire chain, so even small devices can feasibly just download all of the headers, follow the longest POW chain, and feasibly just re-sync to the latest chain tip when the device is next run, etc. (68/92)
@beardpappa Since block headers have the merkle root, this can be used to check whether a transaction was in a block without having the entire block. At least that is if you are provided with a merkle inclusion proof (or merkle path). A block header by itself doesn't tell you enough. (69/92)
@beardpappa A merkle inclusion proof is a small proof (per transaction) that you can check against the merkle root to prove that the root commits to the transaction. If it does, then the block header commits to that transaction. It is saying it knows of the transaction. (70/92)
@beardpappa Crucially this can't prove the block itself is valid, though. If any transaction in the block is invalid, the entire block is supposed to be thrown out (ideally). If any block earlier in the entire chain is invalid, the whole chain is supposed to be thrown out (ideally). (71/92)
@beardpappa If you ONLY see the block headers, you can't tell for yourself if the blocks in the longest chain are valid. You can reason that "the majority of the hashrate probably wouldn't have mined them if they were invalid", but you can't check and ENSURE that this is the case. (72/92)
@beardpappa You can check the proof-of-work of the block headers at least, but that's all. So if you receive a small merkle proof that an incoming payment was included in a block, and that block is in the chain with the most proof-of-work, that's still useful and better than nothing. (73/92)
@beardpappa If you trust in the validity of that chain—reasoning that miners with the majority hashrate probably wouldn't be producing invalid blocks—then you can use this for some DOUBLE-SPEND PROTECTION (by waiting for further block header confirmations to be put on top of it). (74/92)
@beardpappa But be aware that you've essentially given up the validation-checking responsibility and outsourced that to miners, trusting that the majority of the hashrate stays 100% honest. SPV will just follow whichever chain has the most POW, regardless of its underlying validity. (75/92)
@beardpappa It's not a full substitute for ensuring the entire chain is valid. Satoshi said SPV lets users just be users. I don't think he meant by this what BSVers allege, where 'users' is everyone: even the most highly profitable, motivated, professional merchant businesses. (76/92)
@beardpappa I don't think Satoshi meant that ALL validation globally should be outsourced to the honest miners, because it's supposed to be too costly, and too specialist of a field, for even the most profitable, motivated, professional merchants to handle validation for themselves. (77/92)
@beardpappa I think 'letting users be users' means your average Joe Bloggs with his phone can still participate in a trust minimized and non-custodial manner, not necessarily that even Walmart's point-of-sale system in a hyperbitcoinized economy should not even be fully validating. (78/92)
@beardpappa Again, even the whitepaper itself doesn't say that. It says "BUSINESSES that receive frequent PAYMENTS will probably still want to run their own nodes" as opposed to SPV. And I don't think Satoshi meant this is temporary, i.e. just for the beginning stages of the network. (79/92)
@beardpappa If a lot of the economy fully validates then it can also help keep the majority of the hashrate honest, because otherwise they're just forking themselves away with respect to that economy. They want to be able to SPEND their bogus inflated coins in the economy, after all. (80/92)
@beardpappa Consider that if miners ultimately decide between themselves how much bitcoins they print in each block, it is fully in their economic self-interest to team up and to change that limit. To inflate the token, siphoning away all purchasing power in the system to themselves. (81/92)
@beardpappa Purchasing power implies spending. If the Bitcoin circular economy broadly validates, they can't hawk their bogus inflated coins off into the economy, so they can't benefit. There is no purchasing power if they can't unload. It's essentially a hardfork to a worthless alt. (82/92)
@beardpappa So there's also a herd-immunity-like property here, where even the Joe Bloggs SPV user benefits. The Bloggs user is outsourcing validation, yet miners are not just printing themselves whatever amounts they want (which would otherwise be in their economic self-interest). (83/92)
@beardpappa The reason for this is because the miners can't easily benefit from producing invalid blocks if the broader Bitcoin economy is still broadly validating, even if the Joe Bloggs user isn't. So there's a kind of herd immunity that Joe Bloggs is still benefiting from. (84/92)
@beardpappa So SPV can have its place, but that doesn't imply we should throw caution to the wind. If EVERY Bitcoin participant uses SPV, out of some misguided loyalty to Satoshi's misinterpreted words, we WILL lose a valuable property. (85/92)
@beardpappa If EVERYBODY just uses SPV, it becomes true that attackers with a majority of the hashrate can just print themselves coins, contra the whitepaper. 'Nodes' (in this case SPV ones) WOULD gladly accept an invalid transaction as PAYMENT, contrary to what the whitepaper says! (86/92)
@beardpappa Indeed, this happened in BSV with so-called 'confiscation transactions' (DAR) being hardforked in. Except for a few paid higher-ups, nobody in BSV's economy fully validates (and it is heavily discouraged), so BSVers cannot meaningfully oppose DAR. (87/92)
@beardpappa Even the BSV software license forbids any defiance. See how it talks about ALERT MESSAGES and lawsuits being mandated by the license? The license that is built upon Craig fraudulently pretending to be Satoshi, and licensing 'his' ownership rights to the BSV Assocation. (88/92)
@beardpappa So now BSV has added central administrators into their system, who have admin keys to all funds. This NEW hardfork consensus rule, which was forced in, allows a small group of worshippers picked by Calvin and Craig Wright (fraudster) to ignore digital signatures at will. (89/92)
@beardpappa So that's clearly not the vision Satoshi had in mind for the system as a whole. Users can just be users, but the whitepaper says "businesses will probably still want to run their own nodes" at least, and that SPV alone is more vulnerable to the network being overpowered. (90/92)
@beardpappa A healthy mix of SPV and fully-validating nodes is totally OK, because of the herd-immunity effect from the broader Bitcoin circular ECONOMY being fully validating. It's ECONOMICALLY-relevant nodes that I'm talking about, so we're not talking about any sybil attacks here. (91/92)
@beardpappa SPV having a place and value doesn't imply that everybody moving to full SPV mode maintains the exact same game-theoretic security. Where literally none of the economy validates and we all just place trust in those like Calvin & Craig (LOL) to not inflate or steal coins. (92/92)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
