Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 298. (Read 240843 times)
Hello here all are just give and show how and I will take only bitcoins and I will tell you thank you sorry my English
#80: 0xea1a5c66dcc11b5ad180
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
Nice. What software/script and what hardware did you used? What are the costs? Thanks!
Pollard kangaroo on gpu. No costs.
#80: 0xea1a5c66dcc11b5ad180
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
Nice. What software/script and what hardware did you used? What are the costs? Thanks!
Pollard kangaroo on gpu. No costs.
#80: 0xea1a5c66dcc11b5ad180
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
Nice. What software/script and what hardware did you used? What are the costs? Thanks!
And now, the #100 is spent!! 
Congratulations to the solver (or solvers
)
We hope the share of the found keys for our records.
I join in congratulations!!!Unless it's the Creator himself spending those addresses! Congratulations to the solver (or solvers
) We hope the share of the found keys for our records.
How quickly you can empty it,I did not have time to buy a Google for this.
#80: 0xea1a5c66dcc11b5ad180
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
And now, the #100 is spent!!
Congratulations to the solver (or solvers)
We hope the share of the found keys for our records.
Congratulations to the solver (or solvers
) We hope the share of the found keys for our records.
from transactions it is clear that these are 3 different people 
How you may know, Mate, that it was three different people? Because all that transactions to three different addresses? 
----
I'm still pretty sure that someone had found some weakness or tricky way in how to recover private keys. But the way is not really easy because it takes several days to Mr. X to recover the private key, OR theway is really easy but the Mr. X has an ancient type PC and so it takes him several days to recover the private key.
Step "5" is not a sudden one, there is definetely something behind it! Otherwise if you have a way to recover the private key from four addresses with total amount of 3.7 BTC why wouldn't you do it???
----
Also could be that there is a group of Mr. Xs who rent several VPSs with a huge RAM and distribute keyspaces between each other to search.
That would be quite an easy way for thouse who have money to invest and if the BS GS really the one which helps to find the private keys.
----
In any way that Mr. X is genius compared to us, guys!
And 99.9% sure that Mr. X or Xs was/were here on this forum reading this topic. ----
Dear Mr. X pls share with us at least the recently found private keys for our records.
So how secure are satoshi's coins which were mined directly and put in a public address instead of a BTC address.
Because you are saying that reusing addresses is not good because its not as secure but if this was the case why wouldn't this person who is solving all these puzzles for less than <1 BTC instead try and crack Satoshi's early coins which are sitting in all those public key addresses?
I think why its faster is because the search space is much small compared to the entire 128 bit search space, so its still safe to re-use addresses since as far as we know ECDSA hasn't been cracked yet or some exploit found.
Few people deal with this issue, as soon as it is put on stream then This standard ECDSA will quickly split. Because you are saying that reusing addresses is not good because its not as secure but if this was the case why wouldn't this person who is solving all these puzzles for less than <1 BTC instead try and crack Satoshi's early coins which are sitting in all those public key addresses?
I think why its faster is because the search space is much small compared to the entire 128 bit search space, so its still safe to re-use addresses since as far as we know ECDSA hasn't been cracked yet or some exploit found.
So how secure are satoshi's coins which were mined directly and put in a public address instead of a BTC address.
Because you are saying that reusing addresses is not good because its not as secure but if this was the case why wouldn't this person who is solving all these puzzles for less than <1 BTC instead try and crack Satoshi's early coins which are sitting in all those public key addresses?
I think why its faster is because the search space is much small compared to the entire 128 bit search space, so its still safe to re-use addresses since as far as we know ECDSA hasn't been cracked yet or some exploit found.
Because you are saying that reusing addresses is not good because its not as secure but if this was the case why wouldn't this person who is solving all these puzzles for less than <1 BTC instead try and crack Satoshi's early coins which are sitting in all those public key addresses?
I think why its faster is because the search space is much small compared to the entire 128 bit search space, so its still safe to re-use addresses since as far as we know ECDSA hasn't been cracked yet or some exploit found.
I don't know why but I'm smelling a big scam.
You are smelling a big scam because you did not bother to read the thread and came in here and dumped a stinking pile of your uninformed opinion on the thread. What you are smelling is not a scam but your own steaming pile of opinion. 
When there is a spend transaction the search method is:
Next Private Key -> Public Key -> Compare Public Key, repeat until found
Note that the private key range in this case is the full 2256 but there are ways to speed up the process
So, I think full entropy 256 bit private keys are still safe even with multiple spend transactions, but they may be less safe than a 160 bit Bitcoin address from a full entropy 256 bit private key with no spend transactions.
When the public key is known, there is a BIG speed up. With the fastest known algorithm the bit strength is cut to HALF so it is only 128bit security. Which is indeed a lot less than the 160 bit of hashed addresses. Next Private Key -> Public Key -> Compare Public Key, repeat until found
Note that the private key range in this case is the full 2256 but there are ways to speed up the process
So, I think full entropy 256 bit private keys are still safe even with multiple spend transactions, but they may be less safe than a 160 bit Bitcoin address from a full entropy 256 bit private key with no spend transactions.
But even 128 bits is secure. There is no way to brute force 128 bits, That is unless someone comes up with a new additional way to speed up the calculations
from transactions it is clear that these are 3 different people
Nothing will be shared by them, but they will not forget what more they can solve, and then it will be possible and I will think it will be silenced
I think this they solve the problem pikachunakapika or arulbero simply didn’t have been done anyway anyway arulbero said that it could search for a key to be 160
sorry my english translate
I think this they solve the problem pikachunakapika or arulbero simply didn’t have been done anyway anyway arulbero said that it could search for a key to be 160
sorry my english translate
... And the #95 is Spent now.
https://www.blockchain.com/btc/tx/2b46d8d754b712c0c481185f07fa7b11100fe48f807069fc2e0779735d81c99e
I'm still looking for the #80, #85 and #90 to add them to the spent list but I still didn't found them. Maybe pikachunakapika or arulbero can help us.
Congratulations to the one who found #95 (19eVSDuizydXxhohGh8Ki9WY9KsHdSwoQC)
It's fantastic !!!! Congratulations to the winner !! Can he share with us how he was able to put this into practice. https://www.blockchain.com/btc/tx/2b46d8d754b712c0c481185f07fa7b11100fe48f807069fc2e0779735d81c99e
I'm still looking for the #80, #85 and #90 to add them to the spent list but I still didn't found them. Maybe pikachunakapika or arulbero can help us.
Congratulations to the one who found #95 (19eVSDuizydXxhohGh8Ki9WY9KsHdSwoQC)
... And the #95 is Spent now.
https://www.blockchain.com/btc/tx/2b46d8d754b712c0c481185f07fa7b11100fe48f807069fc2e0779735d81c99e
I'm still looking for the #80, #85 and #90 to add them to the spent list but I still didn't found them. Maybe pikachunakapika or arulbero can help us.
Congratulations to the one who found #95 (19eVSDuizydXxhohGh8Ki9WY9KsHdSwoQC)
https://www.blockchain.com/btc/tx/2b46d8d754b712c0c481185f07fa7b11100fe48f807069fc2e0779735d81c99e
I'm still looking for the #80, #85 and #90 to add them to the spent list but I still didn't found them. Maybe pikachunakapika or arulbero can help us.
Congratulations to the one who found #95 (19eVSDuizydXxhohGh8Ki9WY9KsHdSwoQC)
My understanding is there is a bit of a trade off here.
When there is no spend transaction the search method is:
Next Private Key -> Public Key -> Hash -> Bitcoin Address -> Compare Bitcoin Address, repeat until found
Note that due to the hashing functions used the Bitcoin Address is expected within a private key range of only 2160
When there is a spend transaction the search method is:
Next Private Key -> Public Key -> Compare Public Key, repeat until found
Note that the private key range in this case is the full 2256 but there are ways to speed up the process
So, I think full entropy 256 bit private keys are still safe even with multiple spend transactions, but they may be less safe than a 160 bit Bitcoin address from a full entropy 256 bit private key with no spend transactions.
Even better yet is a longer full 256 bit Bitcoin address based on a full entropy 256 bit private key with no spend transactions.
When there is no spend transaction the search method is:
Next Private Key -> Public Key -> Hash -> Bitcoin Address -> Compare Bitcoin Address, repeat until found
Note that due to the hashing functions used the Bitcoin Address is expected within a private key range of only 2160
When there is a spend transaction the search method is:
Next Private Key -> Public Key -> Compare Public Key, repeat until found
Note that the private key range in this case is the full 2256 but there are ways to speed up the process
So, I think full entropy 256 bit private keys are still safe even with multiple spend transactions, but they may be less safe than a 160 bit Bitcoin address from a full entropy 256 bit private key with no spend transactions.
Even better yet is a longer full 256 bit Bitcoin address based on a full entropy 256 bit private key with no spend transactions.
I understand but why can't a HBM2 16GB GPU do this faster than a system with a fast CPU + loads of system RAM.
I am not too technical on the details here but I understand that if you know the private key you can easily compute the public key, but not the other way around.
So since the search space is small, basically most of the private key starts with 0's then you can easily start a range at the small private keys basically something like " 000000000000000000000000000000000000000000000001A838B13505B26867 "
So the GPU would take that and increment it and compute the public key very fast and just compare it to the public key with the funds inside it.
Since the PublicKey = PrivateKey * G (where G is an agreed to point on the elliptic curve and * is the defined scalar multiplication operation over the finite field of points on the elliptic curve) you can do the following:
0) Initialize PrivateKey to the start of the range you are interested in
1) Calculate the first PublicKey = PrivateKey * G
2) Compare the PublicKey to the target PublicKey, if they match then you are done and PrivateKey is the private key you are looking for
3) PrivateKey = PrivateKey + 1
4) PublicKey = PublicKey + G (instead of PublicKey = PrivateKey * G because adding the point G to the current PublicKey point is faster than calculating the PublicKey point from PublicKey = PrivateKey * G "from scratch" every time through the loop)
5) Goto step 2)
However, people that are doing this search are not using this "brute force" method. They are using a much faster method. This much faster method requires a lot of RAM. This faster method is described in detail in a very large post withing the last few pages of this thread. Check it out.
My understanding is there is a bit of a trade off here.
When there is no spend transaction the search method is:
Next Private Key -> Public Key -> Hash -> Bitcoin Address -> Compare Bitcoin Address, repeat until found
Note that due to the hashing functions used the Bitcoin Address is expected within a private key range of only 2160
When there is a spend transaction the search method is:
Next Private Key -> Public Key -> Compare Public Key, repeat until found
Note that the private key range in this case is the full 2256 but there are ways to speed up the process
So, I think full entropy 256 bit private keys are still safe even with multiple spend transactions, but they may be less safe than a 160 bit Bitcoin address from a full entropy 256 bit private key with no spend transactions.
Even better yet is a longer full 256 bit Bitcoin address based on a full entropy 256 bit private key with no spend transactions.
When there is no spend transaction the search method is:
Next Private Key -> Public Key -> Hash -> Bitcoin Address -> Compare Bitcoin Address, repeat until found
Note that due to the hashing functions used the Bitcoin Address is expected within a private key range of only 2160
When there is a spend transaction the search method is:
Next Private Key -> Public Key -> Compare Public Key, repeat until found
Note that the private key range in this case is the full 2256 but there are ways to speed up the process
So, I think full entropy 256 bit private keys are still safe even with multiple spend transactions, but they may be less safe than a 160 bit Bitcoin address from a full entropy 256 bit private key with no spend transactions.
Even better yet is a longer full 256 bit Bitcoin address based on a full entropy 256 bit private key with no spend transactions.
I understand but why can't a HBM2 16GB GPU do this faster than a system with a fast CPU + loads of system RAM.
I am not too technical on the details here but I understand that if you know the private key you can easily compute the public key, but not the other way around.
So since the search space is small, basically most of the private key starts with 0's then you can easily start a range at the small private keys basically something like " 000000000000000000000000000000000000000000000001A838B13505B26867 "
So the GPU would take that and increment it and compute the public key very fast and just compare it to the public key with the funds inside it.
My understanding is there is a bit of a trade off here.
When there is no spend transaction the search method is:
Next Private Key -> Public Key -> Hash -> Bitcoin Address -> Compare Bitcoin Address, repeat until found
Note that due to the hashing functions used the Bitcoin Address is expected within a private key range of only 2160
When there is a spend transaction the search method is:
Next Private Key -> Public Key -> Compare Public Key, repeat until found
Note that the private key range in this case is the full 2256 but there are ways to speed up the process
So, I think full entropy 256 bit private keys are still safe even with multiple spend transactions, but they may be less safe than a 160 bit Bitcoin address from a full entropy 256 bit private key with no spend transactions.
Even better yet is a longer full 256 bit Bitcoin address based on a full entropy 256 bit private key with no spend transactions.
When there is no spend transaction the search method is:
Next Private Key -> Public Key -> Hash -> Bitcoin Address -> Compare Bitcoin Address, repeat until found
Note that due to the hashing functions used the Bitcoin Address is expected within a private key range of only 2160
When there is a spend transaction the search method is:
Next Private Key -> Public Key -> Compare Public Key, repeat until found
Note that the private key range in this case is the full 2256 but there are ways to speed up the process
So, I think full entropy 256 bit private keys are still safe even with multiple spend transactions, but they may be less safe than a 160 bit Bitcoin address from a full entropy 256 bit private key with no spend transactions.
Even better yet is a longer full 256 bit Bitcoin address based on a full entropy 256 bit private key with no spend transactions.
I used to be a regular in this thread. I actually used vanitygen on my R9 280X to try and solve the #54 or #55 key a few years back before someone beat me to it. I only got like 20 MH/s with my 280X while the Nvidia's with Bitcrack got multiples of that and I just gave up.
Anyways regarding the dangers of reusing BTC addresses. I know you shouldn't reuse BTC addresses ever. However why do many exchanges like Bitfinex and Binanace reuse their addresses.
It seems that since these private keys have a low entropy its possible to solve quick with enough RAM as long as the public key is shown. However would this even be possible if the private key is actually completely random and has high entropy. You would need Terabytes and Terabytes of RAM which is not possible these days.
Anyways regarding the dangers of reusing BTC addresses. I know you shouldn't reuse BTC addresses ever. However why do many exchanges like Bitfinex and Binanace reuse their addresses.
It seems that since these private keys have a low entropy its possible to solve quick with enough RAM as long as the public key is shown. However would this even be possible if the private key is actually completely random and has high entropy. You would need Terabytes and Terabytes of RAM which is not possible these days.
Jump to: