Pages:
Author

Topic: how do pools work? / why are pools not a threat? - page 2. (Read 10075 times)

legendary
Activity: 1862
Merit: 1114
WalletScrutiny.com
Hi

as to my understanding, bitCoins success is based on the peer to peer structure and any entity owning 50% of computational power could cheat on the rest or stop the show for all. While pools are no threat in the latter sense as miners are no zombies tied to them against their will, I come to understand that pools really pose a threat in the former sense.

(Yes I know this must have been discussed somewhere in depth but i could not find it. It's mostly annoying me that all people suggest to join a pool based on the kh or Gh they do.)

My understanding of "mining" was that the miner may add into a block he creates *one* transaction for the reward and as many other transactions as he likes taken from all 0conf transaction that he sees. (input data) he then brute force tries adding salt (never read that but that's my conclusion) and if hash(prior block + input + time + ... + salt) < x he sends it out to the world. fool proof. simple. great.

As in slush pool's sticky post it is made very clear that in a pool situation it is not the miner who decides what gets into the block but the pool delegates the work to the miners. I read it such that not only does the pool dictate the reward (would make sense) but also transactions, time, prior block and the salt to try out.

My questions:
Am I about right in my analysis?
Does the miner know when it found a block?
Does the miner promote its finding only to the pool?
Does the miner do plausibility checks for the timestamp at least?
What if it is not plausible?
Do pools keep an eye on each other by comparing block chain data ...?

Thanx for pointers and answers ...
Pages:
Jump to: