1

In POW miners solve an problem for successfully mining a block, who provide the question to the miners ?, does all miners work on same problem ?, and how the miners verify the answer ?, if the problem is generated by the client(geth) then isn't it a vulnerable ?, you could tamper the problem complexity.

2

The problem is always the same, only the inputs change.

The problem is always "given an input X, try to find a hash value with a nonce which has a smaller integer value than Y". The input X is formed from the previous block's hash and from transactions in the current block. It's very difficult to find the correct nonce value which produces the desired result, but it's very easy to verify the result once it's found.

And there lies the strength of the Proof of Work: difficult to find the right value but very easy to verify the result once a correct nonce has been found. Therefore everyone can easily verify that the nonce someone claims to be the result is actually a correct result.

You can't tamper with the system as the input is always known for everyone and the problem is always the same.

-1

I can add that not all the problems in a given instant are the same for all miners in every situation: as a general rule the hash to found lower than a threshold given is to be formed from a nonce (i.e. a number that is changed by the miner until the solution is found), the given challenge (i.e. a number proposed to the miners community to synthetize the new run) AND a miner disntictive signature (f.i. the Ethereum address of the single miner).

In other words the number to be found under the given threshold is something like (just a description in order to understand):

numberToBeFound = sha3(uint nonce, bytes32 challenge, address _miner);

or something similar.

In this sense, given that the addresses of the various miner are different, the problem to solve is different for each miner at any time.

This can give better chances to miner A respect to miner B for a given challenge run, but this is absolutely random and then, in average this advantage do not exists.

FROM A COMMENT:

To include the address of the miner in the hash is needed to avoid the so called “man in the middle attack”. If you propose your winning transaction, no one can copy it and propose it as it was of his property, even if his “copied winning transaction” is pumped by an enormous gas and is mined before than yours. This is the standard for minable token on Ethereum. You can find it explained here: github.com/xbdao/EIP918-reorganized/blob/master/README.md

HERE I REPORT FOR @Lauri Peltonen THE mint() FUNCTION TAKEN FROM 0xbitcoin token in etherscan. It should be clear the mitm standard mitigation technique I cited above (just watch first few lines of code)

function mint(uint256 nonce, bytes32 challenge_digest) public returns (bool success) {

        //the PoW must contain work that includes a recent ethereum block hash (challenge number) and the msg.sender's address to prevent MITM attacks
        bytes32 digest =  keccak256(challengeNumber, msg.sender, nonce );

        //the challenge digest must match the expected
        if (digest != challenge_digest) revert();

        //the digest must be smaller than the target
        if(uint256(digest) > miningTarget) revert();

        //only allow one reward for each challenge
         bytes32 solution = solutionForChallenge[challengeNumber];
         solutionForChallenge[challengeNumber] = digest;
         if(solution != 0x0) revert();  //prevent the same answer from awarding twice

        uint reward_amount = getMiningReward();

        balances[msg.sender] = balances[msg.sender].add(reward_amount);

        tokensMinted = tokensMinted.add(reward_amount);

        //Cannot mint more tokens than there are
        assert(tokensMinted <= maxSupplyForEra);

        //set readonly diagnostics data
        lastRewardTo = msg.sender;
        lastRewardAmount = reward_amount;
        lastRewardEthBlockNumber = block.number;

         _startNewMiningEpoch();

          Mint(msg.sender, reward_amount, epochCount, challengeNumber );
       return true;
    }
  • Do you have a source for this? I believe this information to be incorrect. Miner's address is not used as input for the hash - otherwise it might indeed give unfair advantage. Have a look at asynclabs.co/blog/proof-of-work-what-it-is-and-how-does-it-work for example. – Lauri Peltonen Dec 18 '18 at 14:06
  • Including the address of the miner in the hash is needed to avoid the so called “man in the middle attack”. If you propose your winning transaction, no one can copy it and propose it as it was of his property, even if his “copied winning transaction” is pumped by an enormous gas and is mined before than yours. This is the standard for minable token on Ethereum. You can find it explained here: github.com/xbdao/EIP918-reorganized/blob/master/README.md – Rick Park Dec 18 '18 at 16:27
  • That has nothing to do with the Ethereum PoW algorithm. That's a suggestion for a token scheme and its status is 'Draft'. The original question was about Ethereum's PoW. – Lauri Peltonen Dec 18 '18 at 16:32
  • I do not think so: the question is absolutely general, being Ethereum pow a special case. In general you have the problem of the Man in the middle attack, where in the special case of Ethereum pow it can be (somehow) ignored. – Rick Park Dec 18 '18 at 16:35
  • Moreover you can easily find this schema in known minable tokens, one for all: 0xbitcoin – Rick Park Dec 18 '18 at 17:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.