[Theoretical]The Short-Circuit 51% attack vulnerability in non Sha256 altcoins.

[slapper]

shhh   r3wt don't let reality get in the way of some good 'innovation' stories  

Quoting this, so it doesn't get edited and I can come back later for a story.

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.

There is a check for the correct PoW hash in CheckBlock():

    // Check proof of work matches claimed amount
    if (!CheckProofOfWork(GetPoWHash(), nBits))
        return DoS(50, error("CheckBlock() : proof of work failed"));

I don't see how you can get around this check.

He says his client can get around this CheckBlock

[1715309178]

1715309178

[1715309178]

1715309178

[1715309178]

1715309178

[foodies123]

The premise here is that this flaw could allow 51% attacks on alternate-algorithm coins with bitcoin hardware.

You have a wrong premise. The main vulnerability is NOT bitcoin hardware, but the speed differential between sha256 and other hashes. If cryptonight hashes at a few hashes per second and you use a sha256 800 mhash GPU (7970), why would you need an ASIC hardware? You will already have 99.9% of the network.

you're both not understanding each other. your arguments have nothing to do with his and vice versa.

Excuse me:

He writes

As 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.

Why would the short-circuiting of the hash only work in ASICs and not in CPUs or GPUs (with SHA256 mining software)? Please explain this to me because I'm an idiot.

Yeah he didn't get that, your point is valid, you don't need asics to mine sha256, you can generate sha256 blocks with any mining hardware

Exactly. And GPU sha256 is orders of magnitude faster than many other algos (so bypassing the other algos ensures a tremendous speed advantage). Hence the "requirement" for ASIC sha256 to "test it" is bogus. So why doesn't he make a software mining client for cpu or gpu so that we can see it?

it's not the mining client that needs to be modified, it's the actual coin source from what I understand so that you skip the primary hash verification and go directly to the sha256 one. The network should see it as a valid hash since it's ultimately a sha256 hash.

[AlexGR]

The premise here is that this flaw could allow 51% attacks on alternate-algorithm coins with bitcoin hardware.

You have a wrong premise. The main vulnerability is NOT bitcoin hardware, but the speed differential between sha256 and other hashes. If cryptonight hashes at a few hashes per second and you use a sha256 800 mhash GPU (7970), why would you need an ASIC hardware? You will already have 99.9% of the network.

you're both not understanding each other. your arguments have nothing to do with his and vice versa.

Excuse me:

He writes

As 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.

Why would the short-circuiting of the hash only work in ASICs and not in CPUs or GPUs (with SHA256 mining software)? Please explain this to me because I'm an idiot.

Yeah he didn't get that, your point is valid, you don't need asics to mine sha256, you can generate sha256 blocks with any mining hardware

Exactly. And GPU sha256 is orders of magnitude faster than many other algos (so bypassing the other algos ensures a tremendous speed advantage). Hence the "requirement" for ASIC sha256 to "test it" is bogus. So why doesn't he make a software mining client for cpu or gpu so that we can see it?

it's not the mining client that needs to be modified, it's the actual coin source from what I understand so that you skip the primary hash verification and go directly to the sha256 one. The network should see it as a valid hash since it's ultimately a sha256 hash.

Yes, that's what I actually meant (wrote it wrong). Even the wallet can mine with a cpu sha256 - and be quite fast at it (compared to slow algos running on GPUs).

[foodies123]

ahmed_bodi just made a good point, even if you mod your client and submit a buttload of directly generated sha blocks, the other nodes on the network will still verify using the usual method and thus will reject your blocks and ultimately mark you as a doser.

[foodies123]

and it wouldn't make for a valid 51% attack because since your blocks will be rejected from the start your hashrate won't even register on the network thus you will not be able to attack anything.

[coinsolidation]

Each block is checked using the client source, you can make one client do anything, even mint 10000000000 of whatever coin, but the block will be rejected by all the other conforming clients because the block is invalid.

[Titan]

shhh   r3wt don't let reality get in the way of some good 'innovation' stories  

Quoting this, so it doesn't get edited and I can come back later for a story.

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.

There is a check for the correct PoW hash in CheckBlock():

    // Check proof of work matches claimed amount
    if (!CheckProofOfWork(GetPoWHash(), nBits))
        return DoS(50, error("CheckBlock() : proof of work failed"));

I don't see how you can get around this check.

He says his client can get around this CheckBlock

There is no "getting around" the CheckBlock function. The PoW hash is calculated and if it does not match the block is rejected by the network.

Emulating the right PoW hash with sha256 hashes is likely a much more complicated problem than simply solving the PoW hash.

[ahmed_bodi]

good ideas but it doesnt check out. (i explained it to foodies)

[Titan]

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.

There is a check for the correct PoW hash in CheckBlock():

    // Check proof of work matches claimed amount
    if (!CheckProofOfWork(GetPoWHash(), nBits))
        return DoS(50, error("CheckBlock() : proof of work failed"));

I don't see how you can get around this check.

Well yes, thats the basics of proof of work. however the problem is, its only verifying a sha 256 hash. not the hashes that produced that hash, so my premise is that you can shortcircuit the entire process and just mine any of these coins with sha 256 ASIC.

You might be faster hashing sha256, but the problem at hand is also matching the correct PoW hash. This seems to be a much more demanding problem than calculating the PoW hash itself.

[vleroybrown]

This is a outrageous claim without something more than some theoretical development in the way the underlining math works.  Celebrate the "discovery" of this idea when you have successfully broken a few shitcoins. 

[r3wt]

is the claim so outrageous. what does checkProofOfWork do exactly?

i'll comment it for you so you understand.

Code:

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.
}

https://github.com/Logicoin/logicoin/blob/master/src/main.cpp  line 1420


now, for CheckWork:

Code:

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.

[Titan]

is the claim so outrageous. what does checkProofOfWork do exactly?

checkProofOfWork is called with a PoW hash, i.e. GetPoWHash(), and not a sha256 hash.

[coinsolidation]

GetPoWHash() executes the hashing algo on the client

https://github.com/Logicoin/logicoin/blob/0bfec6b1e2a63c0a60a77fb38dfb95d666293ed9/src/main.h#L1320
https://github.com/Logicoin/logicoin/blob/0bfec6b1e2a63c0a60a77fb38dfb95d666293ed9/src/hashblock.h#L62

block getpowhash calls header gethash calls a hash function.

In the above it does the hash9.

In litecoins case it's scrypt: https://github.com/litecoin-project/litecoin/blob/master-0.8/src/main.h#L1376

[r3wt]

GetPoWHash() executes the hashing algo on the client

https://github.com/Logicoin/logicoin/blob/0bfec6b1e2a63c0a60a77fb38dfb95d666293ed9/src/main.h#L1320
https://github.com/Logicoin/logicoin/blob/0bfec6b1e2a63c0a60a77fb38dfb95d666293ed9/src/hashblock.h#L62

block getpowhash calls header gethash calls a hash function.

In the above it does the hash9.

In litecoins case it's scrypt: https://github.com/litecoin-project/litecoin/blob/master-0.8/src/main.h#L1376

https://github.com/Logicoin/logicoin/blob/0bfec6b1e2a63c0a60a77fb38dfb95d666293ed9/src/main.h

Code:

uint256 GetPoWHash() const
    {
        return GetHash();
    }

uint256 GetBlockHash() const
    {
        CBlockHeader block;
        block.nVersion        = nVersion;
        block.hashPrevBlock   = hashPrev;
        block.hashMerkleRoot  = hashMerkleRoot;
        block.nTime           = nTime;
        block.nBits           = nBits;
        block.nNonce          = nNonce;
        return block.GetHash();
    }

uint256 GetHash() const
    {
        return SerializeHash(*this);
    }

uint256 GetHash() const
    {
        return Hash9(BEGIN(nVersion), END(nNonce));
    }

so the argument is that a short circuited hash would be seen as invalid on the unmodified clients? i don't think thats true at all.

[coinsolidation]

without the technical side.

your theory is based on the assumption that the hash is accepted as is and checked if it meets the difficulty.

instead the values you send are run through the client, a hash is produced using the algo of the coin, and if that production matches up the block is valid.

so a sha256 hash matching isn't enough, it'll be invalid.

snipped code:

Code:

class CBlockHeader
{

    uint256 GetHash() const
    {
        return Hash9(BEGIN(nVersion), END(nNonce));
    }

};

class CBlock : public CBlockHeader
{

    uint256 GetPoWHash() const
    {
        return GetHash();
    }

};

(you were looking at the gethash function from transactions, not blocks in your above snip)

[r3wt]

without the technical side.

your theory is based on the assumption that the hash is accepted as is and checked if it meets the difficulty.

instead the values you send are run through the client, a hash is produced using the algo of the coin, and if that production matches up the block is valid.

so a sha256 hash matching isn't enough, it'll be invalid.

snipped code:

Code:

class CBlockHeader
{

    uint256 GetHash() const
    {
        return Hash9(BEGIN(nVersion), END(nNonce));
    }

};

class CBlock : public CBlockHeader
{

    uint256 GetPoWHash() const
    {
        return GetHash();
    }

};

(you were looking at the gethash function from transactions, not blocks in your above snip)

How will it be invalid? the target and all underlying block data are the same. when the hash is converted to sha256, how would the hash be accepted but rejected if it is short circuited with sha256?

[r3wt]

So far, much of my theory has been proven wrong, but i still think i'm on to something here. there is a flaw, i can feel it

[slapper]

So far, much of my theory has been proven wrong, but i still think i'm on to something here. there is a flaw, i can feel it

Quick question. I noticed in your OP there is no mention of x11. There is a reference of Logicoin and you posted this only in Darkcoin thread.

may i solicit some opinions from the {{great minds}} in this thread?

https://bitcointalk.org/index.php?topic=669634.new#new

I guess I am unclear if if you are claiming x11 has this flaw? And why post that snarky comment in Darkcoin thread?

[coinsolidation]

r3wt, the nonce is the PoW not the hash. It's the former, nonce, time merkle which is checked, not the hash.

flaw's in what you thought was being checked.

very glad somebody is checking this stuff though, always question and check, thanks!

[r3wt]

So far, much of my theory has been proven wrong, but i still think i'm on to something here. there is a flaw, i can feel it

Quick question. I noticed in your OP there is no mention of x11. There is a reference of Logicoin and you posted this only in Darkcoin thread.

may i solicit some opinions from the {{great minds}} in this thread?

https://bitcointalk.org/index.php?topic=669634.new#new

I guess I am unclear if if you are claiming x11 has this flaw? And why post that snarky comment in Darkcoin thread?

no you took it the wrong way. I wanted to get the attention of
 eduffield, the dark coin dev's opinion. With so many ahitcoins darkcoin seems to be one of few with a dev who would care to investigate it.