Anyone interested in chatting about BTC RF transmissions / internetless bitcoin

[Altoidnerd]

This came about here: https://bitcointalk.org/index.php?topic=369373.msg3956377#msg3956377

Now's the time to seek venture cap.  This is more than possible.

Note: it doesn't threaten the position of developers, but perhaps the internet conglomerates.  

Edit: For now, here is a summary of the developments of the last thread, which will likely die off:

• user wumpus ->

"Bitcoin produces on average one block of max 1MB every 10 minutes.
That's ~1666 bytes per second on average, but it can be more.
So I suppose that's way too much for the available bandwidth?"

• using a chart here

http://en.wikipedia.org/wiki/Channel_capacity#Channel_capacity_in_wireless_communications

I became suddenly optimistic but failed to correctly interpret the units kb, kB, Mb, MB, byte, bit...etc to draw exact conclusions (sorry, my background is RF and physics - not all that used to base 2)





• I suggested we break down exactly who does what in the network now and determine "minimial connectivity requirements" for the following roles I listed.  I recommended we be utterly explicit and break this down to pre-k levels.

"+ There are lightweight users who transmit tx's only
    + Users tend to also enjoy notification of reception of a payment, but actually no action takes place on the receive side to receive a TX.  Receives are essentially "offline" unless you're afforded the information you've been paid - otherwise known as a receipt.

+ There are full nodes who relay the txs

+ There are miners

+ They talk to their pool servers

+ Not sure what else?



• I made a little speech:

"If you think about wireless telecommunication today, this is already possible over existing networks, but that's not really the big idea... that is merely an extension of the internet.  To go for a much greater leap forward, think passive receivers with limited transmit abilities as "wallets". Examining the function of each of the above players in the protocol and determining "minimum tolerable level of connectivity" for each would be nice.  

We can decide who holds what device and how much energy it needs to power transmissions, relays, or passive reception.  We could have people sending bitcoins with handhelds that draw little or no power, or are solar powered.  There are clever ways to transmit just a small amount of information (initiate a TX) with magnetic induction that are almost passive if not actually entirely so - they could be initiated with the amount of energy extracted from waving your hands...  Receivers can be completely passive, so syncing to the blockchain can be done with almost no energy as well (on the receive side - in principle).

Actually thinking things like this over for a night made me realize how efficient Bitcoin itself is by design, yet how inefficiently we are carrying out the underlying principle by using computers, monitors, etc.  This isn't a knock to what happened and how BTC developed online - it had to be that way.  But since bitcoin is a realization of the fact that wealth is only an account of what you have earned and spent - bits of information on a big list somewhere - bitcoin doesn't require the internet or computers at all to persist.  Bits need to flip when they need to - the internet is truly overkill."

[grux]

It's a great idea to have the btc protocol over a secondary medium, but theres going to be a lot in your way.
1) Not practical/easy to get transmitting power required to reach countrywide, or even statewide. A 5 Watt handheld radio on around 140mhz gets you only 10 miles range, it costs atleast $100 to get a non-consumer handheld radio. Beyond that you will start to need large antennas and equipment that costs thousands of dollars

2) FCC will gut you. The FCC regulates the air wave usage, they will only allow you to transmit more than a few watts on specific commercial bands. Beyond that you will need a ham license, which doesn't allow any encryption to be transmitted. Beyond that you will require a commercial license, $$$.

3) Airwaves already extremely polluted, HAM amateurs barely get any space to broadcast. It is mostly dominated by military/cellular/tv/commercial frequencies which take up 99% of available bandwidth. Extreme lobbying is required to get lower frequencies, higher frequencies require a satellite relay to use effectively across the globe.

[jojo69]

mesh net on HF

I'm all ears

[StarfishPrime]

Individual BTC transactions could quite easily be broadcast over RF, there is already widespread TCP/IP over RF networks in place called "packet radio" (amateur radio). Anyone could quite easily build an RF gateway to a bitcoin node.

Bandwidth is extremely limited however (mostly by physics). This might have some hypothetical no-more-internet/post-apocalyptic type applications but could never really replace a high bandwith scenario of millions of interconnected nodes.

[Altoidnerd]

It's a great idea to have the btc protocol over a secondary medium, but theres going to be a lot in your way.
1) Not practical/easy to get transmitting power required to reach countrywide, or even statewide. A 5 Watt handheld radio on around 140mhz gets you only 10 miles range, it costs atleast $100 to get a non-consumer handheld radio. Beyond that you will start to need large antennas and equipment that costs thousands of dollars

2) FCC will gut you. The FCC regulates the air wave usage, they will only allow you to transmit more than a few watts on specific commercial bands. Beyond that you will need a ham license, which doesn't allow any encryption to be transmitted. Beyond that you will require a commercial license, $$$.

3) Airwaves already extremely polluted, HAM amateurs barely get any space to broadcast. It is mostly dominated by military/cellular/tv/commercial frequencies which take up 99% of available bandwidth. Extreme lobbying is required to get lower frequencies, higher frequencies require a satellite relay to use effectively across the globe.

1 - It's not uncommon in our current situation that bitcoin miners are spending a lot of money to mine.  

2 + 3 - this is the guide -> http://www.ntia.doc.gov/files/ntia/publications/2003-allochrt.pdf one must dance around these.

About commercial license... $$$...bitcoin is precisely money.  Money should be available, no?
----------------

I'd like to emphasize the extreme inherent efficiency in the abstract bitcoin "idea" (not sure if protocol is the wrong word).  Some ideas of bandwidth were entertained in the previous thread, and preliminarily, I was really surprised at how low the transmit powers I was calculating were.  However, I need more support from those who have a high degree of knowledge of our current implementation to interpret exactly what the various energies required would be.

I'm going to place a summary of the developments of the last thread in the first post of this one now.  That thread got buried and it needed more knowledgeable comments to flow in.

[Altoidnerd]

Individual BTC transactions could quite easily be broadcast over RF, there is already widespread TCP/IP over RF networks in place called "packet radio" (amateur radio). Anyone could quite easily build an RF gateway to a bitcoin node.

Bandwidth is extremely limited however (mostly by physics). This might have some hypothetical no-more-internet/post-apocalyptic type applications but could never really replace a high bandwith scenario of millions of interconnected nodes.

This is true.  The bright side is I believe that most participation in the bitcoin network theoretically requires as bare minima, small transfers of data.  

IMO, the use of entire computers with big LCD displays connected up to massive servers etc etc to carry out the (cryptographic) task of logging transactions in a public record of expenses and earnings is overkill.  

Physics is my career¹,  I can address the physics concerns as they arise.  My specialization is NMR.

Question for you all: can we make a rudimentary list of the the very ROOT, most basic, elementary participants in the network and their respective quantities of transmissions/receptions of information that NEED to happen to keep bitcoin stable. (I think its a smaller amount of total information/entropy/energy than is immediately intuitive). I started this list in top post.  You can use quantities of bits and bytes but don't be surprised when I ask questions about those actually are.  

¹ _{however recently bitcoin has been my career with that price eh, AMIRITE?}

[GreekBitcoin]

I need some sleep now but as i was experimenting with transmitters and i know some things about analoge electronics that would be interesting!

[BitcoinFX]

Bitcoin or P2P currency without the internet is a very interesting proposal indeed.

Exisiting projects that spring to my mind include;

The Free Network Foundation: http://thefnf.org/

https://www.youtube.com/watch?v=R-3K9xR_Eoc


It should be possible to get something working using tones or pulses instead of radio waves, as a proof of concept.

I once suggested and tested using low latency (highest bandwidth, shortest hop) Tor circuits to allow VOIP or skype to work better with reduced lag over Tor.

https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/

Tor Fone - p2p secure and anonymous VoIP tool: http://torfone.org/

The P2P software could run on Tor hidden services, sending morse code type messages over encrypted VOIP for transactions and .onion addresses. This will help to test the latency issues which will be encountered when using Mesh networks, but can also provide both anonymity and security.


Sometimes you have to take a step backwards to move forwards. Mesh networks are the future of the internet and P2P software, infact they are much the same thing.

This concept might initially work better as a store of value as opposed to a currency, whilst still allowing for transactions to take place.

This idea reminds me of the http://wrgpt.org/ - WRGPT = World Rec.Gambling Poker Tournament

Probably the world's oldest and biggest free email poker tournament.

"Since the entire tournament is run via email it is slow as compared to online poker sites. A single hand can take several days. Fast tables can do more than one hand per day but that is unusual." - just brilliant !

[wumpus]

2) FCC will gut you. The FCC regulates the air wave usage, they will only allow you to transmit more than a few watts on specific commercial bands. Beyond that you will need a ham license, which doesn't allow any encryption to be transmitted. Beyond that you will require a commercial license, $$$.

3) Airwaves already extremely polluted, HAM amateurs barely get any space to broadcast. It is mostly dominated by military/cellular/tv/commercial frequencies which take up 99% of available bandwidth. Extreme lobbying is required to get lower frequencies, higher frequencies require a satellite relay to use effectively across the globe.

Let's just assume "in a territory where this is allowed" (dunno, maybe Antarctica?). The regulatory details of radio frequencies in different countries are not that interesting in this speculative stage. These change over time given shifts in power/money.

What is realistically possible in physics is usually a better indicator of what will happen in the future.

Question for you all: can we make a rudimentary list of the the very ROOT, most basic, elementary participants in the network and their respective quantities of transmissions/receptions of information that NEED to happen to keep bitcoin stable. (I think its a smaller amount of total information/entropy/energy than is immediately intuitive). I started this list in top post.  You can use quantities of bits and bytes but don't be surprised when I ask questions about those actually are.  

Ordered by total amount of bandwidth required:

1. By far most traffic generated by Bitcoin is the initial blockchain download. Nodes connect to random other nodes and request all the current blocks. The amount of traffic has a lower bound of the size of the block chain, but can be more due to coordination.

2. Received blocks and transactions are relayed through the network.

3. Then there are miners that broadcast new blocks. Due to difficulty adjustment this aims for 1 block of 1MB every 10 minutes, but has a Poisson distribution and there can be variations due to changes in network hashrate.

4. Then there are nodes transmitting new transactions. The volume in newly transmitted transactions is very low. Estimate would also be max 1MB per 10 minutes in total (can be more in the case not all transactions make it into a block).

If you have an alternative way to get nodes up to speed (1), and ignore the P2P gossip network (2) and replace it by a broadcast model, that leaves only 3+4 which are pretty low bandwidth.

[Qoheleth]

If you have an alternative way to get nodes up to speed (1), and ignore the P2P gossip network (2) and replace it by a broadcast model, that leaves only 3+4 which are pretty low bandwidth.

In a world without the Internet, people won't be downloading the client from a website; they'll be getting it burned on DVDs by their friends. When they burn those DVDs, it'd be logical to burn the blockchain up to that point as well. This means that (1) is reduced to the amount of "catching up" needed between when the DVDs were burned and the present. How to solve this remainder? Well, if discrete P2P connections go away, the best thing I can think of off the top of my head is to have a second channel where large nodes perpetually broadcast the most recent X blocks in a loop. You tune in, wait for it to get to where you left off, and catch up from there.

[ianspain]

Interesting idea if you guys need fund raising please contact me

[Altoidnerd]

If you have an alternative way to get nodes up to speed (1), and ignore the P2P gossip network (2) and replace it by a broadcast model, that leaves only 3+4 which are pretty low bandwidth.

In a world without the Internet, people won't be downloading the client from a website; they'll be getting it burned on DVDs by their friends. When they burn those DVDs, it'd be logical to burn the blockchain up to that point as well. This means that (1) is reduced to the amount of "catching up" needed between when the DVDs were burned and the present. How to solve this remainder? Well, if discrete P2P connections go away, the best thing I can think of off the top of my head is to have a second channel where large nodes perpetually broadcast the most recent X blocks in a loop. You tune in, wait for it to get to where you left off, and catch up from there.

Bingo.

In loose terms, the largest high power transceiver nodes would be perpetually broadcasting a signal whose information was enough to recover the updated blockchain by interpolation given a measurement of the transmission of sufficient duration commensurate with the degree to which the user's hard copy is outdated.  Having more up to date information in digital form will assist interpolation of the entire blockchain given a capture that is of finite length (in time).

+ compressed sensing comes to mind http://en.wikipedia.org/wiki/Compressed_sensing

++ in the end, it may not be necessary to use the transmission to interpolate a full digital render of the updated blockchain.  After researching I now feel one can exploit the advantages of continuous signals to speed up the acquisition time by using a weight function to decrease emphasis on unknown parts of the chain for security.  Still need to start somewhere, so I'm going to continue with the model that a user wants to "recapture" perfect information.  If that can be done it could serve as a launchpad as a proof of concept, as things would only get "easier" RF wise through such techniques.  

+++ CS and RF people don't always mean exactly the same thing when we say "bandwidth" so careful there (somebody can teach me about CS usage though and we can all have epiphanies together about how its the same I'm sure).  Here by bandwidth I mean an interval of frequencies measured in cycles per second of an electromagnetic wave traveling in space.  Make no mistake, by frequency I mean f in the relevant equations f = c / λ and c is the speed of light (in a medium such as the ionosphere).  In physics, we tend to favor f as a description of a band e.g. 800 MHz.  In radio, the wavelength λ is often used e.g. "13 cm band".  These descriptions are identical. c =~ 3e8 meters per second for quick ref.

Never ended up completing the text that follows, will be ongoing I suppose

A simple scenario - a gal wants to check her balance

In practice what will happen is a user with an outdated copy of the blockchain will try at an arbitrary time to listen to the transmission and will interpolate the updated blockchain using a measurement of duration Δt and recollect what transactions occured in the blocks that the user's old copy of the blockchain do not include. .  How long this takes, I'm not exactly sure but for a first stupid guess take the inverse bandwidth (1/BW).  If I end up renaming any common bitcoin conventions lmk

Correspondence times

I havent written this theory down yet but I can already tell a stumbling block for someone trying to understand what I mean is fourier transforms are all over the place. e.g. the time intervals over which the principal transmission is measured by a passive bitcoin user will not correspond linearly to events that occur (transactions are attempted, tx is verified, etc etc) in an intuitive way, unless you're already familiar with signal processing.  If not, its OK... fourier space (as digital to analog talk normally) involves, roughly describes the notion that every single moment of the transmission is going to describe the entire blockchain in some regard. Fourier transforms reverse the notions of global and local characteristics of a signal.  What a mouthful.

I'll have mathematics for this soon...I hope.  Anyone who knows image processing will know what I'm trying to say.  Hopefully a theorist will finish my sentences, I'm actually not a theorist but I'll start things off to describe the notion I have going right now.


The Idea:
at t = 0 the blockchain was born with block # N = (0 or 1? nbd right now).  N can reference the blockchain age [is this called "block height" in jargon?]

the user's hardcopy of the blockchain is characterized by its age.  Also the user's age will refer to the age of the hardcopy the user is holding when they connect to the bitcoin network

a bitcoin user U with an M block hard copy that is not being updated at all can be called U_M

   + could imagine a situation in which a user with an active device could be updating their copy of the blockchain all the time...this is sort of like what happens today except it will be labeled instead by a time t so that user would be called a U_M(t) because they have a time dependent copy of the blockchain.

A simple situation would be U_M tunes in and starts interpolating at some arbitrary time at which the main chains age is M + K.  

An important parameter the number of blocks K which I'll call the block deficit.  This will determine the acquisition time needed to check the balance. 

+++++++++++++

I'm going to scan literature and try to adopt conventions for the variables I named.  I will update that when I read them. 

I think I can see this but I'm running into problems with discrete variables hanging around.  it's cool it can be done, I need to brush up on how to encode digital signals too. Going to read modulation schemes https://en.wikipedia.org/wiki/OFDM I was told this one scales well with bandwidth.  It's likely for a full blkchain recovery the block deficit K will determine which band the users tunes to.  A large K would naturally have greater needs for bandwidth.  Now going to bed guys, i'm fried.  not even sure what to do right now... write down the equations or just start testing things. I think some equations would be good because math is much better at communicating this stuff than words.   anyway, i have it up there though it's churning.  gonna talk to John R. Klauder... he is good at this stuff (he's also very old).  He theorized chirp radars http://www.lucent.com/bstj/vol39-1960/articles/bstj39-4-809.pdf

[Altoidnerd]

Ordered by total amount of bandwidth required:

1. By far most traffic generated by Bitcoin is the initial blockchain download. Nodes connect to random other nodes and request all the current blocks. The amount of traffic has a lower bound of the size of the block chain, but can be more due to coordination.

2. Received blocks and transactions are relayed through the network.

3. Then there are miners that broadcast new blocks. Due to difficulty adjustment this aims for 1 block of 1MB every 10 minutes, but has a Poisson distribution and there can be variations due to changes in network hashrate.

4. Then there are nodes transmitting new transactions. The volume in newly transmitted transactions is very low. Estimate would also be max 1MB per 10 minutes in total (can be more in the case not all transactions make it into a block).

If you have an alternative way to get nodes up to speed (1), and ignore the P2P gossip network (2) and replace it by a broadcast model, that leaves only 3+4 which are pretty low bandwidth.

Perfect, thank you very much, this was needed. In RF land miners could be constantly transmitting a signal to reach other miners, and also adibatically adjust their continuous signal to

A) match the changes they measure from the other miner's signals and

B) include new TX's they hear in their environments.

Gonna let this cook overnight.

[Altoidnerd]

Interesting idea if you guys need fund raising please contact me

Could use tip bots on reddit to motivate engineers to tell us things on /r/ece. 

[psybits]

This will definitely be integral to the future of BTC.

Unfortunately, I am too busy to get too involved.

But would be happy to help spread the word: http://bitcoinprbuzz.com/services

When you get to the point of seeking capital - we could even post up an article (supplied by you) for free - if you do not have the funds for a full Press Release.

[Altoidnerd]

This will definitely be integral to the future of BTC.

Unfortunately, I am too busy to get too involved.

But would be happy to help spread the word: http://bitcoinprbuzz.com/services

When you get to the point of seeking capital - we could even post up an article (supplied by you) for free - if you do not have the funds for a full Press Release.

Thanks.  Let's see what's happening in a week when more people are involved.  I'm a better scientist than a businessman, so I would certainly need some help in this regard. 

[BitcoinFX]

Ordered by total amount of bandwidth required:

1. By far most traffic generated by Bitcoin is the initial blockchain download. Nodes connect to random other nodes and request all the current blocks. The amount of traffic has a lower bound of the size of the block chain, but can be more due to coordination.

2. Received blocks and transactions are relayed through the network.

3. Then there are miners that broadcast new blocks. Due to difficulty adjustment this aims for 1 block of 1MB every 10 minutes, but has a Poisson distribution and there can be variations due to changes in network hashrate.

4. Then there are nodes transmitting new transactions. The volume in newly transmitted transactions is very low. Estimate would also be max 1MB per 10 minutes in total (can be more in the case not all transactions make it into a block).

If you have an alternative way to get nodes up to speed (1), and ignore the P2P gossip network (2) and replace it by a broadcast model, that leaves only 3+4 which are pretty low bandwidth.

So lets clarify this. The aim is for a Radio based hardware product, which can automatically find and sync. with other similar devices, also linking in chains to the Bitcoin network through 'main' nodes which are conected to the internet to enuse connectivity.

Some installations could also be connected directly to the internet / Bitcoin network, as well as broadcasting both by Radio and WiFi for anyone to connect to send and receive transactions.

Pre-installed blockchain data on a radio hardware device will only require low bandwidth, as above posts.

2x radios (min.) in each device are probably required for this purpose i.e. one set to sync. and one set to broadcast, receive and relay transactions + optional LAN and WiFi connectivity.

'The Bitcoin Freedom Box'. Is this simply a layer technology ? or a new product entirely ?

Isaac Wilder - Free Network Foundation Technical Overview

https://www.youtube.com/watch?v=b4vjD33TIco

[mb300sd]

It's a great idea to have the btc protocol over a secondary medium, but theres going to be a lot in your way.
1) Not practical/easy to get transmitting power required to reach countrywide, or even statewide. A 5 Watt handheld radio on around 140mhz gets you only 10 miles range, it costs atleast $100 to get a non-consumer handheld radio. Beyond that you will start to need large antennas and equipment that costs thousands of dollars

2) FCC will gut you. The FCC regulates the air wave usage, they will only allow you to transmit more than a few watts on specific commercial bands. Beyond that you will need a ham license, which doesn't allow any encryption to be transmitted. Beyond that you will require a commercial license, $$$.

3) Airwaves already extremely polluted, HAM amateurs barely get any space to broadcast. It is mostly dominated by military/cellular/tv/commercial frequencies which take up 99% of available bandwidth. Extreme lobbying is required to get lower frequencies, higher frequencies require a satellite relay to use effectively across the globe.

But theres no actual encryption in the bitcoin network. All data over the network is readable by anyone, signing != encrypting.

[WindMaster]

Now's the time to seek venture cap.  This is more than possible.

...

I became suddenly optimistic but failed to correctly interpret the units kb, kB, Mb, MB, byte, bit...etc to draw exact conclusions (sorry, my background is RF and physics - not all that used to base 2)

I noticed you ended up with basically a chart of theoretical throughput vs. bandwidth vs. power, but this is really only applicable to very high frequencies (UHF and above) in a clear line-of-sight environment with no interference, atmospheric propogation phenomenon, with the carrier far above the noise floor on the receiving end, and even then it's a chart of the theoretical upper bound under absolute ideal conditions, not a real-world achievable figure.  I think a lot of the conversation so far as been focused on long-range communications in the HF realm using ionospheric propogation rather than direct line-of-sight or ground-wave propogation (as the discussion seems to be more about a small number of transmitters transmitting blocks to many end-users), which is an area that high-speed data communications is significantly hampered and will never approach the peak theoretical throughput.

• user wumpus ->

"Bitcoin produces on average one block of max 1MB every 10 minutes.
That's ~1666 bytes per second on average, but it can be more.
So I suppose that's way too much for the available bandwidth?"

I'm going to weigh in on the side that it's way too much throughput for the available bandwidth in the frequency ranges that are being discussed, in a real-world environment.  Hams in the HF bands already have significant challenges even reliably transmitting simple phase-shift data streams at ~31bps (bits per second) or ~63bps (as in PSK31 and PSK63).  For a good read on what the real-world propogation challenges are for data transmission, the right Google terms to start searching are "psk31", "dominoex", "mt63", "olivia mfsk" and such.  A good read of the background and history of MT63 would be good for understanding what is achievable when really pushing hard against the technical challenges with use of OFDM and heavy FEC to counteract interference and atmospheric propogation phenomenon.  In the MT63 case, throughput rates of 5/10/20 characters/sec (7 bits each in this case) are achievable in bandwidths of 500/1000/2000Hz spread across 64 individual PSK carriers in an OFDM arrangement with heavy FEC (which is also used to handle spreading and de-spreading of the 7-bit characters to the 64 carriers) and interleaving over time.

Note that in the PSK31 scenario, you have hams transmitting up to 1.5kW in the HF bands with massive antenna farms with extremely sporadic propogation paths and "hit or miss" results.  For the most part, it's a case of transmitting blind (perhaps as a CQ) and see if you get anyone.  And for how long you can continue communicating before propogation shifts.  And then you have hams experimenting in extremely low-power in the <1W range that sporadically talk around the world.  The whole HF propogation situation is extremely random, chaotic and unpredictable.

If the discussion shifts more toward higher frequencies that aren't as subject to these phonemonon, which would tend to mean the 2m band (144-148MHz) nearly all the time, or some of the time in the 6m band (50-54MHz), you're moving more toward line-of-sight propogation over very short distances and definitely not a scenario where a small number of transmitter sites will cover a large end-user population over a wide geographic area.  So there's a tradeoff here.  Reliable high-speed communications over short distances at higher frequencies, vs. very unreliable low-speed communications at low frequencies.

2) FCC will gut you. The FCC regulates the air wave usage, they will only allow you to transmit more than a few watts on specific commercial bands. Beyond that you will need a ham license, which doesn't allow any encryption to be transmitted. Beyond that you will require a commercial license, $$$.

But theres no actual encryption in the bitcoin network. All data over the network is readable by anyone, signing != encrypting.

I'm going to agree that what's in the blockchain doesn't qualify as encryption under the ITU rules (we need to be thinking more globally, not just in FCC territory in the US).  However, the rules that are going to prevent this from happening in the ham bands in ITU countries are that transmissions can't be for commerce (and I'm going to say that a virtual currency definitely falls into this category), and broadcasting is prohibited.  Propogation beacons and APRS maybe stretch the broadcast rule slightly.  Additionally, there are maximum bandwidths allowed in most of the ham bands under the ITU rules, and that's going to limit throughput particularly in the HF realm.

I'll add in some additional challenges to the list, this would be extremely easy for anyone to jam, and equally easy for anyone to find the location of the transmitter(s).  Many hams make a game of tracking down anything they don't like or they perceive as causing interference in their limited slices of spectrum!  Or, read up on the history of the soviet OTH-B radar ("Russian woodpecker") and all the hijinx of hams jamming and spoofing the signals to screw with it.

[Altoidnerd]

 I think a lot of the conversation so far as been focused on long-range communications in the HF realm using ionospheric propogation rather than direct line-of-sight or ground-wave propogation (as the discussion seems to be more about a small number of transmitters transmitting blocks to many end-users), which is an area that high-speed data communications is significantly hampered and will never approach the peak theoretical throughput.

Well as I suggested earlier, only some information needs to travel great distances. Exactly how little is left to be determined, but after another night of pondering I'm thinking the transmission of the entire blockchain could be canned entirely.  All that is needed is a "state measurement".  If the long range broadcast is a state function that when queried by a wallet returns the balance, we have at least done that much.

This is an eigenvalue problem in the language of linear algebra.  A wallet is a linear operator H which operates on the state of the interconnected transmit nodes (represented state vector Ψ consisting of component frequencies) which returns the scalar balance E as an eigenvalue:

HΨ = EΨ

Anyway, this is blowing smoke up the quantum mechanical ass, however the point is mainly not to get bogged down with bandwidth concerns.  Looking way way back at the original concepts behind cryptocurrency (which lie beneath bitcoin's protocol), passing around copies of this massive blockchain file as we do is probably not the end result of cryptocurrency.

Could have geosynchronous satellites relaying a coherent signal.  Any changes are felt by all other transmit nodes.  Equation above represents balance query only.

Any tx transmission would need to be described by an interaction of the observer with the state, harder problem.