Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: MoonShadow on December 02, 2010, 05:13:00 AM



Title: Datacasting the blockchain
Post by: MoonShadow on December 02, 2010, 05:13:00 AM
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.


Title: Re: Datacasting the blockchain
Post by: RHorning on December 02, 2010, 05:43:06 AM
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.


Title: Re: Datacasting the blockchain
Post by: MoonShadow on December 02, 2010, 06:02:48 AM
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.


Title: Re: Datacasting the blockchain
Post by: da2ce7 on December 03, 2010, 01:00:17 AM
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.


Title: Re: Datacasting the blockchain
Post by: jgarzik on December 03, 2010, 01:12:26 AM
Post blocks to alt.bitcoin :)


Title: Re: Datacasting the blockchain
Post by: MoonShadow on December 03, 2010, 01:55:39 AM
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.


Title: Re: Datacasting the blockchain
Post by: MoonShadow on December 03, 2010, 01:58:13 AM
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.


Title: Re: Datacasting the blockchain
Post by: theymos on December 03, 2010, 02:17:16 AM
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.


Title: Re: Datacasting the blockchain
Post by: appamatto on December 16, 2010, 05:14:10 AM
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.


Title: Re: Datacasting the blockchain
Post by: MoonShadow on December 16, 2010, 05:57:29 AM
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.


Title: Re: Datacasting the blockchain
Post by: appamatto on December 16, 2010, 05:59:19 AM
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)


Title: Re: Datacasting the blockchain
Post by: MoonShadow on April 15, 2012, 07:47:36 PM
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.


Title: Re: Datacasting the blockchain
Post by: benjamindees on April 16, 2012, 06:02:46 AM
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:

Quote from: wikipedia
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.


Title: Re: Datacasting the blockchain
Post by: MoonShadow on April 16, 2012, 01:49:50 PM


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. 


Title: Re: Datacasting the blockchain
Post by: notme on April 16, 2012, 03:11:54 PM
I like the idea, but to me it is screaming CENTRALIZATION OMG!!!

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


Title: Re: Datacasting the blockchain
Post by: MoonShadow on April 16, 2012, 09:51:14 PM
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.


Title: Re: Datacasting the blockchain
Post by: notme on April 16, 2012, 09:53:09 PM
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.


Title: Re: Datacasting the blockchain
Post by: DeathAndTaxes on April 16, 2012, 09:58:05 PM
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.


Title: Re: Datacasting the blockchain
Post by: notme on April 16, 2012, 10:00:04 PM
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.


Title: Re: Datacasting the blockchain
Post by: rjk on April 16, 2012, 10:01:08 PM
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?


Title: Re: Datacasting the blockchain
Post by: MoonShadow on April 16, 2012, 10:07:21 PM
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.

It would be a high value key, yes; but don't assume that it's one that would be easy to aquire.  Yes, subscribers would generally be trusting the security model of the company they contract with, but if anything happens, that trust dies and another datacasting company takes away their business or the subscribers get their own Internet feed.  It's not vendor locked.


Title: Re: Datacasting the blockchain
Post by: notme on April 16, 2012, 10:10:09 PM
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.

It would be a high value key, yes; but don't assume that it's one that would be easy to aquire.  Yes, subscribers would generally be trusting the security model of the company they contract with, but if anything happens, that trust dies and another datacasting company takes away their business or the subscribers get their own Internet feed.  It's not vendor locked.

Thank you for acknowledging the limitations.  I will not be subscribing to any such datacasting company, but I'm sure others are less careful than me.  Carry on.


Title: Re: Datacasting the blockchain
Post by: MoonShadow on April 16, 2012, 10:17:07 PM
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?

Yes, but his complaint is valid.  A client for such a subscriber would have to be modified to accept the encrypted & signed block digest from the datacasting company as both trusted and authoritive.  Such clients could still get such data from other clients that they come into wifi range of, such as customers, but in order to invalidate the trusted block, the subscriber's client would have to have a complete copy of all of the blockchain.  Right now, that's not much of a problem; but by the time that vendors in Africa are using a service such as this in order to transact daily in bitcoin the block limit is going to be huge and a full copy from any source is going to be like drinking from a fire hose.  There already exists an overlay network (Stratum)being developed in order to permit light(er) clients to directly utilize the bitcoin protocol without needing a complete copy of the blockchain, but in every case some level of additional trust is required of the operator of the server that your client connects to in order to update it's local copy of it's own address inputs.  BitcoinSpinner for Android uses a similar client/server trust model in order to allow an Android client to quickly assess what it's own balance is without needing to download and verify it's own blockchain.  Local complete blockchains & verfication will always be available to anyone who wishes that level of security, but only banks and the most paranoid of consumers are likely to continue doing so when the size of the average block approaches 10 Gigs every 10 minutes.


Title: Re: Datacasting the blockchain
Post by: DeathAndTaxes on April 16, 2012, 10:39:12 PM
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.

All clients have the starting source ... the genesis block.   The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0.   As such all full-clients must include the genesis block.  From there every node can validate every tx from block #1 all the way to current block.   As indicated above clients may also include hardcoded checkpoints.

Nodes are NOT secure.  They are inherently insecure.  You have no idea how dishonest your fellow "peer" connections are.  Hell they could all be the same attacker.  As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block.

A broadcast system for blocks wouldn't be any different.


Title: Re: Datacasting the blockchain
Post by: MoonShadow on April 16, 2012, 10:49:43 PM

A broadcast system for blocks wouldn't be any different.


Excepting that there is only one source for the blockchain, no it wouldn't.  Part of the normal client's security model involves getting blocks from differnet sources, and validating them so that they all fit into the same blockchain.  That's where the trust of a datacasting company would come in, for it's possible that such a company that turned to the dark side, (or a hacker gets ahold of the private keys in order to fake being the company) then it's possible for the attacker to send faked blocks to a high value target that also happens to be a costumer.  In this way, the attacker could theoretically create fake blocks that permits himself to send himself his own bitcoins, and then spend them again at the attacked vendor.  Sort of like a delayed double spend attack.  Actually, this might be possible regardless, so I doubt that anyone selling high value items for bitcoin (say a brand new car) is going to be satisfied with just a couple of block verifications.  Odds are high that such a vendor could justify an Internet downlink of their own right, and that buying in bitcoin is going to both require personal identification (ever tried to buy a car for cash at a dealership?  It's not cash an carry) and at least three verified blocks before you get to leave with the new car.  This datacasting idea is more about the little vendors.  Like the guys who sell hot dogs at the street corner downtown.  He's more likely to use BitcoinSpinner on an Android than a datacasting company, but the concept is similar.  He's not going to be running a full client under his hot dog tray paying 4G data rates to keep up.  Eventually even 4G isn't going to be able to keep up anyway.


Title: Re: Datacasting the blockchain
Post by: notme on April 16, 2012, 11:07:38 PM
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.

All clients have the starting source ... the genesis block.   The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0.   As such all full-clients must include the genesis block.  From there every node can validate every tx from block #1 all the way to current block.   As indicated above clients may also include hardcoded checkpoints.

Nodes are NOT secure.  They are inherently insecure.  You have no idea how dishonest your fellow "peer" connections are.  Hell they could all be the same attacker.  As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block.

A broadcast system for blocks wouldn't be any different.


Right, but that doesn't help at all with new blocks, which is where any attack would play out ::).


Title: Re: Datacasting the blockchain
Post by: DeathAndTaxes on April 16, 2012, 11:43:30 PM
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.

All clients have the starting source ... the genesis block.   The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0.   As such all full-clients must include the genesis block.  From there every node can validate every tx from block #1 all the way to current block.   As indicated above clients may also include hardcoded checkpoints.

Nodes are NOT secure.  They are inherently insecure.  You have no idea how dishonest your fellow "peer" connections are.  Hell they could all be the same attacker.  As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block.

A broadcast system for blocks wouldn't be any different.


Right, but that doesn't help at all with new blocks, which is where any attack would play out ::).

New block is simply the tail of the block chain.  Right now a peer node just gave you a block how do you make sure it is valid?


Title: Re: Datacasting the blockchain
Post by: notme on April 16, 2012, 11:48:59 PM
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.

All clients have the starting source ... the genesis block.   The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0.   As such all full-clients must include the genesis block.  From there every node can validate every tx from block #1 all the way to current block.   As indicated above clients may also include hardcoded checkpoints.

Nodes are NOT secure.  They are inherently insecure.  You have no idea how dishonest your fellow "peer" connections are.  Hell they could all be the same attacker.  As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block.

A broadcast system for blocks wouldn't be any different.


Right, but that doesn't help at all with new blocks, which is where any attack would play out ::).

New block is simply the tail of the block chain.  Right now a peer node just gave you a block how do you make sure it is valid?

Check blockexplorer and blockchain.info from systems on multiple ISPs.


Title: Re: Datacasting the blockchain
Post by: rjk on April 17, 2012, 12:14:01 AM
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.

All clients have the starting source ... the genesis block.   The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0.   As such all full-clients must include the genesis block.  From there every node can validate every tx from block #1 all the way to current block.   As indicated above clients may also include hardcoded checkpoints.

Nodes are NOT secure.  They are inherently insecure.  You have no idea how dishonest your fellow "peer" connections are.  Hell they could all be the same attacker.  As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block.

A broadcast system for blocks wouldn't be any different.


Right, but that doesn't help at all with new blocks, which is where any attack would play out ::).

New block is simply the tail of the block chain.  Right now a peer node just gave you a block how do you make sure it is valid?

Check blockexplorer and blockchain.info from systems on multiple ISPs.
Why? If you have an existing, valid blockchain, and you want to check all additional blocks that are sent to you, what is wrong with how it is done now? Do you even know how it is done now? I doubt it.


Title: Re: Datacasting the blockchain
Post by: notme on April 17, 2012, 12:17:24 AM
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.

All clients have the starting source ... the genesis block.   The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0.   As such all full-clients must include the genesis block.  From there every node can validate every tx from block #1 all the way to current block.   As indicated above clients may also include hardcoded checkpoints.

Nodes are NOT secure.  They are inherently insecure.  You have no idea how dishonest your fellow "peer" connections are.  Hell they could all be the same attacker.  As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block.

A broadcast system for blocks wouldn't be any different.


Right, but that doesn't help at all with new blocks, which is where any attack would play out ::).

New block is simply the tail of the block chain.  Right now a peer node just gave you a block how do you make sure it is valid?

Check blockexplorer and blockchain.info from systems on multiple ISPs.
Why? If you have an existing, valid blockchain, and you want to check all additional blocks that are sent to you, what is wrong with how it is done now? Do you even know how it is done now? I doubt it.

Why the hostility?  I do know how it is done.  I'm just remembering a previous conversation with DeathAndTaxes where he brought up the case of having all your connections controlled by an attacker.  But thanks for butting in your your rudeness.


Title: Re: Datacasting the blockchain
Post by: rjk on April 17, 2012, 12:23:15 AM
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.

All clients have the starting source ... the genesis block.   The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0.   As such all full-clients must include the genesis block.  From there every node can validate every tx from block #1 all the way to current block.   As indicated above clients may also include hardcoded checkpoints.

Nodes are NOT secure.  They are inherently insecure.  You have no idea how dishonest your fellow "peer" connections are.  Hell they could all be the same attacker.  As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block.

A broadcast system for blocks wouldn't be any different.


Right, but that doesn't help at all with new blocks, which is where any attack would play out ::).

New block is simply the tail of the block chain.  Right now a peer node just gave you a block how do you make sure it is valid?

Check blockexplorer and blockchain.info from systems on multiple ISPs.
Why? If you have an existing, valid blockchain, and you want to check all additional blocks that are sent to you, what is wrong with how it is done now? Do you even know how it is done now? I doubt it.

Why the hostility?  I do know how it is done.  I'm just remembering a previous conversation with DeathAndTaxes where he brought up the case of having all your connections controlled by an attacker.  But thanks for butting in your your rudeness.
The only way that could possibly work is if the "hostile" connection could generate blocks of the current difficulty and feed them to the clients. We are assuming that you already have a valid, trusted copy of the blockchain, remember? And even if you re-download it from scratch, you would have to be running a hacked version with no built-in checkpoints or genesis block.


Title: Re: Datacasting the blockchain
Post by: notme on April 17, 2012, 12:26:54 AM
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.

All clients have the starting source ... the genesis block.   The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0.   As such all full-clients must include the genesis block.  From there every node can validate every tx from block #1 all the way to current block.   As indicated above clients may also include hardcoded checkpoints.

Nodes are NOT secure.  They are inherently insecure.  You have no idea how dishonest your fellow "peer" connections are.  Hell they could all be the same attacker.  As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block.

A broadcast system for blocks wouldn't be any different.


Right, but that doesn't help at all with new blocks, which is where any attack would play out ::).

New block is simply the tail of the block chain.  Right now a peer node just gave you a block how do you make sure it is valid?

Check blockexplorer and blockchain.info from systems on multiple ISPs.
Why? If you have an existing, valid blockchain, and you want to check all additional blocks that are sent to you, what is wrong with how it is done now? Do you even know how it is done now? I doubt it.

Why the hostility?  I do know how it is done.  I'm just remembering a previous conversation with DeathAndTaxes where he brought up the case of having all your connections controlled by an attacker.  But thanks for butting in your your rudeness.
The only way that could possibly work is if the "hostile" connection could generate blocks of the current difficulty and feed them to the clients.

Yes, that's the exact situation he was talking about in our other conversation.


Title: Re: Datacasting the blockchain
Post by: rjk on April 17, 2012, 12:32:42 AM
The only way that could possibly work is if the "hostile" connection could generate blocks of the current difficulty and feed them to the clients.

Yes, that's the exact situation he was talking about in our other conversation.
It would become pretty damn obvious what was going on when the client didn't get their current block in the average time of 10 minutes each, but instead was getting them hours or days apart because the hostile connection owner had to generate them himself. After about a week of slow blocks, yes, you would definitely check an external source, but how do you know that the external source isn't being hijacked? dun dun dun...

I think you are putting too much stock in an "zomg every node is controlled by a single attacker" situation. It is implausible at best.


Title: Re: Datacasting the blockchain
Post by: notme on April 17, 2012, 12:35:54 AM
The only way that could possibly work is if the "hostile" connection could generate blocks of the current difficulty and feed them to the clients.

Yes, that's the exact situation he was talking about in our other conversation.
It would become pretty damn obvious what was going on when the client didn't get their current block in the average time of 10 minutes each, but instead was getting them hours or days apart because the hostile connection owner had to generate them himself. After about a week of slow blocks, yes, you would definitely check an external source, but how do you know that the external source isn't being hijacked? dun dun dun...

I think you are putting too much stock in an "zomg every node is controlled by a single attacker" situation. It is implausible at best.

Like I already said twice, this was a situation D&T has brought up in the past, so I'm addressing him.  Yes, it is implausible.

As for the external source being hijacked, that's why I check two sources twice using two different connection providers (incase I'm dns hijacked on one).


Title: Re: Datacasting the blockchain
Post by: Stephen Gornick on April 17, 2012, 10:12:07 PM
I check two sources twice using two different connection providers (incase I'm dns hijacked on one).

The check to verify could require only a few bytes if connecting to a trusted service.

The client could even have a special mode where the datacasting source is the only node normally used to get the block data but the rest of the client keeps the same peer discovery and block verification as what everyone else uses.


Title: Re: Datacasting the blockchain
Post by: seniorlancelot on January 14, 2018, 05:25:21 PM
 Blockchain  (https://freedman.club/en/blockchain-pomogaet-kompaniyam-virasti-v-cene/) helps companies grow in price. This week, the publicly registered company Ameri Holdings has added Blockchain technology to its business model


Title: Re: Datacasting the blockchain
Post by: FeArZ on March 01, 2018, 05:18:41 AM
It would be a high esteem key, yes; yet don't accept that it's one that would be anything but difficult to acquire. Truly, endorsers would for the most part be believing the security model of the organization they contract with, yet in the event that anything happens, that trust bites the dust and another information throwing organization takes away their business or the supporters get their own Internet encourage. It's not seller bolted.


Title: Re: Datacasting the blockchain
Post by: AfanasjevIur on March 14, 2018, 05:54:44 PM
All cranes kriptovalyut obveshany advertising.Many users mistakenly click on the wrong way By thus giving to earn in branded advertising. As a result of this income, payments are made as well as the production of crypto-currency is possible through mining.


Title: Re: Datacasting the blockchain
Post by: piratcoin on March 28, 2018, 11:26:00 AM
It would be a high esteem key, yes; nonetheless do not settle for that it's one that will be something however tough to amass. Truly, endorsers would for the foremost half be basic cognitive process the protection model of the organization they contract with, nonetheless within the event that something happens, that trust bites the mud and another data throwing organization takes away their business or the supporters get their own web encourage. it isn't merchandiser latched.


Title: Re: Datacasting the blockchain
Post by: cryptorelax on September 12, 2018, 07:25:22 PM
The Credits blockchain platform and computer manufacturer Lenovo New Vision Technology will start working together on the development of the Internet of things


Title: Re: Datacasting the blockchain
Post by: cryptorelax on September 13, 2018, 08:04:51 PM
Distributed Ledger technology (DLT) could create $ 1 trillion in trade over the next decade, according to a joint report by Bain & Company and the world economic forum.


Title: Online Classes are gonna be launched
Post by: emilyzeo on November 08, 2018, 03:36:52 PM

Hi there :)
Emily here....I am a crypto lover. I want to share a post here related to the crypto world.
Top-ranked institutes and courses of the blockchain:
https://medium.com/@sk6140434/in-my-world-the-top-ranked-institutes-and-courses-of-blockchain-79cb256d8719
It is amazing for the crypto lovers. Bit.college is an amazing institute of blockchain technology which is going to launch its first online classes on 1st December. Everybody who wants to learn about the blockchain technology, I invite to come and learn about the blockchain technology. Believe me, u will learn a lot.
Website: www.bit.college


Title: what is blockchain
Post by: syedelu on November 14, 2018, 08:20:02 AM
Blockchains are incredibly popular nowadays.
what is a blockchain?

as the name indicates, a blockchain is a chain of blocks that contain information.

this technique was originally described in 1991 by a group of researchers.

then it was originally intended to timestamp digital documents so that it’s not possible to back them or to tamper with them. almost like a notary.

however, it went by mostly unused until it was adapted by Satoshi Nakamoto in 2009 to create the digital cryptocurrency bitcoin.

a blockchain is distributed ledger that is completely open to anyone.

they have an interesting property

once some data has been recorded inside a blockchain, it becomes very difficult to change it.
find step by step knowledge about blockchain here:- http://blogparagon.com/what-is-blockchain/