|
3
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
|
on: April 24, 2024, 12:33:56 PM
|
Is this puzzle really worth trying to solve? It's been close to a decade. Can someone give me a TL;DR?
There are several puzzles with different bits of diffculty it is exponential, puzzle 66 is 6.6 BTC BTC puzzle 67 is 6.7 BTC. Puzzles prizes have been incremented in a x10 Factor two times since its creation. Check the list of all unsolved puzzles. https://docs.google.com/spreadsheets/d/1vZyRZ67iNl7aIwYNB55OY8LvZLAaoBxSanxqnGMZlWA/edit?usp=sharingThere are some puzzles addres with publickey avaiable those have another method to be solved current unsolved with publickey is puzle 130 13 BTCI have another idea,
The puzzle creator said the only thing all the private keys have in common, is that all of them were created from a HD wallet, and then masked from the left with zeros.
Is it any weakness on the HD method of creating wallets? I mean, with the number of private keys already revealed, we could just try to target the searches for the the master private key that was used in the HD wallet.
What do you think?
Regards.
I think that author or this puzzle may used a custom method to generate those keys This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density. If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two?  I am the creator. You are quite right, 161-256 are silly. I honestly just did not think of this. What is especially embarrassing, is this did not occur to me once, in two years. By way of excuse, I was not really thinking much about the puzzle at all. I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully. A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community. Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting! He never mention HD wallet it only mentioned some deterministic wallet |
|
|
|
|
5
|
Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED==
|
on: April 23, 2024, 04:18:45 PM
|
1 exakey per second means 1 and 18 zeros, a 4 GHz CPU could "count" up to a 11 digits number with no EC math involved, just pure counting per second. I would like to know how you can generate 4 exakey/s using keyhunt?
If you have a binary tree with 4 billion values, and you search if a specific one is in the tree, it takes at most 32 steps to do so. That means you searched 4 billion keys, but only did 32 CPU "goto next node" operations. So, in a sense, a speed of "4 billion keys / 32 cpu operations". You don't need to go through all of the nodes to know if something is in the tree or not. Ofcourse, this is really misleading. Such exakeys/s numbers mean nothing in context of how big the parent keyspace really is, it's more like a click bait. You might as well apply the same logic to a pollard kangaroo evolving program and end up with ridiculous speeds as well the more data points you store, but it would not be a speed of group operations anymore, just like it's not for keyhunt. Yeah exakeys is nothing compared with the keyspace that is begin scannig. I really like the binary tree analogy as example it is good. With BSGS the important number is the precalculated data in the bloom filter if we have 4 billion keys in a bloom filter we easily can know if the key is not in our bloom filter doing less than 20 hashes. so that means we discard a subrange of 4 billion keys with only 20 CPU Operations. https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/ |
|
|
|
|
17
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
|
on: April 09, 2024, 10:35:09 PM
|
I always dreamed finding something unspent on those ID's (04-06-07).
I didn't know the existence of 06 and 07 public key prefix. I wonder where are those prefixes used? Is there some trick to compute the X value of P + G if you don't know P.y? I'm curious to know.
Q = P+G Well you need to know the value P.y in order to calcualte the next sequence of Q values but you you don't need to calculate the actual Q.y value, this sound a dubious but actuallly it works and faster than regular approach. This work better for some array of Q values, if the array is 512 or 1024 items long you can skip the calcualtions of 512 or 1024 Q.y values You only need to calculate one Q.y value for next group of items and repeat (This value need to be the center of the group becuse it use it use a property that P + i*G and P - i*G have the same deltax and same inverse value), this save alot of time. It not only works for Q = P+G but for any Q = P+ iG Its complex and painful but read the code but it worth the time to study and implement it, just to see how the speed increment, maybe i will publish an step by step explatnation for it, but if you want to take a look please check where i learned it: https://github.com/JeanLucPons/BSGS/blob/master/BSGS.cpp#L189That implementation alone multiply the previous speed x4 times. |
|
|
|
|
18
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
|
on: April 09, 2024, 05:10:43 PM
|
would you recommend any other? or any other PRO tips?
The function that you mention use the method know as Scalar Multiplication, this method is also know as "double and add" it use a cycle that per each bit in the key double the generation point G and only adds to the result those whom are bits 1. In the worst case it is near 256 cycle per key or if you have some precalculated data of those public keys divided in bytes instead bits you can reduce that cycle to 32 per key but that is still just a suggestion for that function. The best way to proceed with it this kind of programs is just calculate the first key and with that first key do Public key additions to reach the next key this process will speed you program around 30 times So instead of recalculate the public key each time with secp256k1_ec_pubkey_create result=secp256k1_ec_pubkey_create(ctx, &pubkey_from_secp256k1.p, privkey);
next_key =secp256k1_ec_pubkey_create(ctx, &pubkey_from_secp256k1.p, privkey +1);
next_key =secp256k1_ec_pubkey_create(ctx, &pubkey_from_secp256k1.p, privkey +2);
next_key =secp256k1_ec_pubkey_create(ctx, &pubkey_from_secp256k1.p, privkey+3);
is just an example to illustrate what i mean. the program will do something like: first_key=secp256k1_ec_pubkey_create(ctx, &pubkey_from_secp256k1.p, privkey);
next_key = some_publickey_addition(first_key,G);
next_key = some_publickey_addition(next_key ,G);
next_key = some_publickey_addition(next_key ,G);
...
next_key = some_publickey_addition(next_key ,G);
...
Only the first key is calculated in the old way and the subsequent keys are calculated in a faster way. Another short cut is you don't need to calculate the Y value of all the subsequent keys (unless you are scanning for uncompressed keys) this may double the speed of the calculations. Another short cut is endomorphism (This don't work on small puzzles) but it can multiply your speed up to 6 times for a general search. |
|
|
|
|
19
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
|
on: April 09, 2024, 12:41:48 AM
|
The search speed is between 15-25K keys/s per CPU thread, depending on the CPU clock.
For CPU that speed is slow, the minimum acceptable speed per thread is at least 1 Million keys. Even my Core i5 laptop can do some 15 millions keys per second using only 8 threads. There is a lot of shortcuts that can be made to reach those speeds. I am interested to know the nature of the bot wars.
How is it possible the war?
Are the Kangaroo and BSGS tools sending the private key findings to the developers?
No those tools are open source and you can read the code to see what network activities they do. The bot war may start as soon an output transaction come from those address a transaction contains the public key, with it Kangaroo or BSGS can solve the private key almost instantly and with it they may be now able to make a new transactions with a different destination address |
|
|
|
|
Show Posts
