Search content
Sort by
Showing 20 of 450 results by brainless
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
how do we break a 100bit number fast and what cpu/gpu is the best for the task?
your question is about 100 bit pubkeyOr
100 bit address ?
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
how do we break a 100bit number fast and what cpu/gpu is the best for the task?
your question is about 100 bit pubkeyOr
100 bit address ?
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Try 4c to 50
Are you kidding? There are 200-400 1PWo3JeB9jr in this huge range.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Unless you burned around 15.000 $ for the last week, did you honestly expect to find one?
Why so many? I've only been doing this for a couple of weeks, and I've already found a couple dozen 1PWo3JeB9j and one 1PWo3JeB9jr. Total cost is about $150
At the end of the range they posted it here in the topic, I found it in the middle, now I'm looking at the beginning range for statistics.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
A completely new class of method for computing discrete logarithms
This paper seems to be about a specific case http://web.archive.org/web/20250725043122/https://cr.yp.to/dlog/cuberoot-20120919.pdf but in reality, the method is generic. They talk about small discrete logarithms in the same vein that pollard rho has a complexity too high to handle large discrete logarithms…
Victor Shoup theorized that no generic discrete logarithm solving method could perform better than x½. This is indeed the complexity of Pollard Kangaroo and Pollard rho. But he also theorized than an algorithm with precomputation can yield at best a complexity of x⅓ which means the lower bound to break full sized secp256k1 is far less than the 2128 estimated security.
This paper is indeed diving in that class of faster speed at the expense of memory storage.
anyone to turn it’s mathematical description into implementation ?
This paper seems to be about a specific case http://web.archive.org/web/20250725043122/https://cr.yp.to/dlog/cuberoot-20120919.pdf but in reality, the method is generic. They talk about small discrete logarithms in the same vein that pollard rho has a complexity too high to handle large discrete logarithms…
Victor Shoup theorized that no generic discrete logarithm solving method could perform better than x½. This is indeed the complexity of Pollard Kangaroo and Pollard rho. But he also theorized than an algorithm with precomputation can yield at best a complexity of x⅓ which means the lower bound to break full sized secp256k1 is far less than the 2128 estimated security.
This paper is indeed diving in that class of faster speed at the expense of memory storage.
anyone to turn it’s mathematical description into implementation ?
Yes. That paper is the very basis of everything I was talking about numerous times, when saying that the DLP can be solved much faster.
You can also see it in practice whenever you hear anyone talking about precomputed data.
Note that reaching the 1/3 exponent complexity also requires doing the 2/3 exponent pre-work, so for secp256k1, if you want to reach that lower bound, you first have to do 2**170 group operations (and also storing a very large amount of data, depending on the desired DP frequency; in any case, much much more than the number of bits in all the storage drives in existence, raised to the power of 2).
And another thing is that that 1/3 + 2/3 refers to an optimal tradeoff between precomputed effort and solving effort, because there's nothing (except memory and time limits) stopping anyone from computing the full log, storing it, and solving any key in a single O(1) lookup step. And nothing stopping anyone from computing, let's say, half of the full log domain, and solving any key in 2 steps. And so on and so forth.
No, because as far I understand, in the case of http://web.archive.org/web/20250725043122/https://cr.yp.to/dlog/cuberoot-20120919.pdf the complexity is decreased by the square of the size of the table. And anyway, the challenge here indeed involve computing several discrete logarithms so reusing precomputation would be worthwhile compared to sticking to pollard kangaroo isn’t it ?
If we reduce the range of the puzzle 135 to 10^38 using the Kangaroo algorithm and having the specified public key, how long will it take to obtain the private key of the puzzle?
I don't understand what you mean. Could you explain how to create mathematics?
You and most user, developer at these forum follow math book written within last 100 years, today most of us applying those formula in digital world, just imagin it's not end still you can create your own math, can write a book and also could apply in our development, ,
2 most workable area, finding odd/even for private key
2nd finding key in exact bit range
No probability in above 2 cases, and it's possible
Just you need to act and think like scientist
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
A completely new class of method for computing discrete logarithms
This paper seems to be about a specific case http://web.archive.org/web/20250725043122/https://cr.yp.to/dlog/cuberoot-20120919.pdf but in reality, the method is generic. They talk about small discrete logarithms in the same vein that pollard rho has a complexity too high to handle large discrete logarithms…
Victor Shoup theorized that no generic discrete logarithm solving method could perform better than x½. This is indeed the complexity of Pollard Kangaroo and Pollard rho. But he also theorized than an algorithm with precomputation can yield at best a complexity of x⅓ which means the lower bound to break full sized secp256k1 is far less than the 2128 estimated security.
This paper is indeed diving in that class of faster speed at the expense of memory storage.
anyone to turn it’s mathematical description into implementation ?
This paper seems to be about a specific case http://web.archive.org/web/20250725043122/https://cr.yp.to/dlog/cuberoot-20120919.pdf but in reality, the method is generic. They talk about small discrete logarithms in the same vein that pollard rho has a complexity too high to handle large discrete logarithms…
Victor Shoup theorized that no generic discrete logarithm solving method could perform better than x½. This is indeed the complexity of Pollard Kangaroo and Pollard rho. But he also theorized than an algorithm with precomputation can yield at best a complexity of x⅓ which means the lower bound to break full sized secp256k1 is far less than the 2128 estimated security.
This paper is indeed diving in that class of faster speed at the expense of memory storage.
anyone to turn it’s mathematical description into implementation ?
Yes. That paper is the very basis of everything I was talking about numerous times, when saying that the DLP can be solved much faster.
You can also see it in practice whenever you hear anyone talking about precomputed data.
Note that reaching the 1/3 exponent complexity also requires doing the 2/3 exponent pre-work, so for secp256k1, if you want to reach that lower bound, you first have to do 2**170 group operations (and also storing a very large amount of data, depending on the desired DP frequency; in any case, much much more than the number of bits in all the storage drives in existence, raised to the power of 2).
And another thing is that that 1/3 + 2/3 refers to an optimal tradeoff between precomputed effort and solving effort, because there's nothing (except memory and time limits) stopping anyone from computing the full log, storing it, and solving any key in a single O(1) lookup step. And nothing stopping anyone from computing, let's say, half of the full log domain, and solving any key in 2 steps. And so on and so forth.
No, because as far I understand, in the case of http://web.archive.org/web/20250725043122/https://cr.yp.to/dlog/cuberoot-20120919.pdf the complexity is decreased by the square of the size of the table. And anyway, the challenge here indeed involve computing several discrete logarithms so reusing precomputation would be worthwhile compared to sticking to pollard kangaroo isn’t it ?
If we reduce the range of the puzzle 135 to 10^38 using the Kangaroo algorithm and having the specified public key, how long will it take to obtain the private key of the puzzle?
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Today I am uploading 400 million addresses list, which u guy can use with bitcrack pinkachunka ver, and their method to find puzzle 135, these list I generate with manual calculation as per kangaroo method, and believe could find key better then 1 key by rckangaroo etc
Let me up upload list rest discussion how to use later
Let me up upload list rest discussion how to use later
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Simple calc
Any report bitcrack or similar when u set from end bit range it's tell u how much time, resulted multiple thousand years,
And actually you see difference from 67 to 69 within 1 year 3 keys found , and most some individual with 1 or few one GPU, it's mean clear your thoughts not calc
Simple using these gpu with formula or strategy can reduce multiple years to few months,
As I stated before 71 puzzle could be found with 1000 gpu max 7 days...
If you have less GPUs you can try to find puzzle 135 with my strategy,
It's not mean
Any report bitcrack or similar when u set from end bit range it's tell u how much time, resulted multiple thousand years,
And actually you see difference from 67 to 69 within 1 year 3 keys found , and most some individual with 1 or few one GPU, it's mean clear your thoughts not calc
Simple using these gpu with formula or strategy can reduce multiple years to few months,
As I stated before 71 puzzle could be found with 1000 gpu max 7 days...
If you have less GPUs you can try to find puzzle 135 with my strategy,
It's not mean
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
In other words, is the ownership of the one who finds the key second (from the transaction) legitimate? My subjective opinion is no. Since this does not meet the main purpose of the puzzle (testing the security of keys) and such a condition for acquiring ownership of the reward is not explicitly stipulated by the creator of the puzzle.
This is a loophole in the puzzle's design, not a flaw in Bitcoin itself. The solver’s failure to protect their claim (e.g., by using tools like Mara or broadcasting with high fees) could be seen as negligence in a competitive environment. This ambiguity is why clear rules (or better puzzle designs) are needed. Without them, the "law of the jungle" (or in this case, the law of the mempool) prevails.
The creator’s statement clarifies:
https://bitcointalk.org/index.php?topic=1306983.msg18765941#msg18765941
The puzzle is a measuring instrument for the "cracking strength of the community."
It rewards brute-force tools (like the "Large Bitcoin Collider"), not mempool-sniping bots.
There’s no mention of RBF, transaction racing, or ownership transfer via mempool spies.
This implies the creator intended the reward to go to whoever cryptographically solves the key and not to opportunistic bots that exploit transaction propagation.
The creator could argue:
The bot did not solve the puzzle as intended.
It exploited a loophole (mempool snooping) unrelated to cryptographic security.
This violates the spirit of the experiment (transaction racing).
If the creator’s identity is known, they might try to argue theft under "unauthorized access" laws but this is untested.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
For the remaining unsolved lower bitlength puzzles the solver has to use non-public mempool with so far the only easy public service at slipstream.mara.com OR the solver is a complete idiot as was the case with puzzle #69.
Any solver of puzzles #71, #72, ... which are not multiples of 5 have to be mined from non-public mempools. Period!
Solvers of remaining puzzles which are multiples of 5, i.e. #135, #140, ... #160, don't necessarily need non-public mempools and should be fine to broadcast their puzzle withdrawal transaction publicly. Though it doesn't really hurt to do it via slipstream.mara.com, too. I'd consider it safer that way.
It's funny how some dudes here don't seem to understand how RBF works and that basically all mining pools have an economic incentive to have FullRBF enabled by default. Therefore you can't prevent that your transaction gets replaced as long as the replacer follows RBF rules. You can't opt-out RBF successfully anymore. Period!
Anybody who doesn't understand this, shouldn't play with solving #71+, just don't come later and cry you've been robbed by bots. DYOR!
Any solver of puzzles #71, #72, ... which are not multiples of 5 have to be mined from non-public mempools. Period!
Solvers of remaining puzzles which are multiples of 5, i.e. #135, #140, ... #160, don't necessarily need non-public mempools and should be fine to broadcast their puzzle withdrawal transaction publicly. Though it doesn't really hurt to do it via slipstream.mara.com, too. I'd consider it safer that way.
It's funny how some dudes here don't seem to understand how RBF works and that basically all mining pools have an economic incentive to have FullRBF enabled by default. Therefore you can't prevent that your transaction gets replaced as long as the replacer follows RBF rules. You can't opt-out RBF successfully anymore. Period!
Anybody who doesn't understand this, shouldn't play with solving #71+, just don't come later and cry you've been robbed by bots. DYOR!
I don't understand. What is the difference between any puzzle and these that are multiples of 5?
In case you solve any of the puzzles from 71 to 134, you must consider several precautions to avoid being robbed by automated bots.
I understand well how the public mempool works and how transactions function. I've read through the entire thread and I understand the risk of being front-run by bots when transfering funds.
This is the first time I’m seeing someone mention that “solvers of remaining puzzles which are multiples of 5 don’t necessarily need non-public mempools and should be fine to broadcast publicly.” I don’t understand what difference the puzzle number makes - whether it's #61, #71, #82, etc. And specifically, what makes special the puzzles that are multiples of 5 - like #85, #100, #105?
Don't trust online claims, especially in the digital currency space, where scammers are everywhere.
Puzzle 71 has been the subject of three or four months of global effort since the solution of Puzzle 69, but the private key hasn't been cracked. Can you believe your funds could be stolen by a so-called bot within a minute of your transfer? Bitcoin's most important principle is decentralization. Even if you're transferring funds publicly, as long as you use the highest transaction fee, miners around the world will rush to confirm your transaction. This is the essence of Bitcoin's decentralization and security. What's there to worry about? You can claim your winnings in under a minute. If Bitcoin were so easily hackable, it would have collapsed long ago.
Remember, anyone who asks you to submit your transactions to a private mining pool is likely a scammer. Even if the private mining pool is a large company, what about their employees? Anyone who handles your transaction information could try to steal your winnings. Think for yourself.
You keep repeating the same thing, either you're the bot owner waiting in ambush, or SimonNeedsBrain
Nice try Diddy LOL, can you share your bot with us?
This is hilarious! If I knew how to use a bot like this, I'd have already cracked dozens of Bitcoin addresses. I'd probably be on vacation in Hawaii.
Don't you think that asking you to give them your transaction data is essentially like saying, "Hey, give me your private key."?
You guys are so technically proficient, do you think private mining pools are any worse than you?
You claim you crack Bitcoin wallets and have lot of money, and enjoying time n money
Here is simple example and test
You should create 71 bit range address
Put their 1 btc
Post address here, and announce your destination address where you will transfer your 1 btc full or partial btc after 3 hours, using ur secure mempool tx, remember no one have ur pvkey,
After play this test you will learn lot of things, when bots will pickup before go to your destination address
If you successfully transfer your fund to your des address , whole forum will learn from you
Come and play And proof your simple tx by mempool
After 12 hours
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Suggest me free ftp
Where I upload addresses list about 400 million addresses, for puzzle 135
Where gpu holder act open pool for bitcrack run to find 1 address and win 1 btc
Where I upload addresses list about 400 million addresses, for puzzle 135
Where gpu holder act open pool for bitcrack run to find 1 address and win 1 btc
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
ok!! best set up for 4090 and 5090?
?
-b 170 -t 256 -p 4096?For 5090, if no fault, then add 32 in 4096 and test with every time by adding 32 till it crash
You will reach maxmium speed of you 5090
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Ever gpu have their own structure, every need to set their b t p
It's like load design as per country state cities
Wrong set b t p, u will waste resources and missing keys
It's like load design as per country state cities
Wrong set b t p, u will waste resources and missing keys
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Thanks for the tip! Quick question — wouldn’t it be easier to just use RTX 5090 or 4090 GPUs instead? They’re more stable and probably easier to tune, right? Or does the H200 NVL have big advantages despite the tricky tuning?
In my view h200 betterIf u r using 5090 -b is 170
Rest t and p adjust as per test
But h200 have 140gb ram, which can be used to make ur finding spot big definitely in puzzle 135
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Bro Tried all these configs — all crash with too many resources requested for launch
/bin/cuBitCrack --keyspace 5206e53083080a29e7:5206eef59f4d2c09e8 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU -b 132 -t 256 -p 6048
[2025-08-04.22:05:51] [Info] Compression: compressed
[2025-08-04.22:05:51] [Info] Starting at: 00000000000000000000000000000000000000000000005206E53083080A29E7
[2025-08-04.22:05:51] [Info] Ending at: 00000000000000000000000000000000000000000000005206EEF59F4D2C09E8
[2025-08-04.22:05:51] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2025-08-04.22:05:51] [Info] Initializing NVIDIA H200 NVL
[2025-08-04.22:05:51] [Info] Generating 204,374,016 starting points (7796.2MB)
[2025-08-04.22:06:30] [Info] 10.0%
[2025-08-04.22:06:31] [Info] 20.0%
[2025-08-04.22:06:31] [Info] 30.0%
[2025-08-04.22:06:32] [Info] 40.0%
[2025-08-04.22:06:32] [Info] 50.0%
[2025-08-04.22:06:32] [Info] 60.0%
[2025-08-04.22:06:32] [Info] 70.0%
[2025-08-04.22:06:32] [Info] 80.0%
[2025-08-04.22:06:33] [Info] 90.0%
[2025-08-04.22:06:33] [Info] 100.0%
[2025-08-04.22:06:33] [Info] Done
NVIDIA H200 NVL 19244 / 143156MB | 1 target 3079.91 MKey/s (11,444,944,896 total) [00:00:01]
It's mean your device max support -t 256 /bin/cuBitCrack --keyspace 5206e53083080a29e7:5206eef59f4d2c09e8 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU -b 132 -t 256 -p 6048
[2025-08-04.22:05:51] [Info] Compression: compressed
[2025-08-04.22:05:51] [Info] Starting at: 00000000000000000000000000000000000000000000005206E53083080A29E7
[2025-08-04.22:05:51] [Info] Ending at: 00000000000000000000000000000000000000000000005206EEF59F4D2C09E8
[2025-08-04.22:05:51] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2025-08-04.22:05:51] [Info] Initializing NVIDIA H200 NVL
[2025-08-04.22:05:51] [Info] Generating 204,374,016 starting points (7796.2MB)
[2025-08-04.22:06:30] [Info] 10.0%
[2025-08-04.22:06:31] [Info] 20.0%
[2025-08-04.22:06:31] [Info] 30.0%
[2025-08-04.22:06:32] [Info] 40.0%
[2025-08-04.22:06:32] [Info] 50.0%
[2025-08-04.22:06:32] [Info] 60.0%
[2025-08-04.22:06:32] [Info] 70.0%
[2025-08-04.22:06:32] [Info] 80.0%
[2025-08-04.22:06:33] [Info] 90.0%
[2025-08-04.22:06:33] [Info] 100.0%
[2025-08-04.22:06:33] [Info] Done
NVIDIA H200 NVL 19244 / 143156MB | 1 target 3079.91 MKey/s (11,444,944,896 total) [00:00:01]
Now expand -p 6048 to on word
-p 6048 + 64. Or 32 every time test with add into -p 6112
When last stop that time just minus 32 for get final -p value workable
By these setting u will get highest speed print ur last final value of -p