đź“™
[EN] The Book of Satoshi by Phil Champagne (beta)
source
  • The Book of Satoshi : The Collected Writings of Bitcoin Creator Satoshi Nakamoto by Phil Champagne
  • About the Cover Picture
  • Acknowledgements
  • Who This Book is Intended For
  • Foreword
  • 1. Introduction
  • 2. How and Why Bitcoin Works
  • 3. The First Post on Crypto Mailing List
  • 4. Scalability Concerns
  • 5. The 51% Attack
  • 6. About Centrally Controlled Networks Versus Peer-to-Peer Networks
  • 7. Satoshi on the Initial Inflation Rate of 35%
  • 8. About Transactions
  • 9. On the Orphan Blocks
  • 10. About Synchronization of Transactions
  • 11. Satoshi Discusses Transaction Fees
  • 12. On Confirmation and Block Time
  • 13. The Byzantine General's Problem
  • 14. On Block Time, an Automated Test, and the Libertarian Viewpoint
  • 15. More on Double Spend, Proof-of-Work and Transaction Fees
  • 16. On Elliptic Curve Cryptography, Denial of Service Attacks, and Confirmation
  • 17. More in the Transaction Pool, Networking Broadcast, and Coding Details
  • 18. First Release of Bitcoin
  • 19. On the Purpose For Which Bitcoin Could Be Used First
  • 20. "Proof-of-Work" Tokens and Spammers
  • 21. Bitcoin Announced on P2P Foundation
  • 22. On Decentralization as Key to Success
  • 23. On the Subject of Money Supply
  • 24. Release of Bitcoin Vo.1.3
  • 25. On Timestamping Documents
  • 26. Bitcointalk Forum Welcome Message
  • 27. On Bitcoin Maturation
  • 28. How Anonymous Are Bitcoins?
  • 29. A Few Questions Answered By Satoshi
  • 30. On "Natural Deflation"
  • 31. Bitcoin Version 0.2 is Here!
  • 32. Recommendation on Ways to Do a Payment for An Order
  • 33. On the Proof-of-Work Difficulty
  • 34. On the Bitcoin Limit and Profitability of Nodes
  • 35. On the Possibility of Bitcoin Address Collisions
  • 36. QR Code
  • 37. Bitcoin Icon/Logo
  • 38. GPL License Versus MIT License
  • 39. On Money Transfer Regulations
  • 40. On the Possibility of a Cryptographic Weakness
  • 41. On a Variety of Transaction Types
  • 42. First Bitcoin Faucet
  • 43. Bitcoin 0.3 Released!
  • 44. On The Segmentation or "Internet Kill Switch"
  • 45. On Cornering the Market
  • 46. On Scalability and Lightweight Clients
  • 47. On Fast Transaction Problems
  • 48. Wikipedia Article Entry on Bitcoin
  • 49. On the Possibility of Stealing Coins
  • 50. Major Flaw Discovered
  • 51. On Flood Attack Prevention
  • 52. Drainage of Bitcoin Faucet
  • 53. Transaction to IP Address Rather Than Bitcoin Address
  • 54. On Escrow and Multi-Signature Transactions
  • 55. On Bitcoin Mining as a Waste of Resources
  • 56. On an Alternate Type of Block Chain with Just Hash Records
  • 57. On the Higher Cost of Mining
  • 58. On the Development of an Alert System
  • 59. On the Definition of Money and Bitcoin
  • 60. On the Requirement of a Transaction Fee
  • 61. On Sites with CAPTCHA and Paypal Requirements
  • 62. On Short Messages in the Block Chain
  • 63. On Handling a Transaction Spam Flood Attack
  • 64. On Pool Mining Technicalities
  • 65. On WikiLeaks Using Bitcoin
  • 66. On a Distributed Domain Name Server
  • 67. On a PC World Article on Bitcoin and WikiLeaks Kicking the Hornet's Nest
  • 68. Satoshi's Last Forum Post: Release of Bitcoin 0.3-19
  • 69. Emails to Dustin Trammell
  • 70. Last Private Correspondence
  • 71. Bitcoin and Me (Hal Finney)
  • 72. Conclusion
  • Bitcoin: A Peer-to-Peer Electronic Cash System
  • Terms & Definitions
  • Index
Powered by GitBook
On this page
  • 13
  • The Byzantine General’s Problem

13. The Byzantine General's Problem

Previous12. On Confirmation and Block TimeNext14. On Block Time, an Automated Test, and the Libertarian Viewpoint

Last updated 12 months ago

13

The Byzantine General’s Problem

IN WHAT IS POSSIBLY the most interesting post made by Satoshi, he explains how the block chain solves a problem in computer science known as the “Byzantine fault tolerance”, a more generalized version of the “Two Generals’ Problem”. In this problem, two (or more) persons need to share information in an unreliable communication environment, where messages sent can be lost or tampered with. The statement of the problem first appeared in the 1970s in network computing literature, and at that time the problem was considered unsolvable. In this post, Satoshi claims that Bitcoin solves it.

To illustrate the problem, imagine that two generals are required to attack a city at the same time. If either one attacks and the other does not, the forces of the attacking general will be annihilated by the city’s defenses. Communication between the generals is unreliable; the courier sending the message regarding when to attack must go through the city and so could be intercepted. The first general can, by 9 am, dispatch the messenger with the message communicating that the attack will commence on that same day. However, once dispatched, the first general will have no idea as to whether or not the messenger got through. This uncertainty may lead the first general to hesitate to attack since he might be attacking alone if the second general never received his message.

Knowing all this, the second general may send a confirmation back to the first to indicate that he received the message to attack. But that message, too, could be intercepted, leading the second general to hesitate as well. The first general could be sending a confirmation of the confirmation, but that too could have been intercepted. Hence, again, the first general could hesitate unless he gets back a confirmation of this confirmation of the first confirmation. This process could be carried out ad infinitum with no way for either general to know whether messages were dispatched or whether they were but were intercepted by the enemy.

To learn more, read the section “Illustrating the problem” in the following Wikipedia article:

See also this article on the Byzantine fault tolerance:

Re: Bitcoin P2P e-cash paper

Satoshi Nakamoto Thu, 13 Nov 2008 19:34:250800

James A. Donald wrote:

It is not sufficient that everyone knows X. We also need everyone to know that everyone knows X, and that everyone knows that everyone knows that everyone knows X which, as in the Byzantine Generals problem, is the classic hard problem of distributed data processing.

The proof-of-work chain is a solution to the Byzantine Generals’ Problem. I’ll try to rephrase it in that context.

A number of Byzantine Generals each have a computer and want to attack the King’s wi-fi by brute forcing the password, which they’ve learned is a certain number of characters in length. Once they stimulate the network to generate a packet, they must crack the password within a limited time to break in and erase the logs, otherwise they will be discovered and get in trouble. They only have enough CPU power to crack it fast enough if a majority of them attack at the same time.

They don’t particularly care when the attack will be, just that they all agree. It has been decided that anyone who feels likeit will announce a time, and whatever time is heard first will be the official attack time. The problem is that the network is not instantaneous, and if two generals announce different attack times at close to the same time, some may hear one first and others hear the other first.

They use a proof-of-work chain to solve the problem. Once each general receives whatever attack time he hears first, he sets his computer to solve an extremely difficult proof-of-work problem that includes the attack time in its hash. The proof-of-work isso difficult, it’s expected to take 10 minutes of them all working at once before one of them finds a solution. Once one of the generals finds a proof-of-work, he broadcasts it to the network, and everyone changes their current proof-of-work computation to include that proof-of-work in the hash they’re working on. Ifanyone was working on a different attack time, they switch to thisone, because its proof-of-work chain is now longer.

After two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU power per hour was expended on it and see that it must have requiredthe majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proofof-work is proof that they worked on it. If the CPU power exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time.

The proof-of-work chain is how all the synchronisation, distributed database and global view problems you’ve asked about are solved.

The Cryptography Mailing List

http://en.wikipedia.org/wiki/Two_Generals%27_Problem
http://en.wikipedia.org/wiki/Byzantine_fault_tolerance