Post
Topic
Board Development & Technical Discussion
Re: Miners that refuse to include transactions are becoming a problem
by
DeathAndTaxes
on 24/03/2012, 18:25:23 UTC
The getwork size is the same, whether transactions are included or not.  The quantity of getworks is the same too, whether or not transactions are included.

If your calculations prove anything, then that its not a botnet.  "Because its too difficult to manage even a moderade sized botnet (ask Tycho)" - your own words paraphrased.

The fact that transactions are not included does not add one single jota of support towards/against the botnet theory.


No please listen.  USING A POOL SERVER WITH A BOTNET IS NOT VIABLE DUE TO THE COST OF GETWORKS.  It was your "theory" that the nodes not being able to process tx was bogus because most miners don't.  However conventional pool miners need a pool.  I was just showing the math that current tx fees come nowhere near the cost needed to support a pool.  They don't for a botnet, they don't even for a small conventional pool.

The nodes likely are running a modified stipped down version of bitcoind.  It doesn't keep the blockchain, it doesn't need a db, it doesn't even need logs.  It simply connects to peers and looks for inv messages.  When inv message occurs the nodes internally use the last block hash, current time, no tx, the simplified coinbase, build a merkle tree consisting of 1 tx, build block header and start hashing.  Likely not all nodes are even running this.  To isolate the botnet only a "few" (as a % of total nodes) would need connections to bitcoin network.  They could rely new block notifications in p2p fashion to the rest of the swarm.

Essentially they are listen ony nodes.  They only broadcast to bitcoin network when they find a block.  Which if the avg node is 10 MH/s would only be once every 20 years (per 10 MH/s node).

Or that is how I would do it.