preambleWhat is proof of work, and why should i care?From the bitcoin wiki:For a block to be valid it must hash to a value less than the current target; this means that each block indicates that work has been done generating it. Each block contains the hash of the preceding block, thus each block has a chain of blocks that together contain a large amount of work. Changing a block (which can only be done by making a new block containing the same predecessor) requires regenerating all successors and redoing the work they contain. This protects the block chain from tampering.
The most widely used proof-of-work scheme is SHA-256, which was introduced by Bitcoin. Some other hashing algorithms that are used for proof-of-work include scrypt, Blake-256, CryptoNight,[1] HEFTY1, Quark, SHA-3, scrypt-jane, scrypt-n, and combinations.
The reality:the checksum method only validates that a block is a valid sha256 hash less than or equal to the target described in the equation. this means, that at the hashing level there are nothing to verify how a hash was produced, only that it confirms all previous work and contains valid transaction data, satisfying the "Proof of Work" concept.
What does this mean for altcoins?Typically, altcoins rely on hashing blocks using a different algorithm, then converting the hashed block to a sha256 unsigned integer.
This means that an attacker only has to have enough Sha-256 asics to account for 51% or more of the network hashrate and a modified client designed to hash with sha256 instead of all of these algorithm's that have been piggy backed on top of sha256.
What about chained hashing?Chained hashing provides only the illusion of security, or security through obscurity as we like to call it. this collection of algorithms:
Here's a case study:
Logicoin:
https://github.com/Logicoin/logicoin/blob/master/src/hash.hnow, lets look at bitcoin:
https://github.com/bitcoin/bitcoin/blob/master/src/hash.hAs you can see, these alternative hashing implementations are reliant on conversion back to uint256 then hashed as sha256, meaning that the entire hashing process can simply be shortcircuited back to sha256, bypassing these algorithms entirely, making the coin mineable by sha256 asics.
Additionally, the flaws with chained hashing algorithm's do not stop here. With WildKeccak derivates such as Boolberry and JackpotCoin, it is possible to short circuit the internal switch statements that chooses which hash to use in a given round. An attacker could modify his client to use the weakest, fastest hash every round, producing a clear advantage for his miners.
Additionally, this exposes a flaw in every coin other than bitcoin, and there in also reiterates the true strength of bitcoin, which relies solely on the strength of the sha256 algorithm and the proof of work concept to secure the blockchain. If you are looking for innovation in altcoins, it simply doesn't exist in a true form to date.
ConclusionHow can this issue be addressed?Through mathematics, plain and simple. If you want to add additional hashing algorithms to bitcoin, you need to modify proof of work with additional checksum algorithms to confirm a given hash satisfies the specifications of your hashing algorithm. With chained hashing, you want to make a requirement that will show the block was hashed in a specific order. adding this data to the block defeats the purpose and a method of bypassing this will be discovered relatively easily. Instead, you might want to follow the approach of the BCRYPT hashing algorithm, which appends data to the beggining and end of a hash, offering information as to how the hash was produced.
One might be able to determine an algorithm for appending a secret to the end of the hash, and number for each round of hashing to the beginning.
say we have four rounds of hashing well to illustrate my point this is what our block hashing method might look like.
step1:
input -> 0xfe 0xdd 0xbe 0xfd //some random data
secret[0]-> //some random data computed from our input
hash-> create a hash from secret and input
result:
secret[0].hash.input //our result hash string would
at the end of 4 rounds our hash would look like
secret[3].secret[2].secret[1].secret[0].hash / input
in this example, we can easily prove all subsequent steps in the chained hashing algorithm originated from the original input, while making it difficult to replicate without performing the entirety of the work.
Again mathematics, plain and simple.
is the claim so outrageous. what does checkProofOfWork do exactly?
i'll comment it for you so you understand.
bool CheckProofOfWork(uint256 hash, unsigned int nBits)
{
CBigNum bnTarget;
bnTarget.SetCompact(nBits);
// Check range
if (bnTarget <= 0 || bnTarget > bnProofOfWorkLimit) // if Target <= 0 OR target > limit
return error("CheckProofOfWork() : nBits below minimum work");
// Check proof of work matches claimed amount
if (hash > bnTarget.getuint256()) //if hash > Target
return error("CheckProofOfWork() : hash doesn't match nBits");
return true;//it passed the test, it must be valid.
}
line 1420
now, for CheckWork:
bool CheckWork(CBlock* pblock, CWallet& wallet, CReserveKey& reservekey)
{
uint256 hash = pblock->GetPoWHash(); //get the block hash, which is obviously sha256
uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
if (hash > hashTarget)
return false;
//// debug print
printf("LogiCoinMiner:\n");
printf("proof-of-work found \n hash: %s \ntarget: %s\n", hash.GetHex().c_str(), hashTarget.GetHex().c_str());
pblock->print();
printf("generated %s\n", FormatMoney(pblock->vtx[0].vout[0].nValue).c_str());
// Found a solution
{
LOCK(cs_main);
if (pblock->hashPrevBlock != hashBestChain)
return error("LogiCoinMiner : generated block is stale");
// Remove key from key pool
reservekey.KeepKey();
// Track how many getdata requests this block gets
{
LOCK(wallet.cs_wallet);
wallet.mapRequestCount[pblock->GetHash()] = 0;
}
// Process this block the same as if we had received it from another node
CValidationState state;
if (!ProcessBlock(state, NULL, pblock))
return error("LogiCoinMiner : ProcessBlock, block not accepted");
}
return true;
}
The hashings itself may occur in other algorithms, but the checks are only ran on sha256 hashes, which was my point all along. if the sha256 hash satisfies the target it doesn't matter whether the extra hashing ever occured.
I'm having trouble understanding what the argument against my theory is? is it that short circuiting can't possibly produce a valid hash without all the extra hashing? i don't believe that to be true.
