But with a bank, they would simply confirm the first cheque cashed (Dave), when there was money enough, and deny the second (Betty), when the account was too low. Right? There is no real evaluation of either cheque's validity, just first come first served, and maybe some consequence for the writer of the cheques.
No. If they didn't verify the validity of the cheque, then anyone could just walk in with a plain piece of paper, cut it into the shape of a cheque, draw a sloppy picture of a cheque drawn against someone else's account, and then cash it. The bank ABSOLUTELY makes sure that the cheque is real and valid before they even bother looking to see if there's enough money registered to the account that it is drawn against.
Sorry for being dense (it is an old crse of mine...), but I still fail to see how the mining truly adds to the validity/trust in the included transactions. I think I am missing some clever detail. To me, speedy confirmation and thus spreading information on a transaction makes the difference, just as it would with the two cheques example.
Speedy confirmation by whom? Who gets to be the "official decider" of which transaction is the "first" one? If you first receive a transaction saying that franky1 paid you, and I first receive a transaction saying that franky1 paid me, then who gets to decide which was actually first? If John first sees the transaction from franky1 to you, and Bobby first sees the transaction from franky1 to me, we now have multiple people that all believe that you were paid, and multiple people that all believe that I was paid.
How do we designate an "official decider" that gets to choose which transaction actually IS first?
This actually puts a bit more of a point on it, but still leaves some.... confusion. Demanding PoW means a 'bank' cannot simply pack doubles by the thousands. Which ever 'cheque' gets cashed into a block supported by PoW gets confirmed. And if later blocks have the other cheque, they get discarded as doubles. I kiiinda get that. But how is this an improvement over the initial spread of the transaction through the network? First come is still first served, it seems. The blocks just cements one batch of transactions over another. The network should have already weeded out doubles by discarding the later transaction.
How does "the network" decide? "The network" isn't a single entity. It's millions of individual nodes/peers that each may have received a different transaction first. If a node/peer on the network receives 2 competing transactions, and it just chooses whichever it receives first, how can it know that ALL other nodes on the network ALSO received that same transaction first? They could ask a few of the nodes/peers that they happen to be connected to, but how do they know that there aren't some other nodes that they aren't connected to which saw the other transaction first?
I suppose we could require that every node ask every other node about every transaction, but how would a node know when it has talked to ALL other nodes? What about nodes that are offline? And what's to keep an attacker from just firing up a few thousand (or million) super cheap, bare minimum, virtual servers that all always switch which transaction they tell other nodes they saw first?
"First into a block = first served" fixes this problem. When you get a block that has met the minimum proof of work requirements you just assume that everyone else also got that same block. You continue to assume that so long as you never hear of a different chain of blocks with a higher total proof of work. If you do receive a chain of blocks with a higher total proof of work, then you abandon the chain you currently have, and accept the new chain as the "real" chain. The only way an attacker can keep you on a false chain is to either:
1. Completely isolate you from EVERY other node on the network. Even then, he'd need to have enough hashing power to continue to feed you valid blocks, otherwise you'd quickly become suspicious of the fact that you haven't received a block in a VERY long time.
or
2. Maintain more hashing power than the entire rest of the world combined so that he can continue to outpace the rate at which they create blocks.
Since the quantities of hash power needed to pull off either of these attacks is expensive, the attacker has nothing to gain unless your transaction is more valuable that all that hash power. Furthermore, since that hash power could have been used to gain block rewards through honest participation (mining), the attacker risks all that potential revenue by spending time on attempting any type of attack. These financial incentives make it too expensive to even try attacking for small amounts. For higher value transactions, the recipient of the payment can simply increase the number of "confirmations" (blocks) that they require before they'll release whatever is being exchanged. This increases the amount of time that the attacker must keep up the attack, which significantly increases his costs AND prolongs the amount of time that he won't receive the mining rewards he could have gotten instead (increasing the attacker's risk and losses)
I know the basics, the problem is that I am not quite getting how this exact method adds significantly to the validity. The overall theory makes perfect sense and is, in a way, beautiful, but there are just some aspects that I feel a need to really pick apart to get a firm grasp on. This is one such aspect.
I'm really surprised that the 3B1B video didn't get you there. He explains each step of the solution 1-by-1 and at each step he shows exactly why that step is needed AND how it overcomes the problem that it is intended to solve.
