đź“™
[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
  • 40
  • On the Possibility of a Cryptographic Weakness

40. On the Possibility of a Cryptographic Weakness

40

On the Possibility of a Cryptographic Weakness

SEVERAL THREADS covered different issues to which Satoshi suggested the same solution. Two of the threads below concern SHA-256, which is the cryptographic hash function used to create the “message digest” of the blocks used as the public ledger, each containing a set of bitcoin transactions. SHA-256 is used by the banking industry and other financial institutions. Were any weaknesses to one day be discovered in this encryption method, it would affect the whole financial industry, which would then be forced to change over to a new method. Satoshi suggests the same policy for Bitcoin.

The second thread was in regard to the discovery of a major cryptographic weakness. At first, Satoshi refers to his earlier post on SHA-256 Collisions, but user llama specifies the case where a major weakness is discovered in the elliptic curve cryptographic code that is used for the Bitcoin private key.

Re: Dealing with SHA-256 Collisions

Satoshi Nakamoto June 14, 2010, 08:39:50 AM

Quote from: lachesis on June 14, 2010, 01:01:11 AM

A mathematician friend of mine pointed out that there arevery few if any hash protocols that have survived for 10 years or more. What would Bitcoin’s solution be if SHA256 were to be cracked tomorrow?

SHA-256 is very strong. It’s not like the incremental step from MD5 to SHA1. It can last several decades unless there’s some massive breakthrough attack.

If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was beforethe trouble started, lock that in and continue from there with a new hash function.

If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can’t be used.

Re: Major Meltdown

Satoshi Nakamoto July 10, 2010, 04:26:01 PM

Quote from: llama on July 01, 2010, 10:21:47 PM

Satoshi, That would indeed be a solution if SHA was broken (certainly the more likely meltdown), because we could still recognize valid money owners by their signature (their private key would still be secure).

However, if something happened and the signatures were compromised (perhaps integer factorization is solved, quantum computers?), then even agreeing upon the last valid block would be worthless.

True, if it happened suddenly. If it happens gradually, we can still transition to something stronger. When you run the upgraded software for the first time, it would re-sign all your money withthe new stronger signature algorithm. (by creating a transaction sending the money to yourself with the stronger sig)

Re: Hash() function not secure

Satoshi Nakamoto July 16, 2010, 04:13:53 PM

SHA256 is not like the step from 128 bit to 160 bit.

To use an analogy, it’s more like the step from 32-bit to 64-bit address space. We quickly ran out of address space with 16-bit computers, we ran out of address space with 32-bit computers at4GB, that doesn’t mean we’re going to run out again with 64-bit anytime soon.

SHA256 is not going to be broken by Moore’s law computational improvements in our lifetimes. If it’s going to get broken, it’ll be by some breakthrough cracking method. An attack that could so thoroughly vanquish SHA256 to bring it within computationally tractable range has a good chance of clobbering SHA512 too.

If we see a weakness in SHA256 coming gradually, we can transition to a new hash function after a certain block number. Everyone would have to upgrade their software by that block number. The new software would keep a new hash of all the old blocks to make sure they’re not replaced with another block with the same old hash.

Previous39. On Money Transfer RegulationsNext41. On a Variety of Transaction Types

Last updated 12 months ago