Datacasting is perfect for bitcoin, anyone has $100,000,000 for a satellite?
(back to reality). Radio would be perfect for bitcoin, even for 10MB/s the band space would not be excessive. Bitcoin is a true one-to-many broadcast once it is compiled by the network.
Topic: Datacasting the blockchain - page 3. (Read 4313 times)
Thinking about the 'lightweight' standalone client concept, it occurred to me that, since the thin clients don't generate, block data only moves in and only transactions are bi-directional.
In terms of a thin client, I'm not entirely sure that blocks would be necessary at all. Certainly a think client may only have to keep track of the last few blocks to confirm transactions have been accomplished and what blocks may have coins they are using. In addition, they would have to listen to and transmit unconfirmed transactions that are floating around the network, but it wouldn't have to be all that much data.
The transaction traffic would not be much data for any particular client, but any standalone client must receive and process the blockchain in order to track it's own received and sent coins. The 'lightweight' client wouldn't keep much of the blockchain once it had been processed and pruned as much as the merkle trees could be, but it still has to see every block as far as I understand it. This one-to-many data model means that the blockchain is ideal for the datacasting concept, whether it's shortwave in middle Africa or a 4am sat downlink in North America, the concept remains the same. We've discussed at length how large blocks would have to grow to process the transaction rates that Paypal does daily on this forum, and how that kind of disk storage requirements limits who is likely to generate in the future; but just imagine the bandwidth that this p2p network would continuously consume if only 10% of the cellphones in the US had a lightweight client and had to update blocks over an Internet connection directly from the p2p network. It would dwarf bittorrent if bitcoin is remotely as well known as Facebook or youtube.
Thinking about the 'lightweight' standalone client concept, it occurred to me that, since the thin clients don't generate, block data only moves in and only transactions are bi-directional.
In terms of a thin client, I'm not entirely sure that blocks would be necessary at all. Certainly a thin client may only have to keep track of the last few blocks to confirm transactions have been accomplished and what blocks may have coins they are using. In addition, they would have to listen to and transmit unconfirmed transactions that are floating around the network, but it wouldn't have to be all that much data.
Thinking about the 'lightweight' standalone client concept, it occurred to me that, since the thin clients don't generate, block data only moves in and only transactions are bi-directional. So for any thin client that has a Dash7 radio, direct access to the Internet is not necessary if the client has a shortwave receiver and can listen to a 'datacast' of the blocks. Digital Radio Monodial has the ability to broadcast data interweaved into it's broadcast, which does not need to be directly related to the radio show; or a digital broadcast of the blocks could occur independently of commercial broadcasting. This technique could permit clients running on old or dedicated hardware hundreds of miles from a wifi hotspot to keep relatively up to date, and continue to trade transactions locally via Dash7 under the assumptions that eventually such transactions will filter back to the Internet by some vector, and then be seen in a block in the next day's regular blockchain broadcast. Of course, the blockchain is likely to eventually grow too fast for this as a piggyback datacast on a commercial DRM broadcast. Yet, if bitcoin takes over the world, then a dedicated & continuous datacast that can keep up with the blocks is still a very effective way to keep mass numbers of mobile thin clients updated without consuming massive amounts of bandwidth over the Internet.
Jump to: