Search content
Sort by
Showing 8 of 8 results by vshoes
uhh i might be a little bit late finding your problem but i have went through the same problem back in 2017 and solved it and i think i know what is your problem exactly . your wallet needs some dust cleaning and recovering it on a specific platform with a specific way(the same way i used to recover mine)and you mentioned that you still have the private keys which will make it much more easier ,so if you see this and you still want to recover it, ill be available for you any time lol 
|
|Isn't the problem that OPs brother mined orphan blocks and there's a network of precisely 1 computer that recognizes his mined rewards, falling to 0 when that computer gets synced up to the latest block? Or have I missed something. If you can turn orphan blocks into accepted blocks I think there'd be zero demand for your services because you've destroyed the entire crypto industry. Please share your method, sir.
Thanks for explanations (and picking up my sloppy nomenclature). All seems clear now. I didn't run a Grubb's test as there's no need, the explanations have covered why this is the case and we can take it that there are two distinct populations here.
⭐ Merited by ABCbits (2)
I'm using a python script and bitcoinlib to generate a vanity address; I'm looking for a public key that looks like 1(name) where (name) is only 4 characters long, so I didn't think it would take me too long, guessed maybe the order of days or weeks.
I ran it for a short time exporting the results, and analyzed the output. What surprised me was the distribution of the first variable character. After 1, these are the most frequently occurring characters
https://talkimg.com/images/2024/11/20/b1d0v.png
Clearly the first cluster of 2 through to P (less I) appears evenly distributed (will run a Grubb's test to confirm). Can anyone explain why characters(1, I, Q, R, S, T, U, V, W, X, Y, Z) are so less likely to appear in the first position? Thanks
Code:
from bitcoinlib import wallets
# create new wallet
w = wallets.Wallet.create('TestWallet1')
# key info as dictionary
keyInfo = w.get_key()
# get pub and priv key in WIF format
pubKey = keyInfo.address
privKey = keyInfo.wif
# create new wallet
w = wallets.Wallet.create('TestWallet1')
# key info as dictionary
keyInfo = w.get_key()
# get pub and priv key in WIF format
pubKey = keyInfo.address
privKey = keyInfo.wif
I ran it for a short time exporting the results, and analyzed the output. What surprised me was the distribution of the first variable character. After 1, these are the most frequently occurring characters
https://talkimg.com/images/2024/11/20/b1d0v.png
Clearly the first cluster of 2 through to P (less I) appears evenly distributed (will run a Grubb's test to confirm). Can anyone explain why characters(1, I, Q, R, S, T, U, V, W, X, Y, Z) are so less likely to appear in the first position? Thanks
Re: Python based Solo miner for CPU | Learn Basic Bitcoin Mining | Just for fun
It's very slow. I optimised a little, but couldn't find many ways to improve. One way way was change the libraries imported: instead of
replaced with importing the specific function from the library and giving an assignation as below
Then do this for every function called from an imported library. Improvement was slight but noticable
Code:
import binascii
binascii.hexlify(merkle_root).decode()
binascii.hexlify(merkle_root).decode()
replaced with importing the specific function from the library and giving an assignation as below
Code:
from binascii import hexlify as h
h(merkle_root).decode()
h(merkle_root).decode()
Then do this for every function called from an imported library. Improvement was slight but noticable
Re: Python based Solo miner for CPU | Learn Basic Bitcoin Mining | Just for fun
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!
Re: Python based Solo miner for CPU | Learn Basic Bitcoin Mining | Just for fun
One more q for anyone who might be able to answer;
Why are we evaluating hash < target? Shouldn't that be
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...")
# 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!!')
print('success!!')
Re: Python based Solo miner for CPU | Learn Basic Bitcoin Mining | Just for fun
I made some small improvements:
1) I called the noncework function 2**32 times, not just 10 million million times
2) every time i called the noncework function, i passed the loop value k, using that number as the nounce and not a random number
I could also have used the time parameter, another 5000 or 6000 times cycle, so that the root merkle only resets once every 5000*2**32. In that case, if we had a 100 TH/S asic instead of a CPU, it would have to recalculate the nounce every 4 or 5 seconds, if I'm not mistaken.
1) I called the noncework function 2**32 times, not just 10 million million times
2) every time i called the noncework function, i passed the loop value k, using that number as the nounce and not a random number
I could also have used the time parameter, another 5000 or 6000 times cycle, so that the root merkle only resets once every 5000*2**32. In that case, if we had a 100 TH/S asic instead of a CPU, it would have to recalculate the nounce every 4 or 5 seconds, if I'm not mistaken.
Code:
# omitted for brevity
# use this loop if you want to do a speed test with only 1 million rounds
start = time.time()
for k in range(1000000):
noncework(k)
end = time.time()
print(end - start)
# about 42.5
'''
# use this loop if you want to try all the nounce with 2**32 rounds
for k in range(2**32):
noncework(k)
'''
print("Finished nounce. Regaining Information.")
sock.close()
main()
main()
# use this loop if you want to do a speed test with only 1 million rounds
start = time.time()
for k in range(1000000):
noncework(k)
end = time.time()
print(end - start)
# about 42.5
'''
# use this loop if you want to try all the nounce with 2**32 rounds
for k in range(2**32):
noncework(k)
'''
print("Finished nounce. Regaining Information.")
sock.close()
main()
main()
I'm interested to understand why you chose (2**32) as the target for noncework. Given the end-start times when I tried your script, the noncework function takes around 2.5 hours. In that time, it's almost certain that a block would be found and you'd be looking at coinbase etc information from a non-current block. Am I wrong here, or should you be regaining information much sooner?
Also, can you explain the advantage of noncework(k) instead of noncework() ? Thanks!
I'm trying to optimize the script as a bit of fun, given I'll never mine a block, my goal is to improve my Mh/s figure as much as possible and learn more about the technical background underpinning mining.
Re: Python based Solo miner for CPU | Learn Basic Bitcoin Mining | Just for fun
You say just for fun, I wonder where is the fun if we start mining with our CPU 24/7 and never mine anything, could you provide some probability estimations on a single block found/time?
I've just fired this up on one core of a i5, running through 10MM hashes in around 56 seconds. That gives me 178,000 hashes/s or 0.178M/h, which presently equates to 65 BILLION years to find a block. That's between 14 and 15 times the age of the Earth, and slightly less than 5 times the age of the universe and everything in it.
Still, gotta be in it to win it!