Broadcasting the Blockchain

[richmke]

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.

[1714127053]

1714127053

[1714127053]

1714127053

[1714127053]

1714127053

[DeathAndTaxes]

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.

[MoonShadow]

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.

[MoonShadow]

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.

[richmke]

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.

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.

[DeathAndTaxes]

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]

[nirom]

Looks like someone is going to attempt this:

https://www.outernet.is/

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

[smooth]

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.

[MoonShadow]

Looks like someone is going to attempt this:

https://www.outernet.is/

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.

[MoonShadow]

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.

[smooth]

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.

[MoonShadow]

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.

[benjamindees]

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

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.

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.