Quote from: JayJuanGee on June 28, 2020, 10:47:08 PM

There could be a better thread for my question, yet I would like to raise a question that came into my head while I was reading OP, which I understood attempted to suggest both an ideological underpinning to bitcoin that was achieved through technological progressions and/or improvements to what ended up being bitcoin.

So, when you described b-money in OP, you suggested that it seemed to have a lot of bitcoin's attributes but it was both subject to sybil attacks, but also suffered from the problem of NOT being coded or implemented. Bit Gold was also subject to sybil attacks, and I am suspecting that the network of proof of work was not decentralized enough in bitgold so it ended up having potential hashpower manipulation vulnerabilities?

A question came in my thinking regarding what aspects of bitcoin exactly helped bitcoin to overcome the deficiencies of b money and Bit Gold? [...]

I am coming back on this question, and this time I'm going to explain it also using Satoshi's own words, as maybe my own explanation was not clear enough.

In an email from November 3rd, 2008, he explains the flaws of HashCash:

Quote

As long as honest nodes control the most CPU power on the network, they can generate the longest chain and outpace any attackers.

But they don't. Bad guys routinely control zombie farms of 100,000 machines or more. People I know who run a blacklist of spam sending zombies tell me they often see a million new zombies a day.

This is the same reason that hashcash can't work on today's Internet -- the good guys have vastly less computational firepower than the bad guys.

The following is a list of his statements for solving the double spending problem.

For example, in a post on P2P Foundation website, he wrote the following:

Quote

Any owner could try to re-spend an already spent coin by signing it again to another owner. The usual solution is for a trusted company with a central database to check for double-spending, but that just gets back to the trust model. In its central position, the company can override the users, and the fees needed to support the company make micropayments impractical.

Bitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle. For details on how it works, see the design paper at http://www.bitcoin.org/bitcoin.pdf

The result is a distributed system with no single point of failure. Users hold the crypto keys to their own money and transact directly with each other, with the help of the P2P network to check for double-spending.

More details about the solution for the double spending can be found in the white paper and in the emails he sent on the cryptography mailing list. As an issue of note, it is very interesting that he referred to the author (himself) using the term "we", which suggest either that he used the royal plural or that he referred to a team working on Bitcoin. I didn't notice that before. I knew that it is debated if Satoshi was a person or a group of people, but seeing how he used the term "we" in the white paper suggests there was more than one person.

White paper quote:

Quote

We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU proof-of-worker. As long as a majority of CPU proof-of-worker is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. [...]

In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU proof-of-worker than any cooperating group of attacker nodes. [...]

The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank. [...]

We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

Email from November 2nd, 2008:

Quote

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.

Email from November 8th, 2008:

Quote

The attacker isn't adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he's doing that. He's rewriting history. Once his branch is longer, it becomes the new valid one.

Email from November 10th, 2008:

Quote

When there are multiple double-spent versions of the same transaction, one and only one will become valid.

Email from November 10th, 2008:

Quote

The guy who received the double-spend that became invalid never thought he had it in the first place. His software would have shown the transaction go from "unconfirmed" to "invalid". If necessary, the UI can be made to hide transactions until they're sufficiently deep in the block chain.

Email from November 11th, 2008:

Quote

The receiver of a payment must wait an hour or so before believing that it's valid. The network will resolve any possible double-spend races by then.

Email from November 14th, 2008:

Quote

There's no need for reporting of "proof of double spending" like that. If the same chain contains both spends, then the block is invalid and rejected. Same if a block didn't have enough proof-of-work. That block is invalid and rejected. There's no need to circulate a report about it. Every node could see that and reject it before relaying it.

Email from November 14th, 2008:

Quote

We're not "on the lookout" for double spends to sound the alarm and catch the cheater. We merely adjudicate which one of the spends is valid. Receivers of transactions must wait a few blocks to make sure that resolution has had time to complete. Would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that within a few blocks, one of the spends becomes valid and the others become invalid. Any later double-spends are immediately rejected once there's already a spend in the main chain.

Email from November 15th, 2008:

Quote

The race is to spread your transaction on the network first. Think 6 degrees of freedom -- it spreads exponentially. It would only take something like 2 minutes for a transaction to spread widely enough that a competitor starting late would have little chance of grabbing very many nodes before the first one is overtaking the whole network. During those 2 minutes, the merchant's nodes can be watching for a double-spent transaction. The double-spender would not be able to blast his alternate transaction out to the world without the merchant getting it, so he has to wait before starting. If the real transaction reaches 90% and the double-spent tx reaches 10%, the double-spender only gets a 10% chance of not paying, and 90% chance his money gets spent. For almost any type of goods, that's not going to be worth it for the scammer.

Please let me know if my previous explanation plus these quotes explained properly the question.