You don't want a universal waterblock as that won't cool the VRM and VRM temps are the real bottlenecks.

I use DangerDen blocks for 5970s.  They are solid.  They one at the link is designed for a "reference" style 5870.

The EK-FC5870 is the EK model which fits reference style 5870s.  EK is pretty much the cadillac of waterblocks.  

If you have a non-reference card well likely you should seek help from a watercooling forum like overclockers.  Non-reference can be very very very tricky.  Since the PCB can be different you need to pay close attention to make sure the waterblock will fit and there might not be any waterblock which does fit.

hashing algorithms are designed to be "trap door" functions.  That is they are designed to work only one way. 

plaintext -> hash = very easy
plaintext <- hash = impossible (technically the term is infeasible)

When designing and validating a hash function researchers are looking to ensure that given a hash there is clue as to what plaintext generated it, no signature, nothing that narrows down the search space.

If you could do what you suggest then SHA-256 is broken and useless as a cryptographic hash.  Forget Bitcoin it has ramifications for everything from passwords lists to vpn to digital signatures.   The entire global cryptographic community has been looking for flaws in the algorithm for a decade.  I doubt you will find what they haven't.  The cryptographer who breaks SHA-256 will be famous (well at least in crypto-nerd circles ).

True.  If the botnet operator is paranoid he may wish to minimize the connections to the rest of the bitcoin network (to keep the ip of nodes unknown).

In that case take my theory above and modify it so there is a single bitcoind active at one time.  When it detects a new block it notifies the rest of the swarm.  Using a mesh p2p like protocol the "gateway" nodes notifies 50 nodes who notify 50 each, who notify 50 each.  Each node is aware of the current gateway.  When it finds a block it relays it to the gateway who broadcasts it to the bitcoin network.

Really that would be sub optimal but very isolated.  If one takes the gateway down the operator promotes another node to the gateway.  By keeping the bulk of the swam unknown and with no direct communication with bitcoin network it is opaque and dark.

If the botnet has 1.8 million nodes and only one is active as the gateway at a time shutting it down would be tough.  Even if the ISP did shut it down.  Well there are 1,799,999 more nodes to go.

Likely the next question is "If D&T is right, why doesnt' the gateway simply include txs like any other node would?".  A little thinking I think will reveal a very obvious reason.

But he can't.  If the majority of miners include 10 free tx on the "required list" for the next block then "mystery" (or any miner or pool) is required to include them or have that block invalidated by other miners.  He can't even exclude free tx without taking a risk his block will be orphaned.

Miners already have limited pricing power due to the fact that mining is a commodity business this ensures they have no independent pricing.  If clients know the list used by majority of miners includes free tx there is little reason for them to include a fee.

$15K in GPUs?

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.  

Nonsense.  The blockheader is tiny.  99%+ of the blockchain is transactions.  The number of blocks is based on time.  Empty or not the block chain will grow by (300 bytes) * 6 * 24 * 365 bytes per year = 15MB annually  (roughly double that if you include the only requires tx - the coinbase).  

That cost is fixed.  The only thing that would change that is a avg block time other than 10 minutes.

Transactions make up the vast majority of the blockchain.  This is why downloading blockchain is fast initially (first 50,000 blocks downloads within minutes but then it slows down).  Those blocks are mostly empty (yup even Satoshi mined empty blocks).


No botnet or even conventional TH/s farm would be running the standard client.  Especially not a farm (conventional or not) which is ignoring tx.

Solid.

BTW That model is made by Seasonic for XFX.  XFX just uses a slightly different fan and fan controller.  The rest of the differences are just cosmetic.  I have the Seasonic version and it is "solid".  It can handle anything you throw at it up to and including 4x5970s.  Runs cool even at 85%+ load.

It is what is powering my watercooled rig (including the pump):
https://bitcointalk.org/index.php?topic=66606.msg773594#msg773594

I have been running some of my rigs @ 1.00V.  Nice drop in power consumption.  As FPGA miners start making the price/difficulty ratio to fall (network gets more efficient) I think the 5970s are a great card because you can keep dropping voltage (and clocks) to boost efficiency and expand their longevity.

The bad news is that you make less gross hashes the good news is that you can keep mining even with really old hardware.

Ahh smart.  

So if I am understanding right it is (to update my high level flow):
0) p2pool detects "inv" message on bitcoin port.
1) p2ool uses "getmemorypool" bitcoind RPC call to get block components.
2) p2pool generates coinbase transaction (reward split) from current sharechain
3) p2pool generates merkle tree (combining tx from bitcoind w/ coinbase from sharechain).
4) p2pool issues block headers to miners as they request work via getwork call.

One last "last question".
inv messages can contains things objects other than blocks (like tx broadcast from other nodes).  
Does p2pool only make getmemorypool request based on inv messages about blocks?
Is so that means the "work" (i.e. set of tx) is fixed until the next block right? (No picking up intra-block tx as they are broadcast).

And yeah I could have look it all up in the code but I got a lot on my plate right now so thank you for explaining it all (and providing cites).

Well in that case you might be able to get by with a "lesser" unit.  Still good 80Plus-Gold units often are well built (beefy heatsinks, higher end caps, etc) and come with 5-7 year warranties.  Higher efficiency also means the internal temp of PSU is lower and that means (theoretically) better stability and longevity.  They also tend to hold their value well.  Even used ones sell for good amounts.  Personally (just my opinion) the PSU is the heart of any rig and I don't want to take any changes with the heart.  Power problems can often be subtle and hard to diagnose. 

Still others have had good luck with lesser units.  If you have cheap power and/or using power for heat it is less important.  I have moderately priced power and long hot summers.  80Plus-Gold Seasonic units all the way.

One last question(s)?

How does p2pool get updated work? 
The Bitcoind RPC doesn't support asyncronous calls does it (i.e bitcoind just sends work on a block change)?
Does it just continually poll bitcoind and check for changes?  Every x seconds?

1 BTC sent (I figured a bounty would get more detailed answers then just "yeah" or "I think so" )
c9cd269fe070ac3df98c23c965637910916e5e5223da6e8370afa04c6fde2b81

If this is a dedicated mining rig I would drop it to a Sempron single core.  More cores just mean more wasted wattage.

2GB is enough but 4GB is cheap.  You did he right thing getting a single stick.  Memory consumption is per bank.  So 4GBx1 is less wattage than 2GBx2.

Unless you have free power I would spend a little more (take savings from cheaper CPU) on PSU and get a better brand 80Plus unit.  I would go with Gold but if you can't stomach the cost at least 80Plus-Bronze.

Remember FPGA have higher efficiency already you wan't the most efficient rig possible.  Wasted electricity =  higher operating cost.

In a dumb miner - pool model the fact that the miner doesn't do the workload doesn't mean the workload doesn't exist.

One getwork is ~400 bytes.  Some have speculated mystery has 1.8 million nodes.  To use a traditional full pool server the bandwidth requirements alone would be 5.7Gb and 1.8 million connects every long poll.  Say he staggered those getworks to supply all nodes with work over a 10 second period (less revenue btw).  You are still talking about almost 200K simultaneous connections, 750Mbps, and enough computing power to generate 200K block headers a second.

If you want more insight ask Tycho what kind of load even small botnets do to a pool server.  Now with enough computing power (we are talking a dozen or so high end load balanced servers on a 1 Gbps connection) a 1.8 million node botnet "could" operate in a pool-miner model.  However now compare all that cost vs the incremental reward of .... ready for it ....about 2 cents per block.

To it is my right to charge what I consider fair but if I do you will exclude the block and I lose everything.  Honestly you think miner's will support this.

It would be like saying:
You can open a restaurant and charge what you want but if 5 people are waiting and you don't feed at least 25% of them you will be shutdown.  Oh an BTW some of them want to eat for free and some want to eat for a penny.  But sure you can charge what you want.

No dice.  Any system that forces me as a miner to use MY HASHPOWER purchased with MY CAPITAL and running on MY ELECTRICITY to include fee and "essentially free" transactions is a non-starter.  The "solution" is worse than the problem.


You "encourage me" but at the same time advocate a system which would orphan my blocks if I do what you are encouraging.  Thanks for your encouragement. 

Even a 1 satoshi minimum would get people to at least start paying fees, and pave the road for the future where free/1-satoshi transactions are slow (just a few miners supporting them) and reasonable fees are required for fast processing.  It's probably helping your goals on the whole.

I am not advocating that.  I am adovcating I set the minimum fee for my hashing power ONLY with no changes to the protocol and you are advocating orphaning my blocks if I do that.

Escrow address as requested:

1SAFECAGn5HnJ8ZMF8fWPn3aF6S3fSj3k

(from vanitygen made on offline computer to a paper wallet)

Right but the point being that is an unlikely scenario.

Which is why I said you are RIGHT but it is irrelevant.  The most likely scenario is Moore's law hold, there is no global war wiping out technological progress and your encryption must be able to handle 1 million fold increase in computing power over the next three decades.

Although I disagree with foggyb larger view and I think Moore's law (or more correctly we are interested in Koomey's law as it relates to encryption) is good for at least three or four decades and possibly a century he likely is right about war.

Since WWII at least in the US (and I would imagine around the world) military tactics have changed.  The goal is no longer to secure territory, land, strategic points ("take the hill") it is to utterly dominate the enemy and destroy both their ability to wage war (kill troops instead of taking land) and their ability to finance the war.

WWII defenses and offenses were fairly matched.  B-52 bombers for example could level a factory but they often missed and routinely bombers would be destroyed enroute.  Since WWII the destructive capacity of offensive weapons has improved by magnitudes but defensive systems haven't.

In a modern global war of full spectrum dominance you simply couldn't defend your industrial assets.  Stealth bombers, high speed drones, ground hugging cruise missiles, bunker buster ordinances, ballistic missiles, long range pinpoint accurate field artillery, etc would rapidly overwhelm any defensive systems.

How many cruise missiles can a Intel FAB take before it is a $20B pile of rubble?  How many stealth bomber runs can a nuclear power plant take before it is molten radioactive slag and there is no power to run your $20B Silicon chip FAB?

The most effective way to "win" is destroy the enemies ability to wage war so both (all?) sides will.

The good news is all the nations capable of waging such a war have nuclear weapons and unstoppable delivery systems.  Any such war would inevitably escalate to nuclear force.  Either pre-emptively to "end the war before it starts" or defensively as one side starts to lose and sees nuclear weapons as the only way to regain a fighting chance.  Nuclear escalation wouldn't stop (when 1 million of your citizens die as a leader you will strike back with similar force).  Limited "strategic exchanges" would escalate to "counterforce" (google it) strikes and eventually full scale "countervalue" strikes. 

So yes when 90%+ of human race is wiped out and technological progress is pushed backwards 200 or so years as humans cling to a shattered and poisoned planet then foggy is likely right Moore's law won't continue and your encrypted file is likely safe.


Still now that we are WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYYYYYYYYYYYYYYYYYYYYYY off topic.

Hoping for a nuclear war (or any other improbable scenario) to keep your encrypted secrets safe really doesn't have much value.   It would be like not getting fire insurance, counting on the fact that the day your house catches fire it will be raining ... hard.

Any estimate for the long term strength of a cipher should be based on the most plausible and likely scenario.  That scenario is that Moore's law (or more accurately Koomey's law) will continue for next 30+ years.  So if your secret must remain protected even 30 year from now you should assume computers will eventually have 1 million times as much performance per watt (30 years at doubling ever 18 months).  When choosing a cipher strength that should be your target.

Now if your assumption is WRONG well most likely it is wrong on the short side (nuclear war, lack of demand for faster chips, technological brick wall) and your file is still safe.  On the other hand if your assume Moore's law won't hold and it does well you are fracked.

It is all about being conservative.

As someone who was an outspoken (and loud) critic of BFL I am convinced they aren't a "scam".  They masively overestimated their specs and timelines.  They also seem ill equipped to handle the non-tech portions of the demand they are facing.

IMHO the only real risks dealing w/ BFL are:
a) time risk.  800 MH/s miner earns ~15 BTC per month.  4 month delay = 60 BTC in lost revenue.
b) warranty risk.  If new orders take 12-16 weeks then how long will RMA take.
c) solvency risk. If company had a huge financial setback (say 1000 singles died under warranty) could they absorb that and continue to operate

basically the risks are the same as dealing with any small business where demand way outstrips productive capacity.  It would be smart for BFL to hire an business student (for next to nothing) to handle non-tech tasks like emails, order processing, releasing company statements, etc.

Psst BFL there is 10% unemployment right now (20%+ for college age workers), labor is cheap.

Nobody?  

OK how about 1 BTC bounty
a) verify and/or correct the above execution flow above.
b) provide filename and line # of code (p2pool github) where p2pool pulls works from bitcoind.
c) provide fielname and line # of code (p2pool github) where p2pool modifies work from bitcoind to include coinbase reward split.