We should form a cooperative and search the private key...
Most dump idea ever. 
You made my day.
Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 258. (Read 192344 times)
You made my day.
We should form a cooperative and search the private key space for the next correct value in much the same way GIMPS (http://www.mersenne.org/) searches for prime numbers.
Everyone that wants to participate would run a client in the background on their computer.
There would be a central server which would dole out search spaces of one billion or trillion consecutive private keys (whatever makes sense as a chunk size) to the connected clients and the clients would grind through their assigned search spaces using my suggested (increment by G) algorithm.
When a client was done with its assignment it would request another chunk of private key space from the server.
If a client did find the correct private key then the winner would keep the 0.051 BTC.
we could do something with the BTC, suggestions are:
split it among all clients proportional to work done [but method to prove work would need to be figured out]
donate it to charity
open to other suggestions
Everyone that wants to participate would run a client in the background on their computer.
There would be a central server which would dole out search spaces of one billion or trillion consecutive private keys (whatever makes sense as a chunk size) to the connected clients and the clients would grind through their assigned search spaces using my suggested (increment by G) algorithm.
When a client was done with its assignment it would request another chunk of private key space from the server.
If a client did find the correct private key then the winner would keep the 0.051 BTC.
split it among all clients proportional to work done [but method to prove work would need to be figured out]
donate it to charity
open to other suggestions
Here are all keys from #1 to #40:
Very nicely done. I especially like the graphical binary form and the log2 is also informative.Thanks for this.
Are you currently trying to discover the values above 40?
It seems to me that you guys should not be using the ECC scalar multiplication function at all, just a very fast, totally optimized "increment by G" function:
This algorithm, when optimized, and split up so that many loops could be done in parallel, is as fast as it can be done.
Note on the PublicKey to BitcoinAddress conversion function:
You only need to do the first 3 of the 9 steps in this process.
1 - Take the PublicKey and format it properly (add the 1 byte of 0x04, change to compressed form if needed)
2 - Perform SHA-256 hashing on the result
3 - Perform RIPEMD-160 hashing on the result of SHA-256
This result can be compared directly to the BitcoinAddresses[] array assuming you have stored the 256 Bitcoin addresses in the proper binary form.
Not sure a miner would help as it only does one of the steps in the PublicKey to BitcoinAddress conversion.
Of course an FPGA could be programmed to do this. And, of course, if you had the resources an ASIC could be made to do this.
Final note on the BitcoinAddresses[] array values:
To get the proper values for this array simply undo the last 6 steps of the PublicKey to BitcoinAddress function for each of the 256 Bitcoin addresses in the transaction:
1 - Decode the base58 string to a binary byte array
2 - Strip off the 4 checksum bytes from the tail
3 - Strip off the version byte (0x00) from the front
4 - Store the result in the array
Code:
Initialization:
Set BitcoinAddresses[256] = the list of bitcoin addresses from the transaction, binary form without the checksum
Set BitcoinAddressIndex = 0;
Set PrivateKey = 1;
Set PublicKey = G;
Loop Until BitcoinAddressIndex == 256: // == "forever"
Call Convert PublicKey to BitcoinAddress [but just to the binary form, do not encode or calculate the checksum]
If BitcoinAddress == BitcoinAddresses[BitcoinAddressIndex] Then
Log BitcoinAddressIndex, PrivateKey, PublicKey, BitcoinAddress
Create transaction and claim Bitcoins if any available at BitcoinAddress
Endif
++PrivateKey;
Call Increment PublicKey by G // Highly optimized, very specialized function to just compute PublicKey = PublicKey + G
EndLoop
Set BitcoinAddresses[256] = the list of bitcoin addresses from the transaction, binary form without the checksum
Set BitcoinAddressIndex = 0;
Set PrivateKey = 1;
Set PublicKey = G;
Loop Until BitcoinAddressIndex == 256: // == "forever"
Call Convert PublicKey to BitcoinAddress [but just to the binary form, do not encode or calculate the checksum]
If BitcoinAddress == BitcoinAddresses[BitcoinAddressIndex] Then
Log BitcoinAddressIndex, PrivateKey, PublicKey, BitcoinAddress
Create transaction and claim Bitcoins if any available at BitcoinAddress
Endif
++PrivateKey;
Call Increment PublicKey by G // Highly optimized, very specialized function to just compute PublicKey = PublicKey + G
EndLoop
This algorithm, when optimized, and split up so that many loops could be done in parallel, is as fast as it can be done.
Note on the PublicKey to BitcoinAddress conversion function:
You only need to do the first 3 of the 9 steps in this process.
1 - Take the PublicKey and format it properly (add the 1 byte of 0x04, change to compressed form if needed)
2 - Perform SHA-256 hashing on the result
3 - Perform RIPEMD-160 hashing on the result of SHA-256
This result can be compared directly to the BitcoinAddresses[] array assuming you have stored the 256 Bitcoin addresses in the proper binary form.
Not sure a miner would help as it only does one of the steps in the PublicKey to BitcoinAddress conversion.
Of course an FPGA could be programmed to do this. And, of course, if you had the resources an ASIC could be made to do this.
Final note on the BitcoinAddresses[] array values:
To get the proper values for this array simply undo the last 6 steps of the PublicKey to BitcoinAddress function for each of the 256 Bitcoin addresses in the transaction:
1 - Decode the base58 string to a binary byte array
2 - Strip off the 4 checksum bytes from the tail
3 - Strip off the version byte (0x00) from the front
4 - Store the result in the array
Pretty good performance. I'm at 10,000 keys/s, pretty slow, so I will get nowhere for values > #40 without trying to improve code or coding for GPU.
Anyhow, I think even with GPU we won't go too far...
Do you know anything about who created this 32 BTC puzzle?
A GPU cracker would take at most a year for solving the next 251 address at 35,000,000 keys/s. I guess it will be cracked too in future, but for fun and not for money.Anyhow, I think even with GPU we won't go too far...
Do you know anything about who created this 32 BTC puzzle?
I don't know who made this pizzle.
Exactly.
One thing I was wondering is if it is possible somehow to tweak some ASIC miner out there to turn it into a cracker?
I have no idea if such thing is possible as I never used any ASIC miner.
Miners can only do sha256d. What is needed here is pubkey(ECDSA privkey) and ripemd160(sha256(0x04pubkeyxpubkeyy)). Everything else can be ignored if we compare to the ripemd160 hash. Its certainly possible to design an ASIC for this and it might even be profitable for someone to do so in the future.
Pretty good performance. I'm at 10,000 keys/s, pretty slow, so I will get nowhere for values > #40 without trying to improve code or coding for GPU.
Anyhow, I think even with GPU we won't go too far...
Do you know anything about who created this 32 BTC puzzle?
A GPU cracker would take at most a year for solving the next 251 address at 35,000,000 keys/s. I guess it will be cracked too in future, but for fun and not for money.Anyhow, I think even with GPU we won't go too far...
Do you know anything about who created this 32 BTC puzzle?
I don't know who made this pizzle.
Exactly.
One thing I was wondering is if it is possible somehow to tweak some ASIC miner out there to turn it into a cracker?
I have no idea if such thing is possible as I never used any ASIC miner.
Pretty good performance. I'm at 10,000 keys/s, pretty slow, so I will get nowhere for values > #40 without trying to improve code or coding for GPU.
Anyhow, I think even with GPU we won't go too far...
Do you know anything about who created this 32 BTC puzzle?
A GPU cracker would take at most ~a year for solving the next 251 address at 35,000,000 keys/s. I guess it will be cracked too in future, but for fun and not for money.Anyhow, I think even with GPU we won't go too far...
Do you know anything about who created this 32 BTC puzzle?
I don't know who made this pizzle.
Your results are from CPU or GPU?
What's your performance?
I was involved in the challenge and earned some BTC. I speedhacked the code in the mealtime at work straight after I saw the puzzle back in January 2015 and started it on some server remotely. The first version could do about 100,000 keys/s using a CPU. After some improvements I boosted the rate to 700,000 keys/s on a single computer. Later I ran it on many computers and checked million of keys/s. Luckly I could recycle the code later in the August 2015 puzzle at https://bitcointalksearch.org/topic/bitcoin-cipherpuzzle-056-prize-bitcoins-solved-1144807What's your performance?
I had no time to learn how to code on a GPU.
Pretty good performance. I'm at 10,000 keys/s, pretty slow, so I will get nowhere for values > #40 without trying to improve code or coding for GPU.
Anyhow, I think even with GPU we won't go too far...
Do you know anything about who created this 32 BTC puzzle?
Your results are from CPU or GPU?
What's your performance?
I was involved in the challenge and earned some BTC. I speedhacked the code in the mealtime at work straight after I saw the puzzle back in January 2015 and started it on some server remotely. The first version could do about 100,000 keys/s using a CPU. After some improvements I boosted the rate to 700,000 keys/s on a single computer. Later I ran it on many computers and checked million of keys/s. Luckly I could recycle the code later in the August 2015 puzzle at https://bitcointalksearch.org/topic/bitcoin-cipherpuzzle-056-prize-bitcoins-solved-1144807What's your performance?
I had no time to learn how to code on a GPU.
Well damn I can't code so there goes that option
If I was smart enough to do this I would, looks fun
If I was smart enough to do this I would, looks fun
So could I just use vanitygen & type in
vanitygen.exe -t 50 -v [address]?
Or is there different else to do
Vanitygen doesn't support this way of address generation but you can create your own customized program by copying some code off vanitygen.vanitygen.exe -t 50 -v [address]?
Or is there different else to do
It doesn't make sense to use the CPU version anymore if you plan to brute force the keys above 250.
Your results are from CPU or GPU?
What's your performance?
So could I just use vanitygen & type in
vanitygen.exe -t 50 -v [address]?
Or is there different else to do
Vanitygen doesn't support this way of address generation but you can create your own customized program by copying some code off vanitygen.vanitygen.exe -t 50 -v [address]?
Or is there different else to do
It doesn't make sense to use the CPU version anymore if you plan to brute force the keys above 250.
Very good! Thanks
What does the column Log(2) mean exactly? What are the calculations behind it?
Log(2) = Logarithm to the base 2 of the decimal value.What does the column Log(2) mean exactly? What are the calculations behind it?
How did you find the private key for the first address?
Brute forceSo could I just use vanitygen & type in
vanitygen.exe -t 50 -v [address]?
Or is there different else to do
What does the column Log(2) mean exactly? What are the calculations behind it?
Log(2) = Logarithm to the base 2 of the decimal value.How did you find the private key for the first address?
Brute force
I'm horrible at this stuff, just curious..
How did you find the private key for the first address?
Maybe once I figure that out I can give this a shot
How did you find the private key for the first address?
Maybe once I figure that out I can give this a shot
Here are all keys from #1 to #40:
-snip-
-snip-
Very good! Thanks
What does the column Log(2) mean exactly? What are the calculations behind it?
I don't know why but I'm smelling a big scam. Because a newbie that offer more than 12 000€ to solve a following of numbers this is strange...
Pls read the posts first before spamming for sig campaign
Here are all keys from #1 to #40:
| Bits | Hex | Decimal | Binary | As raw text | Log(2) |
| 1 | 0000000001 | 1
This is the address #25:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7siAXycwkwRQg 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP 33185509 Nobody knows yet any others? What I don't understand exactly is how 1 encodes to a private key. 1 doesn't "encode to a private key", 1 IS a private key. An ECDSA private key is simply a number. For bitcoin, it is ANY number between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494336 (when represented in base 10) That number can be represented in any of various forms such as binary, hexadecimal, octal, decimal, base58, or Wallet Import Format (also known as base58check or WIF). Perhaps you are asking how to represent the decimal value of 1 in WIF? Yes, sometimes asking the right questions is also an issue... And I think that's the right question I wanted to ask. Tried fiddling with this but haven't reached a working WIF for 1. I guess there is yet much more to learn about Bitcoin than I could ever imagine  Jump to:
|