Python based Solo miner for CPU | Learn Basic Bitcoin Mining | Just for fun

[vshoes]

One more q for anyone who might be able to answer;

Code:

        if hash < target :
    #    if(hash[:10] == '0000000000'):
            print('success!!')
            print('hash: {}'.format(hash))
            payload = bytes('{"params": ["'+address+'", "'+job_id+'", "'+extranonce2 \
                +'", "'+ntime+'", "'+nonce+'"], "id": 1, "method": "mining.submit"}\n', 'utf-8')
            sock.sendall(payload)
            print(sock.recv(1024))
            input("Press Enter to continue...")

Why are we evaluating hash < target? Shouldn't that be

Code:

if hash == target:
     print('success!!')

[1715362423]

1715362423

[1715362423]

1715362423

[1715362423]

1715362423

[1715362423]

1715362423

[Flavatron]

One more q for anyone who might be able to answer;

Code:

        if hash < target :
    #    if(hash[:10] == '0000000000'):
            print('success!!')
            print('hash: {}'.format(hash))
            payload = bytes('{"params": ["'+address+'", "'+job_id+'", "'+extranonce2 \
                +'", "'+ntime+'", "'+nonce+'"], "id": 1, "method": "mining.submit"}\n', 'utf-8')
            sock.sendall(payload)
            print(sock.recv(1024))
            input("Press Enter to continue...")

Why are we evaluating hash < target? Shouldn't that be

Code:

if hash == target:
     print('success!!')

No, it should be < the target ( not equal to it).

When mining Bitcoin , the goal is to find a hash that is not equal to the target(near impossible), but less than the target value(probalistic).  The target is a 256-bit number that the network adjusts every 2016 blocks to ensure that the time between blocks remains approximately 10 minutes on average.  A lower target means a higher difficulty in finding a valid block.

The hashing process is essentially a race to find a nonce value that, when combined with the block's header data(which itself contains the Merkle root of the previous blocks tx) and passed through the SHA-256 hashing algorithm twice, produces a hash value that is less than the network-defined target, which everyone can easily verify for themselves too.

Therefore the condition, in the educational example,  if hash < target: is correct because you are looking for a hash that is numerically less than the target.

[vshoes]

No, it should be < the target ( not equal to it).

When mining Bitcoin , the goal is to find a hash that is not equal to the target(near impossible), but less than the target value(probalistic).  The target is a 256-bit number that the network adjusts every 2016 blocks to ensure that the time between blocks remains approximately 10 minutes on average.  A lower target means a higher difficulty in finding a valid block.

The hashing process is essentially a race to find a nonce value that, when combined with the block's header data(which itself contains the Merkle root of the previous blocks tx) and passed through the SHA-256 hashing algorithm twice, produces a hash value that is less than the network-defined target, which everyone can easily verify for themselves too.

Therefore the condition, in the educational example,  if hash < target: is correct because you are looking for a hash that is numerically less than the target.

Thank you so much! I have just had to destroy my entire (wrong) understanding of how mining works, and remake it again from scratch!

[rostep]

Helo,

In the script, during the loop on the nonce, merkle_root and ctx.ntime keep the same value. But, I discover that, during this loop, while continue listening socket, ctx.job_id, ctx.coinb1, ctx.coinb2, ctx.ntime, and ctx.merkle_branch change the value. So, during the loop we have an very old value of merkle_root and ctx.ntime which are not updated.

Do you think that, we have to always listening the socket during the loop and update the value of merkle_root and ctx.ntime, according to what we receive?

[Nexus9090]

I find this thread really quite interesting.

I've been wondering what the payloads look like going back and forth.

This simple script goes a long way to explaining it, thank you.

I may even give it a go, just to see how slow it is

Thanks

G.