Datacasting the blockchain

[MoonShadow]

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.

[RHorning]

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.

[MoonShadow]

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.

[da2ce7]

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.

[jgarzik]

Post blocks to alt.bitcoin

[MoonShadow]

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.

A bitcoin channel on satellite radio would work well, there is no need for a dedicated satellite.

[MoonShadow]

Post blocks to alt.bitcoin

I think that you are missing the point.  The p2p network uses the available bandwidth efficiently, but it still consumes bandwidth.  Datacasting would reduce the need for vast numbers of nodes.  Although it may not be as beneficial as I first thought if the p2p network considers the proximity of other nodes.

[theymos]

That would be a really efficient way of downloading the block chain, especially for poor communities. You can use Bitcoin with even the most primitive dial-up connection if you can get the block chain.

It's probably possible to allow people to download a "block digest" containing the first few few bytes of all addresses in that block. This wouldn't work with non-standard transactions, but it should allow general use without downloading entire blocks. Even this might be too much data for super poor communities in Africa, though.

[appamatto]

That would be a really efficient way of downloading the block chain, especially for poor communities. You can use Bitcoin with even the most primitive dial-up connection if you can get the block chain.

It's probably possible to allow people to download a "block digest" containing the first few few bytes of all addresses in that block. This wouldn't work with non-standard transactions, but it should allow general use without downloading entire blocks. Even this might be too much data for super poor communities in Africa, though.

Is multicast/broadcast functioning at all?

For information that needs to be retransmitted repeatedly it seems much more efficient than p2p, although I'm not sure what to do when nodes need a retransmit.

[MoonShadow]

That would be a really efficient way of downloading the block chain, especially for poor communities. You can use Bitcoin with even the most primitive dial-up connection if you can get the block chain.

It's probably possible to allow people to download a "block digest" containing the first few few bytes of all addresses in that block. This wouldn't work with non-standard transactions, but it should allow general use without downloading entire blocks. Even this might be too much data for super poor communities in Africa, though.

Is multicast/broadcast functioning at all?

No.  It would be a compromise that the Bitcoin community isn't interested in at this time.  It shouldn't be hard to do if the time came for it.

[appamatto]

That would be a really efficient way of downloading the block chain, especially for poor communities. You can use Bitcoin with even the most primitive dial-up connection if you can get the block chain.

It's probably possible to allow people to download a "block digest" containing the first few few bytes of all addresses in that block. This wouldn't work with non-standard transactions, but it should allow general use without downloading entire blocks. Even this might be too much data for super poor communities in Africa, though.

Is multicast/broadcast functioning at all?

No.  It would be a compromise that the Bitcoin community isn't interested in at this time.  It shouldn't be hard to do if the time came for it.

I meant ip multicast and broadcast (not sure if that was clear)

[MoonShadow]

That would be a really efficient way of downloading the block chain, especially for poor communities. You can use Bitcoin with even the most primitive dial-up connection if you can get the block chain.

It's probably possible to allow people to download a "block digest" containing the first few few bytes of all addresses in that block. This wouldn't work with non-standard transactions, but it should allow general use without downloading entire blocks. Even this might be too much data for super poor communities in Africa, though.

http://www.wmo.int/pages/prog/www/TEM/EMDCS-INT/satbroadcast-india.htm

If this page is remotely recent, then datacasting a daily digest of the most recent blocks would be relatively cheap for all of Africa, India or South America.  A company that sold POS devices for businesses without any reasonable broadband access to the Internet could sign up for the daily digest, receive their gear & a blockchain on a thumbdrive, and then be kept up to date withing a day by the daily digest.  At $10 per megabyte (per continent, presumedly) that's expensive broadband, but not if shared across 1000+ subscribers.  Even at twice that price it wouldn't be out of sorts for this kind of thing.  Granted, those vendors wouldn't be able to prevent a double spend, but if we were talking low value trades, such protection might be unnecessary.  Those same subscribers then might be able to charge a small fee to individual bitcoin device users for access to their blockchain, thus keeping local devices up to date with just a wifi connection.

[benjamindees]

Nice find.  That's less than $50/day right now.  The site says their data is transmitted hourly.  That's not bad.

Unfortunately the provider seems to be defunct:

However a mystery about the final fate of the original Worldspace satellite radio service still remains because despite the company's very public insolvency and the liquidation of all of its various commercial entities two or more years ago (in 2008/09) the company's Afristar satellite still continues to remain in geostationary orbit to this day (as of the end of the first quarter of 2012) and still continues to broadcast three radio stations:- BBC World Service, WRN 1 and WRN 2.

I wonder whether that pricing is right.  Maybe someone would be interested in buying this case study in order to find out?
http://hbr.org/product/worldspace-satellite-digital-radio-service/an/W11518-PDF-ENG

It sounds cheap, but the info I'm finding makes it seem feasible.  They supposedly had 62 channels, with a final revenue of $14 million and net losses of $170 million.  If each channel were 128 kbps, even with just a single continent, that could earn them $300 million a year at $10/MB.

[MoonShadow]

It sounds cheap, but the info I'm finding makes it seem feasible.  They supposedly had 62 channels, with a final revenue of $14 million and net losses of $170 million.  If each channel were 128 kbps, even with just a single continent, that could earn them $300 million a year at $10/MB.

Only until the rollout of data lines into Africa were to take that work away, but that still could take decades.  Still, I wonder if this is even necessary.  My understanding is that the rollout of cell phone carriers is rather substantial in Africa, despite the difficulties in getting Internet to those carriers.  So the most likely scenario is that cell carriers would sponsor their own version of a BitcoinSpinner server on their local network, with a vendor locked app for their customers.  Less than ideal, but probably still less than $10/mb. 

Yet, this datacasting idea still has legs.  I'd wager that it's no longer $10/mb, and that there is a per-broadcast fee involved, so that daily digests are still less expensive than hourly.  However, hourly would significantly limit the possibility of a local double-spend attack against a subscriber.  Doing the same thing with a more local DRM shortwave station would likley cost more relative to the subscriber base, but might offer the ability to send new blocks closer to their creation.  Either way, a bitcoin datacasting company could stand to make money by using a trick out of the BitcoinSpinner playbook to reduce broadcasted data while also preventing 'free riders' by pre-emptively pruning the broadcasted blocks to include the headers, the merkle tree (perhaps complete, perhaps pruned) and only those transactions that have an address of a subscriber as either an input or output.  This way, subscribers could present the datacasting company with a list of the addresses that they wish to include, and have a standard limit, say 100 addresses.  This would also permit a local 'business association' to get several vendors who only use a couple of addresses apiece (i.e., one for the cash register, one for personal spending, one for a savings account and one for the wife?) and share on downlink equipment & subscriber fees.  The datacasting company could, instead, charge subscriber fees based upon how many addresses it's scanning for; thus an entire town could have one downlink (local Internet service company, perhaps; trying to consolidate their own middle level Internet costs by blocking bitcoin & other p2p ports, but still provide the minimum level of service for customers?) and all the locally relevant data while excluding addresses and transactions that only matter to North America, Japan or Europe.  In this sense, the downlink company becomes a trusted provider, but if any bad things happen the damage would still be limited and identifiable.  Also, even though the digests would be encrypted & a hacker could extract that code from downlink equipment, that digest could still be 'signed' by the downlink company's own address private keys, which no hacker is going to have; so even the malicious things that an attacker could do locally would be limited even with a trusted blockchain provider.

In order to use this method effectively, portable light-client devices that have the ability to present a disconnected vendor's bitcoin client a copy of their own transaction plus their inputs & merkle tree positions would be necessary; but I think that is where we shall end up anyway. 

[notme]

I like the idea, but to me it is screaming CENTRALIZATION OMG!!!

If your broadcast tower is compromised, everyone who uses it is vulnerable.

[MoonShadow]

I like the idea, but to me it is screaming CENTRALIZATION OMG!!!

If your broadcast tower is compromised, everyone who uses it is vulnerable.

Uh, no it's not.  The broadcast tower is just a means of propogation, the security is in both the encryption that the bitcoin datacasting company uses with it's customers and in the cryptographic signing of those same encrypted archive/digests.  If someone gets a copy of those private keys (for signing, not for encrypting of the digest), then everyone who uses it is vulnerable, yes.  This is no different than the security model that bitcoin itself uses, for it's the private keys that matter.  No one can fake being you without them, this is why identities are not necessary under bitcoin and identity theft is practically impossible.

Although it might mean some degree of centralization due to economic concerns, but even the customers of that company aren't locked into that trust relationship, and any of them could catch the broadcasting company if they tried any tricks themselves.

[notme]

I like the idea, but to me it is screaming CENTRALIZATION OMG!!!

If your broadcast tower is compromised, everyone who uses it is vulnerable.

Uh, no it's not.  The broadcast tower is just a means of propogation, the security is in both the encryption that the bitcoin datacasting company uses with it's customers and in the cryptographic signing of those same encrypted archive/digests.  If someone gets a copy of those private keys (for signing, not for encrypting of the digest), then everyone who uses it is vulnerable, yes.  This is no different than the security model that bitcoin itself uses, for it's the private keys that matter.  No one can fake being you without them, this is why identities are not necessary under bitcoin and identity theft is practically impossible.

Except that one key lets you doublespend with everyone who relies on the broadcasting service.  Accessing my keys only hurts me.

[DeathAndTaxes]

Except that one key lets you doublespend with everyone who relies on the broadcasting service.  Accessing my keys only hurts me.

What are you talking about.  Each client validates their own blocks starting from the hardcoded genesis hash in the client.  The method of delivery doesn't need to be secure.  You are aware that a node can give you a bad block right?  The client has already considered that attack vector.

Someone using the service to publish bad blocks would simply find those blocks invalidated by nodes.  At best they could prevent nodes from getting new blocks via this mechanism (service denial) nothing more.

[notme]

Except that one key lets you doublespend with everyone who relies on the broadcasting service.  Accessing my keys only hurts me.

What are you talking about.  Each client validates their own blocks starting from the hardcoded genesis hash in the client.  The method of delivery doesn't need to be secure.  You are aware that a node can give you a bad block right?  The client has already considered that attack vector.

Someone using the service to publish bad blocks would simply find those blocks invalidated by nodes.  At best they could prevent nodes from getting new blocks via this mechanism (service denial) nothing more.

How does the client invalidate the bad blocks unless it has a source of valid blocks?  The whole point here is that this is the only way to get the blockchain to some clients.

[rjk]

Except that one key lets you doublespend with everyone who relies on the broadcasting service.  Accessing my keys only hurts me.

What are you talking about.  Each client validates their own blocks starting from the hardcoded genesis hash in the client.  The method of delivery doesn't need to be secure.  You are aware that a node can give you a bad block right?  The client has already considered that attack vector.

Someone using the service to publish bad blocks would simply find those blocks invalidated by nodes.  At best they could prevent nodes from getting new blocks via this mechanism (service denial) nothing more.

How does the client invalidate the bad blocks unless it has a source of valid blocks?  The whole point here is that this is the only way to get the blockchain to some clients.

Isn't the genesis block and a recent checkpoint hardcoded into every release?