With the 'naked block' protocol being considered, you don't even need this much.  Currently, all full clients require all the data in order to completely check every block for validity, but a "light client" doesn't require this kind of certainty.  Since it's unlikely that clients receiving updates via this method would be mining, complete blocks are not necessary.  What is necessary is a complete block header chain, which only weighs in at 4 mb per year; and the merkle tree for any blocks that contain transactions that concern the client itself.  While it would be ideal to broadcast those merkle trees with the block header (i.e. the naked block, all except the actual transactions) it would be profoundly silly to broadcast every single transaction complete.

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.

Unfortunately, I can see some very real technical and legal issues with trying to do this as described.

First off, Wifi is possible in only two bands.  Since the higher N band is very new, and many smartphones still don't support it, I'm going to assume that the older B,G band is what they plan to use.  But there was a technical reason that this band was chosen at the time of development; namely that the B,G band was license free worldwide.  But why was that, since such license free technologies didn't really exist before Wifi itself?  Because the B,G band is the resonate frequency of hydrogen.  Thus, energy transmitted in this band is heavily attenuated by any water or hydrocarbons found in it's path, and was considered useless for distance communications.  This is still true, and has much to do with why Wifi is so poor at clear range.  It's also why this band is shared by every retail microwave that I know of, since food is pretty much all hydrocarbons and water.  While there wouldn't likely be much risk of hydrocarbons in the line of sight from low earth orbit, there would be much water.  On average, the Earth's atmosphere has enough water from space to sea level to equate to a 32 foot deep dive under the ocean's surface.  The amount of power that would be required to push through this and be receivable by common wifi hardware on the Earth's surface would be rediculous.

Second, there are also sound techincal reasons as to why wifi multicasting is not commonly used.  Mostly because wifi is a time-sharing technology that (generally) permits more than one unrelated connection to coexist on the same channel.  This is permitted because normal mode wifi requires that the hotspot 'listen' to it's own channel several times per second for other broadcasters trying to share the channel space.  This doesn't always work well, but it does work more often than most people realize.  However, a hotspot in space couldn't coordinate timesharing of all the hotspots in it's radio shadow even if it were possible for it to hear them.  In this case, the sat based signal would effectively 'jam' the chosen channel across the whole of it's radio shadow, and also be a violation of international communications treaties as a result.

Third, the licesne free broadcasting nature of the B,G band is limited to 'terrestrial' transmitters, and therefore doesn't apply to satillites at all.  A new treaty would be required to even permit such a license, since every country has max transmitter powers in the B,G band that would be WAY  what a sat would require.

While using the new N band would reduce the power requirements considerablely, the other two issues would still apply.  Perhaps a lower frequency license free band would work with modified FM band recievers, but I can't see a way around the international communications treaties regarding this.  Perhaps a broadcast stream that can switch around frequencies in the higher frequency shortwave bands would work, but the sat would have to be able to respond to the reflectivity of the ionosphere and changes in the critical frequency.  Most Shortwave broadcasters have to stay  the critical frequency so that their Earth bound transmitters can reflect their signal off of the F layer of the ionosphere, but what about a broadcaster in teh shortwave bands that deliberately stays above the critical frequency so that his signal is not reflected back into space?  Regardless, the data throughput woudl be low due to a narrow usable bandwidth and a particularly 'noisey' radio environment in those bands.

compared to what, exactly?

i'm curious to how easy it is to double spends. is it something average joes can learn to do or does it take some college kid genius with glasses and shit to do it?

would it be safe to accept with 0 confirms with, lets say a $10k purschase as a company?

It's not easy.  In fact, it's never been provabley be done in the wild.  It's entirely theoretical.

Also, even a 1 minute delay would be too long to wait in many situations. Especially as that would be the average and some confirmations would take longer. When I'm paying by credit card at a supermarket, if it takes as much as 10 seconds it annoys me. When I've finished and paid I don't want to hang around, waiting. So faster confirmation times don't really help unless they are a lot faster, like 50 times faster.

(I don't know whether Satoshi made this point, and don't much care.)

Faster confirms.


~BCX~

Transactions average 1.4 seconds from anywhere to anywhere.  Transaction clearing is what blocks are doing.  Transaction clearance for credit cards take between 30 and 45 days.


Yes he did.  He chose the 10 minute interval because it was a long enough period to prevent orphaned blocks, most of the time, due to more than one node discovering a block solution within the time period it takes to propagate a block from one edge of the network to the other.  He was assuming that, in a future that Bitcoin was wildly successful, blocks would be very large data sets and the p2p network would be very large; both contributing to network delays that might extend the time for a block to propogate from edge to edge for up to a whole minute.  Therefore, in order to limit the risk of orphaned blocks (and the blockchain splits that often accompany them) the target interval had to be several times longer than the worst case scenario for block propogation delays.  He also wanted the interval to fit neatly into human time cycles for our mental convience.  He could have done a 6 min block interval, for 10 per hour, but he was concerned that wouldn't be enough.  His fears seem correct, because even with the 10 minute interval we average about 1.5% of blocks released onto the network are orphaned.  A 6 minute interval would make that much worse, and 2 minute interval would make that rate simply awful.

Energy costs of mining BTC appear to be a minor issue to me.

Mining is centralisation through pools and specialised hardware.

Also, even a 1 minute delay would be too long to wait in many situations. Especially as that would be the average and some confirmations would take longer. When I'm paying by credit card at a supermarket, if it takes as much as 10 seconds it annoys me. When I've finished and paid I don't want to hang around, waiting. So faster confirmation times don't really help unless they are a lot faster, like 50 times faster.

(I don't know whether Satoshi made this point, and don't much care.)