Pages:
Author

Topic: [Theoretical]The Short-Circuit 51% attack vulnerability in non Sha256 altcoins. (Read 4171 times)

hero member
Activity: 686
Merit: 504
always the student, never the master.
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?

Because sha256d(blockheader) produces a different result to sha256d(other_hashing_algo(blockheader)).

If you assert that it can produce the same, that'd be a sha256 collission and every crypto program which uses sha256 is screwed.

As I said earlier, the checks you are looking at all assume the hash you send is the one being used, when the hash is reproduced by each client when a block is broadcast. The client will come to a totally different hash that doesn't match the one you specified and just reject the block.
you're right I was totally ignoring the difference in the output after x rounds. I didnt thinkit would mean a collision but you are right in the end. Bitcoin doesn't use prngs so the hashes have a certain precision in which they are predictable. If I know correctly understand, its the constant nnonce that makes it all work to produce independently verifiable hashes
sr. member
Activity: 294
Merit: 250
Bitmark Developer
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?

Because sha256d(blockheader) produces a different result to sha256d(other_hashing_algo(blockheader)).

If you assert that it can produce the same, that'd be a sha256 collission and every crypto program which uses sha256 is screwed.

As I said earlier, the checks you are looking at all assume the hash you send is the one being used, when the hash is reproduced by each client when a block is broadcast. The client will come to a totally different hash that doesn't match the one you specified and just reject the block.
legendary
Activity: 1876
Merit: 1000
shhh  Lips sealed r3wt don't let reality get in the way of some good 'innovation' stories  Wink

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


No intention of editing it.
awaiting said story Cheesy (I know a story or 10 myself).
legendary
Activity: 2184
Merit: 1011
Franko is Freedom
Wouldn't it be easier to "make the point" by moding a mining program and raping non-sha altcoins?

Why expend energy in trying to convince others about the theory, instead of actually doing it and showing it? What is the obstacle?

Wouldnt it be easier to just open a testnet?
legendary
Activity: 2184
Merit: 1011
Franko is Freedom
Wouldn't it be easier to "make the point" by moding a mining program and raping non-sha altcoins?

Why expend energy in trying to convince others about the theory, instead of actually doing it and showing it? What is the obstacle?

I'm seeking someone with a fairly large amount of Sha 256 asics to help me test the theory.

Some altcoin algos run at like 3-5 Mhs at some GPUs while SHA256 runs at like 500 MHs. It's already 100x+. Why do you need asics? Mod a client and have fun.

In the case of cryptonight which runs at like a few hashes per sec, you are orders of magnitude faster with 500 MHs of a GPU sha256.

You don't understand the premise at all. The hashes are always converted back to sha256, meaning theoretically you could short circuit the entire algorithms of these coins with bitcoin's sha 256 algorithm and still produce valid blocks on the network.

No I understand what you are saying. I do not understand why you "require" sha256 asics for "testing it". You can test it even with a cpu (or gpu).

Yea, in theory one of the slow chained scrypts should be vulnerable, how about Franko? Mod a client and hit that shit hard, lets see if it will break.

Cheesy still gettin love I see <3
hero member
Activity: 686
Merit: 504
always the student, never the master.
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.
sr. member
Activity: 294
Merit: 250
Bitmark Developer
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!
legendary
Activity: 1946
Merit: 1100
Leading Crypto Sports Betting & Casino Platform
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?
hero member
Activity: 686
Merit: 504
always the student, never the master.
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
hero member
Activity: 686
Merit: 504
always the student, never the master.
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?
sr. member
Activity: 294
Merit: 250
Bitmark Developer
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)
hero member
Activity: 686
Merit: 504
always the student, never the master.

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.
sr. member
Activity: 294
Merit: 250
Bitmark Developer
sr. member
Activity: 259
Merit: 260
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.
hero member
Activity: 686
Merit: 504
always the student, never the master.
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.
hero member
Activity: 1191
Merit: 506
This is who we are.
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. 
sr. member
Activity: 259
Merit: 260
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.
hero member
Activity: 518
Merit: 500
Bitrated user: ahmedbodi.
good ideas but it doesnt check out. (i explained it to foodies)
sr. member
Activity: 259
Merit: 260
shhh  Lips sealed r3wt don't let reality get in the way of some good 'innovation' stories  Wink

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.
sr. member
Activity: 294
Merit: 250
Bitmark Developer
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.
Pages:
Jump to: