đź“™
[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
  • 44
  • On the Segmentation or “InternetKill Switch”

44. On The Segmentation or "Internet Kill Switch"

44

On the Segmentation or “InternetKill Switch”

TWO THREADS involved the possibility of segmentation or a split of the network.

Re: Anonymity!

Satoshi Nakamoto June 08, 2010, 07:12:00 PM

It’s hard to imagine the Internet getting segmented airtight. It would have to be a country deliberately and totally cutting itself off from the rest of the world.

Any node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone. It would only take one node to do it. Anyone who wants to keep doing business would be motivated.

If the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork arereleased into the transaction pool again and are eligible to get into future blocks. Their number of confirmations would start over.

If anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to0/unconfirmed and stay that way.

It wouldn’t be easy to take advantage of the segmentation to double-spend. If it’s impossible to communicate from one side to the other, how are you going to put a spend on each side? If there is a way, then probably someone else is also using it to flow the block chain over.

You would usually know whether you’re in the smallersegment. For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment. If you’re in the smaller segment, you should assume nothing is confirmed.

This covers specifically the case of a network split.

What happens when network is split for prolonged time and reconnected?

Posted by em3rgentOrdr on August 01, 2010, 11:07:24 AM

Suppose that BitCoins are being widely used all across theglobe. Suppose that all internet connections between two countries are blocked (eg China and US go to war) and people still engage in transactions inside each network. Now all transactions within each network are broadcasted to all nodes inside its network, but not to the other network. Within each network, the longest chain in each would be considered valid, and the BitCoin economy would continue to exist inside each network.

Now after several years existing independently, what happens when the two networks are reconnected?

Re: What happens when network is split for prolonged time and reconnected?

Posted by kiba on August 02, 2010, 03:19:08 AM

Maybe they won’t be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).

Re: What happens when network is split for prolonged time and reconnected?

Posted by throughput on August 02, 2010, 06:07:08 PM

I, as a merchant, will only care about whether my network is a majority network, so after a reconnect my transactions will be accepted. So it will be enough for me to be able to monitorthe current number of distinct nodes. Put that into a graph and stop processing transactions if that number suddenly halves.It may be a service on a web-server running a Bitcoin node.

But is there a way to monitor that number at all? If not, it would be wise to add some feature to the standard, which will allow to determine in real time what is the number of distinct nodes running.

Re: What happens when network is split for prolonged time and reconnected?

Posted by creighto on August 03, 2010, 08:01:22 PM

Quote from: throughput on August 03, 2010, 01:33:08 PM

Yes... But what you describe is only possible after someone have noticed and prooved the network split is happening.Do you propose any method to detect the beginning of the network split?

I started another thread along this line elsewhere, but for an individual vendor, a simple watchdog daemon that tracks the average time between blocks since the last official change in difficulty and alerts the vendor if a single block takes more than twice as long as the average, perhaps suspending the acceptance of new coins until the vendor checks to see what is happening. Each block in a row that takes longer than the average increases confidence against a false positive. Soif one block takes twice as long as average, followed by a series of blocks that take 75% longer than average, then you can be fairly certain that you are no longer on the majority network.

Re: What happens when network is split for prolonged time and reconnected?

Posted by satoshi on August 03, 2010, 10:45:07 PM

creighto: I agree with that idea. After a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance. It could tell if it’s not hearing the hum of the world anymore.

Quote from: knightmb on August 03, 2010, 07:02:13 PM

Quote from: gavinandresen on August 03, 2010, 06:38:44 PM

Or if the split lasted long enough (more than 100 blocks),transactions that involve generated coins on the shorter chain would be invalid at the merge.

Interesting info, so other than some double-spending issues, as long as the block chain isn’t separated for more than 100 or so blocks (or 16+ hours),

In practice, splits are likely to be very asymmetrical. It would be hard to split the world down the middle. More likely it would be a single country vs the rest of the world, lets say a 1:10 split. In that case, it would take the minority fork 10 times as long to generate100 blocks, so about 7 days. Also it would be super easy for the client to realize it’s hearing way too few blocks and something must be wrong.

Quote from: knightmb on August 03, 2010, 07:02:13 PM

If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?

There’s no time limit. Assuming you weren’t spending coins generated in the minority fork, or spending someone’s doublespends you received, your transactions can get into the other chainat any time later.

Previous43. Bitcoin 0.3 Released!Next45. On Cornering the Market

Last updated 12 months ago