Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: benjamindees on April 01, 2012, 02:03:37 AM



Title: Broadcasting the Blockchain
Post by: benjamindees on April 01, 2012, 02:03:37 AM
The Bitcoin blockchain can be kept up-to-date with less than a 2400 baud connection.  This is within the limits of amateur packet radio technology.  Using standard HAM radio transmitters and cheap SDR receivers (http://hardware.slashdot.org/story/12/03/31/1914217/software-defined-radio-for-11), this can enable an unlimited number of clients to perform transaction verification and mining, possibly in remote locations, without requiring a dedicated internet connection.  A separate uplink, such as a phone line or perhaps two-way pager, can be used intermittently to initiate transactions or to transmit mined blocks.

What do you think?  Could this concept be economical in developing countries, or in areas with high internet costs?  Could it perhaps one day enable miners to reclaim stranded renewable energy during periods of overproduction?  Could it even justify dedicated satellite or unmanned aerial transmitters?  Or is this concept simply wildly-unrealistic, pie-in-the-sky speculation?


Title: Re: Broadcasting the Blockchain
Post by: niko on April 01, 2012, 04:38:25 AM
The Bitcoin blockchain can be kept up-to-date with less than a 2400 baud connection.  This is within the limits of amateur packet radio technology.  Using standard HAM radio transmitters and cheap SDR receivers (http://hardware.slashdot.org/story/12/03/31/1914217/software-defined-radio-for-11), this can enable an unlimited number of clients to perform transaction verification and mining, possibly in remote locations, without requiring a dedicated internet connection.  A separate uplink, such as a phone line or perhaps two-way pager, can be used intermittently to initiate transactions or to transmit mined blocks.

What do you think?  Could this concept be economical in developing countries, or in areas with high internet costs?  Could it perhaps one day enable miners to reclaim stranded renewable energy during periods of overproduction?  Could it even justify dedicated satellite or unmanned aerial transmitters?  Or is this concept simply wildly-unrealistic, pie-in-the-sky speculation?

Good point. There are already amateur radio satellites in the orbit.  If they ever start broadcasting blockchain, I suggest we rename the network: Orbitcoin.


Title: Re: Broadcasting the Blockchain
Post by: FreeMoney on April 01, 2012, 05:24:47 AM
Do people really have mining gear and reliable electricity in places that this would help? And won't a phone call when they need to check on or make a payment be all they need if not mining?


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on April 01, 2012, 05:37:19 AM
https://bitcointalk.org/index.php?topic=2039.0


Title: Re: Broadcasting the Blockchain
Post by: benjamindees on April 01, 2012, 06:56:00 AM
Interesting.  I like your idea about a channel on digital satellite radio.  I wonder if those $11 SDR receivers would be capable of decoding this.

Do people really have mining gear and reliable electricity in places that this would help? And won't a phone call when they need to check on or make a payment be all they need if not mining?

Part of my original thought was that there are places where electricity is basically free at least part of the time.  But you're right, the idea isn't very useful if not mining.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on April 01, 2012, 01:25:36 PM

Part of my original thought was that there are places where electricity is basically free at least part of the time.  But you're right, the idea isn't very useful if not mining.

Sure it is.  The idea isn't particularly useful if mining, because mining requires as little a delay as possible.  Regular clients, however, can tolerate transmission delays just fine.  It's useful for getting the blockchain to parts of the world that Internet access is sparse or prohibitively expensive.


Title: Re: Broadcasting the Blockchain
Post by: Phinnaeus Gage on April 01, 2012, 02:12:46 PM
The Bitcoin blockchain can be kept up-to-date with less than a 2400 baud connection.  This is within the limits of amateur packet radio technology.  Using standard HAM radio transmitters and cheap SDR receivers (http://hardware.slashdot.org/story/12/03/31/1914217/software-defined-radio-for-11), this can enable an unlimited number of clients to perform transaction verification and mining, possibly in remote locations, without requiring a dedicated internet connection.  A separate uplink, such as a phone line or perhaps two-way pager, can be used intermittently to initiate transactions or to transmit mined blocks.

What do you think?  Could this concept be economical in developing countries, or in areas with high internet costs?  Could it perhaps one day enable miners to reclaim stranded renewable energy during periods of overproduction?  Could it even justify dedicated satellite or unmanned aerial transmitters?  Or is this concept simply wildly-unrealistic, pie-in-the-sky speculation?

I like this idea! A BitStar satellite.


Title: Re: Broadcasting the Blockchain
Post by: Omni on April 01, 2012, 02:21:30 PM
I like this idea! A BitStar satellite.

It now only costs 1,000,000 BTC!


Title: Re: Broadcasting the Blockchain
Post by: Revalin on April 01, 2012, 03:08:07 PM
For practical purposes an offline client such as Armory or an online wallet like (pick your favorite) will work fine over any phone line.

On the other hand I'd still like to see this happen just because it's cool.  :)


Title: Re: Broadcasting the Blockchain
Post by: benjamindees on February 03, 2014, 06:59:43 AM
Looks like someone is going to attempt this:

https://www.outernet.is/

Quote
By leveraging datacasting technology over a low-cost satellite constellation, Outernet is able to bypass censorship, ensure privacy, and offer a universally-accessible information service at no cost to global citizens. It's the modern version of shortwave radio, or BitTorrent from space.


Title: Re: Broadcasting the Blockchain
Post by: Sonny on February 03, 2014, 07:13:31 AM
Looks like someone is going to attempt this:

https://www.outernet.is/

Quote
By leveraging datacasting technology over a low-cost satellite constellation, Outernet is able to bypass censorship, ensure privacy, and offer a universally-accessible information service at no cost to global citizens. It's the modern version of shortwave radio, or BitTorrent from space.

The project looks great...
Quote

June 2015
Begin deployment of Outernet as launch schedule permits


Let's see how it will turn out :)


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 03, 2014, 04:47:43 PM
Looks like someone is going to attempt this:

https://www.outernet.is/

Quote
By leveraging datacasting technology over a low-cost satellite constellation, Outernet is able to bypass censorship, ensure privacy, and offer a universally-accessible information service at no cost to global citizens. It's the modern version of shortwave radio, or BitTorrent from space.

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 below 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 below 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.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 03, 2014, 05:15:22 PM
After checking my own shortwave receiver, which I believe to be fairly representative of the kinds of reciever available most of the world around, is tunable between 19,990 and 30,000 khz using it's third (final) SW band setting.  This encompasses the international shortwave bands of 15 meters (18,90019,020 kHz) 13 meters (21,45021,850 kHz) and 11 meters (25,60026,100 kHz).  All three of these bands are pretty much useless for international broadcasters because it's rare for the critical frequency to spike that high, at least not reliablely enough for a broadcaster to use.  For this reason, 11 meters is a common citizen's band in many countries and 13 meters is a regional AM band in Pacific Asia.  Wikipedia says that 15 meters is rarely utilized, and may be reallocated to DRM broadcasters in the future.

Perfect.

What needs to be done is that someone in a country that is signatory to the communications treaties needs to get a broadcasting license from their country to broadcast in the 15 meter band.  The United States is notoriously unlikely to approve such a broadcasting license, so it'd be better for someone in another country to attempt it.  I might still attempt it, but I'm not going to pursue it if it requires a $10K broadcasting fee, obviously.  The sats would still have to be aware of all licensed broadcasters in this band, and avoid them whenever possible.  I'm pretty sure that this is also a ham band, but not one that I've ever known any hams to use, as local hams use 2 meters and 70 cm while distance hams use 20, 40 and 80 meters.

A modified AM shortwave receiver could simply involve an audio output jack wired to the audio input jack of a computer sound card, with an accompaning app that can fit on a small usb drive and instructions for locating the right frequency and capturing the data stream.


Title: Re: Broadcasting the Blockchain
Post by: benjamindees on February 04, 2014, 07:38:30 AM
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.

You know more about it than I do, but perhaps this is relevant:

Quote
The signal on the ground will be fairly weak, in order to not interfere with local networks.  At this time, we're shooting for receive sensitivity of about -90dBm.

Quote
Correct, in all likelihood the noise floor in modern urban areas will be too dense. As much as we would like everyone to use Outernet, it's really meant for people who would otherwise not have access to information.

http://www.reddit.com/r/technology/comments/1wqgmh/outernet_wifi_for_the_world_from_outer_space/cf4nshr

Actually, now that I look, someone also asked this question on their forum.  The response seems dubious:

https://discuss.outernet.is/t/can-2-4ghz-even-penetrate-the-atmosphere-efficiently/34


Title: Re: Broadcasting the Blockchain
Post by: dweeceman on February 04, 2014, 08:45:38 AM
There are many ways to transmit data other than wifi.. perhaps we will find a suitable substitute...


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 04, 2014, 03:25:42 PM
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.

You know more about it than I do, but perhaps this is relevant:

Quote
The signal on the ground will be fairly weak, in order to not interfere with local networks.  At this time, we're shooting for receive sensitivity of about -90dBm.

Quote
Correct, in all likelihood the noise floor in modern urban areas will be too dense. As much as we would like everyone to use Outernet, it's really meant for people who would otherwise not have access to information.

http://www.reddit.com/r/technology/comments/1wqgmh/outernet_wifi_for_the_world_from_outer_space/cf4nshr

Actually, now that I look, someone also asked this question on their forum.  The response seems dubious:

https://discuss.outernet.is/t/can-2-4ghz-even-penetrate-the-atmosphere-efficiently/34


Well, it's either misinformed or deliberately false.  I've had my kids look at this site and another site (waterstep.org) to compare the tech claims of one charity asking for money compared to another, and we've largely come to the conclusion that this outer.in site is a scam designed to illicit donations from well intended.  As my son noted, the first clue is the "for free" claim.  That can never happen.  While it might be free to receive, there would still need be advertisments and such.  And it's not false that low earth orbit sats have used the S band, but that particular section of the S band is where the attenuation from water is greatest.

EDIT:  By "that particular" section of the S band, I mean the sliver of unlicensed bandwidth that B/G wifi occupies.  The S band is very wide, but only that portion is unlicensed, and because it's an ISM band (Insustrial, Scientific & Medical) that is used primarily for purposes besides communication.  There are other ISM bands, but none that are so wide as the one that B/G wifi (and Bluetooth, and several other short range techs) utilizes.  It's that wide because microwave ovens (in particular) use that band due to the fact that the high attenuation of radio waves by hydrogen is useful for heating with radio waves, and microwaves are so paowerful that they produce a lot of 'splatter'.  Until wifi came out, it was largely believed that  the band was useless for communications due to both the high attenuation and the likelyhood of interfereance from microwaves.  Wifi protocols are designed with the likelyhood of occasional interference in mind, however.  So is Bluetooth.  The rest of the S band experiences attentuation due to water in much the same way that radio does in general, in that the higher the frequency the greater the attenuation from water.  Both the US and Russia have massive ultra-low-frequency transmitters, with enormouse power ratings, in order to communicate with submerged submarines via morse code.  There are ham radio geeks called "lowfers" who try to communicate in this range as well, but it's hard to do anything when the wavelength of the signal is hundreds of kilometers long.  So while there are useful frequencies outside of the wifi band on the S band, they generally require more power for the same task than a lower frequency band such as the L band, and less than higher frequency bands such as the K band.  So most of the S band is particularly good for a low power downlink to consumer class receivers, just not within the B/G wifi band.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 04, 2014, 03:36:11 PM
There are many ways to transmit data other than wifi.. perhaps we will find a suitable substitute...

I'm thinking that mini sats broadcasting a DRM channel in the 15 meter band works well.  Common shortwave receivers are much better at reception than a cell phone wifi chip anyway.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 04, 2014, 09:38:14 PM
Another issue that I can see with using the small 10-cube type sats for broadcasting a wifi signal, even using the 5 Ghz N band, is that wifi channels are normally 20 Mhz wide, which is a particularly broadband signal to produce.  With wifi, this is a good thing, as your signal can cover the office without much interference and signals produced by nearby offices are strongly attenuated before they get into your office, and permits a high data rate.  However, all things being equal, a signal that is twice as broad requires twice the power to be recieved at the same distance under the same conditions.  The wifi standards permit quarter width band signals, but almost no one uses them because they don't help under normal hotspot ranges and conditions.  So, at a minimum, a wifi datacast would have to be 5 Mhz wide.  However, the DRM standard is a digital sound & data standard that uses the bandwidth of the old fashioned shortwave & AM channel standards; which is 9 Kilohertz wide in Europe and 10 Kiloherts wide in the rest of the world.  However, DRM also permits doubled or halved channel widths.  So if we compare the double DRM channel for data throughput versus the quarter width wifi for reduced power requirements and the wifi broadcast would still require roughly 250 times as much power to acheive the same signal quality on the ground versus a double wide DRM broadcast, using the same frequency, sat quality, etc.

And again, the common shortwave receiver is a far better receiver than the common wifi phone chip, so the DRM signal would be much more likely to be clearly received than the wifi signal even if the 10 cube sats could actually produce the 250 times power level.  I'd be surprised if those cube sats can produce a 50 watt RMS output on a continuous basis, and (off the top of my head) I'd say that a DRM transmission would require around 3Kilowatts to properly blanket a 600 mile circle footprint to a clear & receivable degree.  Even a half channel width DRM broadcast (4.5 Khtz wide, minimum) would require at least 1000 watts on an ongoing basis.  Keep in mind, DRM is the digital version of an AM talk radio broadcast.  A local AM broadcaster generally uses between 3 Kilowatts (at night, when the D layer doesn't attentuate the middle wave band) and 20 kilowatts just to cover a major metro area and the surrounding countryside, with a practical coverage radius of 100 to 150 miles.


Title: Re: Broadcasting the Blockchain
Post by: jongameson on February 04, 2014, 09:40:41 PM
while kewl.  u are in receive only mode.

so if u make a payment, how they gonna get it with no internet?


Title: Re: Broadcasting the Blockchain
Post by: DeathAndTaxes on February 04, 2014, 09:45:24 PM
Actually, now that I look, someone also asked this question on their forum.  The response seems dubious:

https://discuss.outernet.is/t/can-2-4ghz-even-penetrate-the-atmosphere-efficiently/34

Why is the response dubious.  Remember this isn't a two way system.  It is more like broadcast sat TV but for information.

2.4 Ghz is fine for sat downlink (remember one direction only).

For example one sat radio system runs on L brand which is 1 to 2 Ghz.
http://en.wikipedia.org/wiki/WorldSpace

In the US Sirius XM radio operates at 2.3 Ghz.
http://en.wikipedia.org/wiki/S_band


Title: Re: Broadcasting the Blockchain
Post by: DeathAndTaxes on February 04, 2014, 09:46:31 PM
while kewl.  u are in receive only mode.

so if u make a payment, how they gonna get it with no internet?

They won't.  However if they have even slow, weak internet access they can use that as the uplink and avoid the cost and frustration of trying to download the blockchain over that limited high cost link because it is being beamed out to blanket the entire earth.

The first sat internet worked on a similar fashion.  The sats were downlink only.  Your dish could only receive not send.  So your uplink was by modem and your downlink was by sat.  Another example is stock quotes.  They were at one time broadcast services for pro traders because the full feed exceeded what was available in internet connectivity (think dialup).  You could receive quote stream as a broadcast and use your slow limited internet connection just for trades.

Yeah antiquated by todays standards for the 1st world but still viable for bitcoin, because the bandwidth requirements are very asymmetric.  It is GB and GB to download (possibly GB a week in the future) but tx are very small so the uplink requirements are minimal.  You probably could do it by SMS to internet gateway if you had to.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 04, 2014, 10:09:08 PM
Actually, now that I look, someone also asked this question on their forum.  The response seems dubious:

https://discuss.outernet.is/t/can-2-4ghz-even-penetrate-the-atmosphere-efficiently/34

Why is the response dubious.  Remember this isn't a two way system.  It is more like broadcast sat TV but for information.

2.4 Ghz is fine for sat downlink (remember one direction only).

For example one sat radio system runs on L brand which is 1 to 2 Ghz.
http://en.wikipedia.org/wiki/WorldSpace


That is a full sized sat with much higher power levels.

Quote

In the US Sirius XM radio operates at 2.3 Ghz.
http://en.wikipedia.org/wiki/S_band

And this is a full sized sat runing on much higher power levels.  And neither of them use the B/G wifi band, which as I have alrady noted, is heavily attenutated by water and hydrocarbons in a way that the rest of the S band is not, and is the primary reason that said band is unlicesned to start with.

The best comparison that we might have for a setup that would work woudl be a ham radio sat.  Here's one to compare...

http://www.amsat.org/amsat-new/satellites/sat_summary/ao51.php
http://en.wikipedia.org/wiki/AO-51

This one uses several transmitters, but keep in mind that not only is this device using much narrower bandwidths, it's not attempting to transmit continuously.  So putting out a 38 Kbps data signal at 300+ watts RMS for an average of a minute or two per hour is within the power requirements of a mini sat that has a 30 watt solar panel.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 04, 2014, 10:11:00 PM
while kewl.  u are in receive only mode.

so if u make a payment, how they gonna get it with no internet?

There are many ways to solve the transaction propogation problem, the datacasting proposal in this thread is to solve the bulk blockchain distribution problem.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 04, 2014, 11:02:36 PM
The best way to make the datacasting idea work with consumer class wifi devices, would be to choose the wifi channel that is the most "distant" from the frequency that microwave ovens use and set it to a quarter channel multicast mode.  Even still, the sat wouldn't be able to broadcast continuously and hit the -90 decibel signal point, it would have to broadcast in scheduled bursts.  That might be okay, but even at -90 decibels, I don't think a cell phone would be able to hear it.  A consumer grade hotspot with a marginally directional antenna pointed up might be able to receive the signal reliablely on a clear night (no clouds in the path, no sunlight induced ionosphere 'crashes' to raise the static background level) but if the guy wanting to receive these datacasts has to buy or build dedicated gear to receive it, then what good is trying to do it using wifi standards and channels?  Datacasting is one of the design goals for DRM shortwave broadcasting.

I'm not convinced that a 10 cube mini sat has the power to push a receivable DRM signal on a continuous basis anyway.  Again, an on-off transmit schedule might be best, particularly with the low earth orbit sats that circle the globe several times per day.  They are usually only 'visable' to any particular receiver for about a half an hour, so perhaps a 10 minute burst of data followed by 50 minutes of rest/solar charging might still work.  Of course, all these kinds of compromises reduce the actual amount of data that can be broadcast.  Eventually we end up back with a normal shortwave broadcasting operation on planet Earth that can transmit continuously from a grid and reflect their signal off the ionosphere.


Title: Re: Broadcasting the Blockchain
Post by: DeathAndTaxes on February 04, 2014, 11:24:18 PM
And this is a full sized sat runing on much higher power levels.  And neither of them use the B/G wifi band, which as I have alrady noted, is heavily attenutated by water and hydrocarbons in a way that the rest of the S band is not, and is the primary reason that said band is unlicesned to start with.

Come on now, you can't be serious.  Yes water and hydrocarbons do attenuate all signals (to a different degree), but physics is physics and there isn't a magical attenuation window right at 2.4 Ghz.  

You got a point on the power of the sat but water is going to look the same to a radio wave at 2.4Ghz as it does at 2.3 Ghz (and 2.5Ghz and 2.2 Ghz).  Now at 12 Ghz it would be a different story.  That is the major disadvantage of Ku sat communication band.  Much higher power (no interference with earth bound microwave transmitters) but in areas with a a lot of rainfall it is inferior to C band because water is almost opaque to a 12 Ghz radio wave.  So areas with a lot of rainfall generally use the lower end of C band instead (~4 Ghz).

I am not sure if it would have enough power, that is a good point, but the frequency is fine.  If you have a cite showing 2.4 Ghz attenuates far worse than 2.2 Ghz or 2.5 Ghz I would love to read it.  BTW I agree with you that the project is likely too ambitious for the power and size constraints.  To use consumer wifi band would probably require more power and more powerful transmitters.  Still I like the idea in general as a way to blanket the earth with the blockchain.



Title: Re: Broadcasting the Blockchain
Post by: DeathAndTaxes on February 04, 2014, 11:34:51 PM
but if the guy wanting to receive these datacasts has to buy or build dedicated gear to receive it, then what good is trying to do it using wifi standards and channels?  

I think using standard wifi gear (like an off the shelf usb dongle or a cellphone) is likely a pipe dream.  They were never really designed that kind of purpose.  Still there is merit in using the wifi frequency (and possibly channel structure) as it would drop the cost of mass producing customized receivers.  The chips that power wifi radios are dirt cheap because they are produced by the billions each year.    Hell you might get away with using a high gain antenna and a custom firmware flashed on a certain routers (think dd-wrt but for space based signal).

The other advantage is that there is no license required.  5 Ghz might be a better choice though, I wonder if there is any data on comparisons between 2.4 Ghz and 5.0 Ghz over this type of link.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 04, 2014, 11:47:36 PM
And this is a full sized sat runing on much higher power levels.  And neither of them use the B/G wifi band, which as I have alrady noted, is heavily attenutated by water and hydrocarbons in a way that the rest of the S band is not, and is the primary reason that said band is unlicesned to start with.

Come on now, you can't be serious.  Yes water and hydrocarbons do attenuate all signals (to a different degree), but physics is physics and there isn't a magical attenuation window right at 2.4 Ghz.  


Hmm, I was going off of memory, but upon checking it seems that 2.45 Ghz isn't the resonate frequency of hydrogen.  Apparently that's actually 1.42 Ghz, or more precisely 1,420,405,751.786 hertz.  And checking oxygen it's 5.85 Ghz.  So apparently I was wrong about 2.45 Ghz having a high attenuation point.  I just got called out, and failed to perform.  Well done, Death.

According to this page, 2.45 is a "good average" between those two, with the goal of permitting the radio signal some degree of penetration into the food, which (according to them) wouldn't be possible with a precise resonate frequency because the signal would dump all it's energy into the first couple of millimeters of the surface.

http://www.schoolphysics.co.uk/age16-19/Wave%20properties/Wave%20properties/text/Microwave_ovens/index.html

In my defense, there does exist a "magical attenuation window" in the microwave spectrum, it's just not at 2.45 Ghz.  So my complaints about high attenution in teh wifi spectrum are without merit.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 04, 2014, 11:57:26 PM
but if the guy wanting to receive these datacasts has to buy or build dedicated gear to receive it, then what good is trying to do it using wifi standards and channels?  

I think using standard wifi gear (like an off the shelf usb dongle or a cellphone) is likely a pipe dream.  They were never really designed that kind of purpose.  Still there is merit in using the wifi frequency (and possibly channel structure) as it would drop the cost of mass producing customized receivers.  The chips that power wifi radios are dirt cheap because they are produced by the billions each year.    Hell you might get away with using a high gain antenna and a custom firmware flashed on a certain routers (think dd-wrt but for space based signal).


That's just the thing, if you have to get a dd-wrt and a directional antenna to receive it, why not just use DRM and shortwave receivers?  Again, datacasting is what DRM was designed for, and it uses a much more "efficient" schema in addition to the much narrower bandwidth (power) requirement.  Sure, it's data rate is slower, but like you said, that's physics.

Quote

The other advantage is that there is no license required.  5 Ghz might be a better choice though, I wonder if there is any data on comparisons between 2.4 Ghz and 5.0 Ghz over this type of link.


That's actually not true.  The license free ISM bands are only license free for terrestrial & incidental emitters, and every nation sets a pretty low transmission power limit.  The ISM license free argument, for a low earth orbit sat, fails on both counts.  They might get away with it, if they can get the sat up there and say "opps, sorry", but they won't get away with it if teh FCC gets wind of it.


Title: Re: Broadcasting the Blockchain
Post by: benjamindees on February 05, 2014, 04:54:35 AM
Why is the response dubious.  Remember this isn't a two way system.  It is more like broadcast sat TV but for information.

Mostly because the "world record" link they cite is not 2.4ghz and uses carefully-aligned directional antennas on both ends and "high sensitivity" receivers.  Putting that in a cubesat and broadcasting to consumer grade hardware, without an antenna or tracking, stretches credulity a bit.

The closest precedent I've found is the CanX-2 satellite, which was 3u and broadcast in the S band at 256 kbps, though likely to a directional receiver.

http://www.utias-sfl.net/nanosatellites/CanX2/system.html

One of the other issues they have mentioned is that the 802.11 spec requires a minimum speed of 1 mbit.  So there is still a gap between what is clearly possible and what they claim to want to do.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 05, 2014, 05:49:14 AM


One of the other issues they have mentioned is that the 802.11 spec requires a minimum speed of 1 mbit.  So there is still a gap between what is clearly possible and what they claim to want to do.

Within official specs, yes.  However there is an extended range mode that is supported by some chipsets.

http://www.qsl.net/kb9mwr/projects/wireless/atheros_XR_whitepaper.pdf

I have no idea how common such support is for cell phones, but with a receive sensitivity of -107 db the loss of data rate might actually make this thing workable.


Title: Re: Broadcasting the Blockchain
Post by: benjamindees on February 05, 2014, 07:25:42 AM
That chipset is pretty old.  Atheros was acquired by Qualcomm since then.  If it's supported in recent chipsets, Qualcomm is being quiet about it.

http://www.dd-wrt.com/phpBB2/viewtopic.php?t=73941

Quote
XR mode seems to be bullshitware.
it never really existed or was never really implemented..

There is no public account of it ever working or being tested compared reviewed in either Linux or Windows.
Nobody I've talked with knows anything about or has ever seen this work..

If they have, they are not willing to share information.

Atheros + any entitiy that sells XR mode enabled devices has never been publicly challenged or reviewed or otherwise documented on the XR feature
other than repeat of the sales information and what the feature promised to offer.

This is my opinion and is based on 6 months of solid digging & research.

I am and have been in direct contact with Atheros on the subject and I'm told it's no longer sold or supported.

This project is getting interesting, for a whole host of reasons.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 05, 2014, 02:09:56 PM
XR is not bullshitware.  I've seen it put into practice by hams.

http://www.qsl.net/kb9mwr/projects/wireless/modify.html

While these guys aren't to keen on it for their purposes, it does work somewhat.  Basicly the timing of transmissions are slowed down, to permit better low-signal copy.  A similar trick can be used with 100baseTX ethernet to extend the cable range limit between two bridge devices.  Your datarate is affected as well, which they admit.  Hams do something similar with very slow computer controlled morse code.

http://www.martellotowergroup.com/The_Martello_Tower_Group/QRSS.html


Title: Re: Broadcasting the Blockchain
Post by: benjamindees on February 06, 2014, 09:18:55 AM
From your link:

Quote
Sadly thus far, there has been little 3rd party driver support to include this.  Note that all of the newer Atheros Chipsets starting with the 9XXX series (The stuff that now is pushing 802.11n) has dropped XR mode.

I understand how it works.  What you don't seem to understand is that there is a reason it has been discontinued.  It's probably not a technical reason.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 06, 2014, 10:39:36 PM
From your link:

Quote
Sadly thus far, there has been little 3rd party driver support to include this.  Note that all of the newer Atheros Chipsets starting with the 9XXX series (The stuff that now is pushing 802.11n) has dropped XR mode.

I understand how it works.  What you don't seem to understand is that there is a reason it has been discontinued.  It's probably not a technical reason.

True.  I have no idea how many chipsets that might harbor a hidden support for XR mode might exist in the wild. 


Title: Re: Broadcasting the Blockchain
Post by: richmke on February 06, 2014, 11:06:32 PM
The Bitcoin blockchain can be kept up-to-date with less than a 2400 baud connection.  ... Or is this concept simply wildly-unrealistic, pie-in-the-sky speculation?

Maintaining the blockchain requires bi-directional communication. Your proposal is basically transmit only. that works ok for something like price quotes, where if you miss one, you just wait for the next time it is quoted. If you miss a part of the block chain, you need to request the data to be retransmitted. What if your town looses power for 8 hours? You need all that data to be rebroadcast when power comes back up.

I could see the broadcast for the major part of the data, and your own internet connection to request missed blocks.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 07, 2014, 04:29:13 AM
The Bitcoin blockchain can be kept up-to-date with less than a 2400 baud connection.  ... Or is this concept simply wildly-unrealistic, pie-in-the-sky speculation?

Maintaining the blockchain requires bi-directional communication.


This is not true.  Transacting with bitcoin requires bi-directional communications between transacting parties, but maintaining a local copy of the blockchain most certainly does not.

Quote

I could see the broadcast for the major part of the data, and your own internet connection to request missed blocks.


This would work also, but is not required per the light client protocol.  What has been proposed is to broadcast the blocks as they are published, and ultimately to broadcast the blocks "naked" once that protocol is ready.  The reason is that, eventually, most user clients will be some flavor of light client.  Unlike a full client, that are normal today, a light client doesn't care about all of the transactions in a block, and doesn't participate in the p2p bitcoin network (other than as an edge node, listening for it's own transactions).  A light client can fucntion just fine with occasional access to a bridge node (such as an electrum node) that can provide the light client information concerning transactions it's seen with addresses that the light client manages.  All that the light client requires is the blockchain headers and the merkel trees of block that contain input transactions for all of it's own addresses.  Broadcasting the published blocks would provide an alternative method for light clients to aquire the most recent block headers & merkle trees.  A light client may or may not keep the merkle trees for the blocks that it doesn't have input transactions, but as small as they are individually, the actual transactions are the bulk of data a full node sees while connected to the p2p network, and a light client has no use for most of these transactions.  Datacasting of naked blocks (block headers and merkle trees with all transactions pruned out) to either light clients directly or to disconnected bridge nodes used as intermediaries would permit bitcoin economies to function with only slow or occasional access to the Internet.


Title: Re: Broadcasting the Blockchain
Post by: richmke on February 08, 2014, 09:30:56 PM
All that the light client requires is the blockchain headers and the merkel trees of block that contain input transactions for all of it's own addresses.

Uni-direction communications assumes transmission without errors. For most things, like television and radio, once it is passed, it is passed, and you only care about what is on now.

Possible errors are:
1) Garbled communications
2) Receiver not working (turned on, error, your are in a basement/tunnel, etc.)
3) Failure of the client (crash, not turned on, busy doing something else, etc.).

So, you need bi-direction communications to request the retransmission of missed blocks. Yes, the lite client only needs its blocks, but it does not know that it missed a block with data that it needs. With bi-direction communication, the lite client can request block numbers relevant to it (with its address), check to see which of the blocks it does not have, and if it is missing any, request a retransmission.

Think about this scenario:
1) There is a service that transmits new blocks in the clear. It is active 24/7
2) Your client goes off line for 2 hours (battery died, and you did not know it).
3) At one hour into your blackout, a block relevant to you was transmitted.
4) At hour 2, you put in a new battery and start receiving blocks again.

Without bi-directional communications, how do you get the missed block?


Title: Re: Broadcasting the Blockchain
Post by: benjamindees on February 08, 2014, 10:43:23 PM
What you do is this.  Let's say the blockchain requires 2400 baud just as a constant stream.  Instead, you broadcast at some higher rate, say 4800 baud.  With the extra bandwidth, you re-broadcast the same thing, but delayed a bit.  So, with twice the bandwidth, each block gets transmitted twice.  If you miss it the first time, you have a chance of getting it the second.  With more bandwidth, you can add on more interesting schemes such that, eventually with enough throughput, it's possible to transmit the entire blockchain over and over again in pieces and if you listen long enough, you're guaranteed to get all of it.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 09, 2014, 02:02:07 AM
What you do is this.  Let's say the blockchain requires 2400 baud just as a constant stream.  Instead, you broadcast at some higher rate, say 4800 baud.  With the extra bandwidth, you re-broadcast the same thing, but delayed a bit.  So, with twice the bandwidth, each block gets transmitted twice.  If you miss it the first time, you have a chance of getting it the second.  With more bandwidth, you can add on more interesting schemes such that, eventually with enough throughput, it's possible to transmit the entire blockchain over and over again in pieces and if you listen long enough, you're guaranteed to get all of it.

Most datacasting protocols (for example, Digital Radio Mondiale) includes this delayed double transmission within it's protocol automaticly.  It's called "forward error correction".  While not perfect, it does work pretty well and actually doesn't require a full doubling of bandwidth.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 09, 2014, 02:06:39 AM

Without bi-directional communications, how do you get the missed block?


You don't always need a missed block, but if you do, there are alternative paths to aquire missed data.  That's the advantage of a true p2p network, you're never dependent upon any particular peer for performance.  Datacasting the blockchain would reduce the bandwidth requirements of (potentially) thousands of clients within the practcial range of the datacaster.  That does not mean that it would eliminate the occasional need for a direct connection to the bitcoin network.


Title: Re: Broadcasting the Blockchain
Post by: richmke on February 09, 2014, 04:05:19 PM
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.




Title: Re: Broadcasting the Blockchain
Post by: DeathAndTaxes on February 10, 2014, 01:07:38 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.



Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 11, 2014, 03:15:51 AM
Without bi-directional communications, how do you get the missed block?


For an example of effective Internet access for the very patient, google the term "pskmail".  With bandwidths that are exponents of 31.25, (31.25,62.5,125,250,500 and 1000 Htz) and practial after-error-correction data rates that are very close to those numbers; the spectral efficiency of PSK on shortwave is very close to 1:1.  Which is excellent for anything that bounces off a kilometers thick refractor, normally called the ionosphere.  The range using relatively affordable equipment is uncontested at normal power levels.  Could this be used to datacast the blockchain? No.  Could this be used to broadcast locally generated transactions?  Yes.  Could this be used to broadcast requests for missed blocks?  Yes.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on February 11, 2014, 03:48:13 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?


Oh, I'm sorry I missed this little tidbit.

The client knows when it's missing a block, because the headers are numbered as well as "chained".  It can tell immediately when it's missed a block.  How that can be handled, either automaticly or otherwise, would depend upon the user's situation.  Something like a Pskmail server, modded for Bitcoin, would work for the random user far from any urban area.  So would paying for a few megabytes over a sat phone.  Even a usb drive over a snailmail "sneakernet" (or, more likely for the regions discussed, a "motorcyclenet") would work great as a method to get a somewhat recent copy of the full blockchain into otherwise disconnected networks.  A single, modified client running on something like a piratebox could form the basis for bitcoin trades among patrons at a particular market.  If the client could receive a regular or on-going datacast stream of block-headers & merkle trees; it could verify that the network has accepted transactions that occured locally (since it already had those transactions) and learn about all other transactions from a regular full blockchain update via a monthly usb-drive delivery from a completely different source.  It could broadcast it's own locally discovered transactions to the rest of the network via PSKmail like shortwave connection once each day, by connecting to such a server 300 to 400 miles away (Near vertical incidental skywave, single hop) using a soundcard connected single-side band tranceiver (most common shortwave gear) pushing only 10 watts.


Title: Re: Broadcasting the Blockchain
Post by: richmke on February 11, 2014, 04:44:05 PM
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%.

That's my point. It might be good for 95% of the data. But, you need bi-directional communications to get 100%. Prior posters are envisioning a lite client that solely relied upon the broadcast. The lite client does not need 100% of the block chain. But, it does need 100% of the block chain that is relevant to it.

Quote
The client knows when it's missing a block,

The client WILL miss a block at some point in time, for whatever reason. That is a certainty. The Client WILL miss a rebroadcast(s) eventually too. But, the client does not know if the missed blocks are relevant to it. At a minimum, it needs bi-directional communications to requested the missed blocks. More likely, to reduce bandwidth on a slow/expensive connection, it queries the block chain for transactions with it's addresses, and if the blocks are not it its storage, then request those blocks to be transmitted either via the slow/expensive connection, or through the public broadcast.

One possible minimum slow/expensive communication is to send to the public broadcast a request with: Addresses, and Last Good Block Number (last block number where it knows it has 100% of the relevant blocks). The public broadcast could then rebroadcast any missed blocks.


Title: Re: Broadcasting the Blockchain
Post by: DeathAndTaxes on February 11, 2014, 04:50:15 PM
When people are saying the system is uni-direction they are not indicating that one can be a node without any other form of communication.  The "what if they miss a block" kinda misses the larger issue on OBVIOUSLY you need two way communication to transmit transactions.  Having 100% of blocks and no way to spend coins is equally useless.

The point was the SATELLITE link can be unidirectional.  Trying to make a bidirectional sat link is a pipe dream but likely it isn't necessary.

Sat ----- one way data broadcast----------->   [ Node ]  < ------ slower/expensive/limited internet connectivity --------> [ Internet]


Title: Re: Broadcasting the Blockchain
Post by: nirom on March 26, 2014, 04:51:26 AM
Looks like someone is going to attempt this:

https://www.outernet.is/

Quote
By leveraging datacasting technology over a low-cost satellite constellation, Outernet is able to bypass censorship, ensure privacy, and offer a universally-accessible information service at no cost to global citizens. It's the modern version of shortwave radio, or BitTorrent from space.

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.


Wow, where to begin. First of all, B, G and N are protocols in the 802.11 family, There are two bands of frequency used by wifi 2.4 Ghz and 5.8Ghz, the latter being 802.11n only. Wifi technology relies on having two-way communication, it is not a broadcast type of comm. Satellite are sending a lot of power on microwave bands (6Ghz to 10Ghz) but your cellphone won't ever be able to rech the satellite. Second, the signal coming down is picked up by a dish, which is essentially focusing the RF energy. Your cellphone work because it is pushing it's signal to nearby towers, not a sat in space.

I suggest reading up on material from the American Radio Relay League, which has amazing content out there that explains all radiofrequency communications.

Enjoy

nirom


Title: Re: Broadcasting the Blockchain
Post by: smooth on March 26, 2014, 05:05:38 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.

You can retransmit blocks with decreasing frequency as they get older. If you miss recent blocks, wait a little while and you get another copy. If you missed old blocks, you may have to wait a long time to get them, but you will eventually get them.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on March 26, 2014, 08:49:24 PM
Looks like someone is going to attempt this:

https://www.outernet.is/

Quote
By leveraging datacasting technology over a low-cost satellite constellation, Outernet is able to bypass censorship, ensure privacy, and offer a universally-accessible information service at no cost to global citizens. It's the modern version of shortwave radio, or BitTorrent from space.

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.


Wow, where to begin. First of all, B, G and N are protocols in the 802.11 family, There are two bands of frequency used by wifi 2.4 Ghz and 5.8Ghz, the latter being 802.11n only. Wifi technology relies on having two-way communication, it is not a broadcast type of comm. Satellite are sending a lot of power on microwave bands (6Ghz to 10Ghz) but your cellphone won't ever be able to rech the satellite. Second, the signal coming down is picked up by a dish, which is essentially focusing the RF energy. Your cellphone work because it is pushing it's signal to nearby towers, not a sat in space.

I suggest reading up on material from the American Radio Relay League, which has amazing content out there that explains all radiofrequency communications.

Enjoy

nirom

I wrote a rather lengthly response to this, but it  got destroyed by a database error.  In short, you're misreading my posts & I have long ago gone to their forum to correct their misconceptions about what is feasible.  They are now considering using Digital Radio Mondiale as their protocol, and I was thanked personally for that suggestion.


Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on March 26, 2014, 08:55:39 PM
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.

You can retransmit blocks with decreasing frequency as they get older. If you miss recent blocks, wait a little while and you get another copy. If you missed old blocks, you may have to wait a long time to get them, but you will eventually get them.

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.


Title: Re: Broadcasting the Blockchain
Post by: smooth on March 26, 2014, 09:04:51 PM
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.

You can retransmit blocks with decreasing frequency as they get older. If you miss recent blocks, wait a little while and you get another copy. If you missed old blocks, you may have to wait a long time to get them, but you will eventually get them.

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.

How do you know who is using the service, if it is broadcast?  Sure you could require that clients register with the head end, but given the original claim (which I have not verified) that broadcasting the entire block chain can be done at 2400 baud, the broadcast service could be used by anyone and everyone passively without registering if it includes the entire block chain (or perhaps some pruned version of it). It is likely difficult to envision in advance all of the potential uses for such a service. Smart property comes to mind, for one thing.





Title: Re: Broadcasting the Blockchain
Post by: MoonShadow on March 26, 2014, 09:13:18 PM
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.

You can retransmit blocks with decreasing frequency as they get older. If you miss recent blocks, wait a little while and you get another copy. If you missed old blocks, you may have to wait a long time to get them, but you will eventually get them.

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.

How do you know who is using the service, if it is broadcast?  Sure you could require that clients register with the head end, but given the original claim (which I have not verified) that broadcasting the entire block chain can be done at 2400 baud,


The entire block header chain can be broadcast at 2400 baud, and individual clients can transact at 2400 baud.  This isn't remotely the same as participating in the bitcoin network as a full peer, and I'm pretty sure no one has claimed this.


Title: Re: Broadcasting the Blockchain
Post by: benjamindees on July 12, 2014, 10:55:38 PM
Apparently a group in Finland has convinced the national TV broadcaster to test this out:

http://slashdot.org/submission/3694105/finnish-national-digital-tv-broadcaster-starts-sending-bitcoin-blockchain

Quote
We have found a partner who is able to cover costs for the pilot stage. The pilot stage will start in 1st of September, 2014 and last for 2 months. The broadcast area covers 95% of Finnish population, approximately 5 million people.

Quote
What is Kryptoradio?

Kryptoradio is a bitcoin data transmission system that

    transmits bitcoin transactions, blocks, and currency exchange data,
    does all this in real-time,
    uses terrestrial television (DVB-T) transmitters around the world.
    Bitcoins in the air, literally speaking.