In a related note, how is longest chain resolved when different hashes are used?  Say I have two competing forks with the same number of blocks but different block algorithms, which one is longest?  My understanding in BTC is that difficulty and extra nonce can break all ties, a chain at low difficulty that contains more blocks can still be considered shorter if the cumulative hashing necessary to make it is less then another chain, thus the highest 'work' chain is always considered longest.  If different algorithms are being employed then the ability to cross compare difficulties and work become much harder.

But the number of inputs for the 'hash lottery' is irrelevant if the most recent block is at all an input towards that hash as the attacker will have full control of the result by repeatedly trying different last block solutions until they get the desired result.  The entire block history back to the genesis block could be hashed and it wouldn't mean a thing.

I think it very likely that a specialized piece of hardware like an ASIC would adopt this strategy.  If they submit their first valid block found to the chain then they have a 1/8 chance of being able to mine the next block and a mean wait time of 7 blocks until the lottery once again allows them to mine.  During that time they will be cut out of all mining and their machine will be idle.  So it makes sense to employ that time and hashing power to attempt to take more then 1/8th of all blocks even if it is by continuing to work on creating an reorganization around your own submitted blocks.

Once ASICs can produce blocks 8 times faster then the remaining network average they will by simple Nash equilibrium start to take most blocks without collusion but rather a simple desire to utilize their otherwise unusable hardware and hash potential.  And this is to speak nothing of a malicious attack which are typically willing to lose some money in the process.

I do not understand your point about all 8 hashes needing to be used in each group of 8 blocks, I see nothing in your protocol that enforces this and if that's the case why use a complex lottery and not a simple fixed rotation based on the block height modulus, this has the virtue of both being simple, guaranteeing an equal proportion and allows for absolutely no attack on that part of the coin.

I think that is actually very wise, or the ability to easily change the clock settings to OC the H boards; although that might put Tom in a tough spot with warranties.

I think with the ASIC storm coming it will be down to companies that help your hardware perform better, not another company with comparable hardware.  (Once we get a company that can actually ship demand that is)

Tacotime:  I think I may have thought of an exploit to the hash rotation system.  In your paper you describe the hash of the last 8 blocks being being modulus to derive the hash type of the next block.  The chance for each hash type to be selected will be quite equal if all block are submitted to the network, but if an attacker is willing to check the blocks they mine for what hash they will allow next and continues working on resolving the block until they get a solution that will allow repetition of the same algorithm.  It is thus a simple matter of performing on average X times more hashing (where X is the number of hash types selected amongst by modulus) to create a block-chain that is composed of only one hash algorithm.  As your planning to mix SHA and Scrypt it seems a fairly trivial process for the existing ASIC's to attempt to monopolize the chain in this way, and indeed they all have an economic incentive to due so and no direct collaboration is necessary as it would be the optimum strategy.

The number of prior blocks that are hashed together to create the hash that's modulus will be used is not material in preventing this kind of attack, as the changing of just 1 small part of a hash input will radically change the result and the modulus then gives a perfectly proportional distribution of all the hash options.  It is effectively no more secure then hashing each block to determine the next hash, the only defense is to increase the number of hash types used or to mandate a rotation of hashes by modulus of the block height.

but if an attacker is willing to check the blocks they mine for what hash they will allow next and continues working on resolving the block until they get a solution that will allow repetition of the same algorithm.

The number of prior blocks that are hashed together to create the hash that's modulus will be used is not material in preventing this kind of attack, as the changing of just 1 small part of a hash input will radically change the result and the modulus then gives a perfectly proportional distribution of all the hash options.  It is effectively no more secure then hashing each block to determine the next hash, the only defense is to increase the number of hash types used or to mandate a rotation of hashes by modulus of the block height.

Stopped my 2 gpu's today as well, .0197 per day just isnt gonna cut it.

time to launch UnPrimeCoin (hashes all non prime numbers!!)

Prove it.  

Q: Why does my cudaminer miner tab hang on "Connecting"?
A: Because python's subprocess can not see cudaminer's output no matter what I tweak on it.  If the author of cudaminer releases a new version in the future that has stdout streams compatible with python 2.7, I will fix this.  In the meantime, if you navigate to the "/cudaminer/" directory, you'll see that a batch file is added after you press start that you can check your performance from.

H-board regulator is this part Texas Instruments TPS53355.  You can use it to OC the chips, but on the H-board 16 chips will max this thing out at .8v or so.

you can find the h-boards under DIY.  They are about 350 h-boards open for order in october.  don't snag them all, I need a few more...

/cet

Hey guys, I'm a linux newbie, I tried to compile this and got this error:


I already installed these prior to it: