TL;DR; this issue (as is) is not an issue at all

@kik's implementation of the exploit relies on an assumption which is not true for Ethereum: the possibility to create variants of the candidate block's header hash in a fashion similar to bitcoin. This is actually not possible in ethereum and even if supported by a customized node the block propagation of such mined blocks would be immediately blocked by other peers as the header hash in invalid.

Kik's assumption originates (probably) from the presence in block header (the full one, not the hash) of a field named extraData which is actualy a string often used to store vaniity messages (see here or here) or to stamp some signal useful for tracking mined blocks in order to activate attacks (see recent analysis about etc 51% attacks by @OhGodAGirl). The implementation of the exploit assumes this field can be used to store an extraNonce (ethereum's block header does not have an extraNonce field so there's no other place where to store it) which behaves as a variant indicator of the header hash pretty much like, in bitcoin mining, the extraNonce signals a variant of the merkle root. What has been overlooked is that extraData field in ethereum is actually part of the header hash, while in bitcoin extraNonce field is part of the merkle tree hash with the specific meaning of "rebuilt the tree hash with this nonce".

For a detail explanation of the exploit workflow please refer to Kik's documentation

Where the whole reasoning fails is here:

    for (uint64_t extra_nonce = start_extra_nonce; extra_nonce < end_extra_nonce; ++extra_nonce)
    {
       // >>> Begin of the misunderstanding
        const block_header new_header = {header.parent, extra_nonce};
        const hash256 header_hash = ethash_keccak256((const uint8_t *)&new_header, sizeof new_header);
        const hash256 final_hash = keccak_progpow_256(header_hash, seed, mix_hash);
       // <<< End of the misunderstanding

        if (is_less_or_equal(final_hash, boundary))
        {
            const uint64_t end_nonce = start_nonce + iterations;
            for (uint64_t nonce = start_nonce; nonce < end_nonce; ++nonce)
            {
                const uint64_t result_seed = keccak_progpow_64(header_hash, nonce) >> TRUNCATE;
                if (seed == result_seed)
                    return {{final_hash, mix_hash}, nonce, extra_nonce};
            }
        }
    }

As you can see from the above code the attempt is to create variants of the header hash starting from the original header hash, received from work provider (named header.parent), appending to it 64 bits of the extraNonce. The new input of 320 bits is Keccak'ed to return a new 256 bit variant of the header hash. So basically the new header hash is a Keccak hash of the original header hash.

Now ... a customized node would be supposed to store the extraNonce in the extraData field and "seal" the block using the nonce and extraNonce received.

What is missing here is that for ethereum :

header_hash = ethash_keccak256(rlp::encode( parentHash, beneficiary,  difficulty,
             gasLimit, ommersHash, bloom, number, gasUsed, timestamp, extraData,
             stateRoot, txRoot, receiptsRoot))

By consequence either of this may happen :

customized node seals the block with the original header and the new extra data and tries to broadcast the block to peers which eventually will reject it as the header hash does not match anymore with header members (the extraData field has changed)
customized node receives the extraData and rebuilds the header hash rlp-encoding all the header members including the new extraData field but this voids the findings of the miner process as the obtained header hash has nothing to do with the header hash computed in the loop depicted above where the hash applied to last keccak_progpow_256 is a hash of the header hash.

The way this exploit has been described does not make it impractical ... it's literally impossible !!

This said the only possibility to bypass DAG accesses using a pattern similar to the one described by @kik is to modify these two steps :

        const block_header new_header = {header.parent, extra_nonce};
        const hash256 header_hash = ethash_keccak256((const uint8_t *)&new_header, sizeof new_header);

to become as

        const uint8_t* new_header_rlp = rlp::encode(<all_header_members_with_new_extraData>)
        const hash256 header_hash = ethash_keccak256(new_header_rlp, sizeof(new_header_rlp));

but this adds so much overhead that any ASIC friendlyness is completely voided.
Worth to mention that spec 0.9.4. of ProgPoW blocks also such a remote (and totally unpractical) possibility.

64 bit seed exploits ASIC resistance #51

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions