AES PoW function and benchmarks

[Harryman]

The goal of proof of work is to have some verifiable cost function. If all PoW algorithms eventually go to ASICs there a huge cost advantage meaning most users would have to set up a payment channel with a PoW provider to purchase hashes, which greatly increases the friction and complexity of operating a node on the #D network.

@Miwcryptocurrency had a brilliant idea to use AES as a PoW function since everything already has a tiny ASIC pipeline for AES and it's all standardized.

The question is how similar is the efficiency and speed of various computing architectures. We need to create benchmarks across a couple different mobile phone process, low and high power x86 processors and maybe a raspberry pi for shits and giggles. Would be good to also compare some processors which don't support AES-NI.

[Harryman]

Offer: 800 tokens, 30 day $1 option on all tokens

[Harryman]

I've been doing a lot research on the related key attacks and AES hashing. Instead of passing nonces we pass keys. However those keys are always public. From my understanding so far, wouldn't anyone be able, without too much computation, check to see if the key is related to one previously used for that message. Furthermore even if vulnerable to that attack, the attack still costs something. However if you implement the hashing function to take advantage of that if it's computationally cheap enough to make sense everyone still has a level playing field if these attacks mainly depend on the ASIC hardware. We aren't looking for collision resistance since the signing of the blocks is what insures their integrity. In the presence in collisions or cost reductions to generate specific cypher text it is just factored into the cost to generate a certain difficulty as long as the rate of collisions or the magnitude of cost reduction is widely known.

Do you see any problems with this reasoning? @MiWCryptoCurrency

[Harryman]

Another possible construction is to fix the key by using a hash of the previous block as a fixed key. Then you have an external nonce concatenated to the next block's signature, encrypt that rotating the nonce until difficulty target of the cipher text is reached. These nonces can then be passed around as the proof of work.

This could be attacked by grinding the previous block. The cheapest way of doing this would be to rotate the op field, however this causes problems with others understanding the block structure, flagging this chain as a spammer since op doesn't match their data definition. The other way which doesn't break the protocol is using a dead end merkle node near the top of the tree, allowing the attacker to change the merkle root without recomputing too many hashes to rotate the merkle root. They then just sign every rotation of the merkle root. However, this grinding attack should be more costly than the gains of choosing a related key. I'm not certain of this but I think for proof of resource/work it should be a safe assumption.

I think I'll write a new hash function using this construction,

I believe it is sound please point out any flaws. Offer: 100 tokens, 30 day option $1 per token