|
Title: network hardening or other ways to prevent forks in a war scenario Post by: Luno on March 18, 2014, 12:18:40 PM What ideas could be relevant?
Trusted nodes in bunkers? An implementation in the client that warns that no "heart beat" has been heard from one of the trusted nodes in 30 minutes, so transactions are discouraged because of a possible fork? Is obfuscation maybe a better way? A minimum client that can be hid headless only to support the network or maybe a virus that installs as many wallets as possible? Maybe this will sort itself out as the stakes get higher, But will bitcoin work between fighting nations, tht's the ultimate network of distrust? Title: Re: network hardening or other ways to prevent forks in a war scenario Post by: aceat64 on March 18, 2014, 10:55:11 PM Bitcoin is a P2P network, so long as there is at least one link between the two groups, even an indirect one, a fork will not occur.
Title: Re: network hardening or other ways to prevent forks in a war scenario Post by: Luno on March 19, 2014, 04:32:26 AM That's the point, Syria had 4 active wallets before things got to bad. Libya two wallets. In that case where one area is suffering for intermittent, low bandwidth, internet, online wallets, TOR, vpn might be better . which is being implemented in BitcoinJ client.
But in a conflict that span multiple countries, you can have rationed power to a few hours each day and a few flaky ISP's and a single state controlled pipeline out of the country. How do you keep in sync then? Some are suggesting a mesh VHF network, but bandwidth on these frequencies, is too low. Title: Re: network hardening or other ways to prevent forks in a war scenario Post by: kjj on March 19, 2014, 05:03:31 AM Some are suggesting a mesh VHF network, but bandwidth on these frequencies, is too low. I think you are either overestimating how much data bitcoin moves, or underestimating how much data packet radio can move. Title: Re: network hardening or other ways to prevent forks in a war scenario Post by: Luno on March 27, 2014, 03:38:09 PM Some are suggesting a mesh VHF network, but bandwidth on these frequencies, is too low. I think you are either overestimating how much data bitcoin moves, or underestimating how much data packet radio can move. I was thinking about initial download of the block chain. Maybe bitcoin, if governments in the future are invested, actually helps in keeping the Internet up as a global network? The would be a good thing in wartime. Title: Re: network hardening or other ways to prevent forks in a war scenario Post by: piotr_n on March 27, 2014, 04:18:26 PM Some are suggesting a mesh VHF network, but bandwidth on these frequencies, is too low. I think you are either overestimating how much data bitcoin moves, or underestimating how much data packet radio can move. Just announcing the block headers should be enough to inform the entire world where is the head of the chain. That you don't have the transactions - that would be a different issue. I was thinking about initial download of the block chain. That's eventually going to become a problem, even with the internet working just fine, outside a war scenario.Some way for compressing the chain (making possible to download just its current state) - this will become a necessity, sooner or later. Title: Re: network hardening or other ways to prevent forks in a war scenario Post by: 2112 on March 27, 2014, 07:46:33 PM moonbounce (a.k.a. EME)
We've discussed this before: "How do we deal with an internet blackout?" https://bitcointalk.org/index.php?topic=128702.0 The salient observation is: although the present Bitcoin network is p2p it actually emulates a broadcast medium. Title: Re: network hardening or other ways to prevent forks in a war scenario Post by: Luno on March 27, 2014, 08:55:04 PM moonbounce (a.k.a. EME) We've discussed this before: "How do we deal with an internet blackout?" https://bitcointalk.org/index.php?topic=128702.0 The salient observation is: although the present Bitcoin network is p2p it actually emulates a broadcast medium. Thank you. There is already an extensive thread on this. |