Quote from: richmke on February 09, 2014, 04:05:19 PM

Quote from: MoonShadow on February 09, 2014, 02:06:39 AM

You don't always need a missed block, but if you do, there are alternative paths to aquire missed data.

So, how do you know that you missed a needed block?

Double/tripple/etc broadcasting does not solve the problem. When is the block repeated? 8 hours later? What if you are off the grid for 24 hours, or just happen to be off when the rebroadcast occurs. The issue is not "unlikely" the issue is: the system is not 100% guaranteed.

Then you get the blocks from alternative channels. You likely should be doing some validation from alternative channels ANYWAYS otherwise you are susceptible to an isolation attack.

Imagine a potential user who DOES have internet but it may be slow, flaky, and high cost. It likely also has some low throughput limits each month. This would describe 3 to 4 billion people in the third world. Still if you want to take it closer to home, imagine someone in the US who who's only internet access is a 3G plan with a 10GB cap.

A data broadcast doesn't have to be 100%. If the broadcast gets the user 95% of the data then he cuts his bandwidth requirements over his conventional link by 95%. Sure 100% would be better but 95% might mean the difference between being able to run a node or not. As for downtime, if it becomes mission critical (and the savings from improved uptime warrant the cost) there are always options. Use two receivers on battery backups and compare the streams. That combine with FEC, and multiple channels, you could achieve > 99.999% receive rate. These concepts are already used in remote sat downlink applications.

My guess is you are thinking of a use case that it wasn't designed to be used. If a user has absolutely no other form of communication (no matter the cost or speed) then yes this is useless, but that wasn't the problem it was trying to solve.