Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 13. (Read 245915 times)

No, the speed per Nvidia GPU is real, as I wrote, this speed-up it is not "skip-hash". The speed GPUs run at, such as 6800 Mkey/s per RTX 4090 at full 100% power limit, is not achieved by skipping anything. It is a real hash reached by heavy CUDA optimizations I did. Full keys are being checked at this speed. My version can go even normal one-by-one scanhash with 1 stride at this speed just as original Bitcrack did without skipping anything.

I heavily modified Bitcrack, did a lot of work, in a way that it is only loosely based on it now. What my experimental version does is, when running in "skipping approach" and "forced pattern(s)" mode, it first selects hex private key candidates based on criteria being set prior to start, and then it fully hashes only those at full speed on respective GPUs in the given range, just as if it was a normal scanhash, but being done on selected keys only, instead of stride by 1 mode. Everything is done in real-time on GPUs, the time consumption of ruling out and selecting private keys in pre-selection CUDA kernels based on criteria is negligible, usually less than around 1% of the speed of each scanhash cycle. When candidates are selected, they are fully hashed and checked at real hash GPU speed, as was said.

Anyway, about this approach, simply my idea behind this experimental puzzle private key finder is that I am not looking at a given private key range as a hexadecimal representation of a number, and instead it is seen as a set of '0..9' and 'a..f' characters, numbers, and letters - a string - more appealing and nicer to the human brain.

Yeah, I realize it may seem pretty ridiculous at first glance, to work with it like this, but well, I like things like that.
I call it cherry-picking from a cake approach.

It is much more fun, but what is more important is that it also adds real effectiveness to search of lower bit BTC puzzle keys.
I mean, there is no reason to compute something and waste computing resources on something that will never lead to a desired solution.
Right? Or is it?!? No, it is not.

Let's think, will the private key (the ending part) of #67 contain only numbers "0x41285418271284394" or only letters "0x(7)CAFECDBCAFEFCABD" when looking at it as a string of characters?
Will it? A randomly generated private key from BTC puzzle will be like that? No!
It is so unlikely that I would even dare to bet my own life on it that no. No way!

So, does it make sense to compute priavte keys that are like this in one-by-one scanhash with 1 stride? No, it is a waste of GPU computation resources.

When searching for #67, any private keys of this sort can be completely ruled out and not computed at all.
As there is no reason to fully compute and check them, they will never ever lead to the right solution, never will they lead to the private key for BTC puzzle #67.

And this is what this approach is about. Just fine-tuned by far more parameters than in this simple example. My reason for this approach is to reasonably rule out as much as possible improbable private key candidates, to balance out the very low count of GPUs I own, to save on every possible hash, and to save on every possible computation that will lead nowhere, to save where I can, in hope of cutting computation times, such as in the case of #67, from hundreds of years when what it would be if it was done in a regular 1-stride scanhash to something reachable in my lifetime, ideally in years, maybe months, with some luck when doing this "skipping approach" and "forced pattern(s)" mode in my experimental solver.

My approach is just like that, I just try to do it in more sophisticated way. Such as, in the case of #67, my experimental version of Bitcrack can be ordered, based on parameters prior to start, to do all private keys from a given range, but forced to contain, looking at the private key as if it were a string of characters, for example this:
---
At least one "letter-letter" next to each other anywhere in the string, at least one number "5" anywhere, but not more than 3 occurrences of number "5" anywhere, at least 3 times "any-number" anywhere but lower than <8, at least one occurrence of "D" anywhere, and must not contain any occurrence of "letter-letter-letter" or more occurrences, no number "7" anywhere in the string, etc., etc.
---
My Nvidia GPU solver does things like that, as was set selects candidates in the given range, real-time. And then it goes, full scan-hash cycles, at full GPU speed, but only on private keys that meet given criteria untill end of given range is reached.

Yeah, this cherry-picking from a cake approach is still based on luck, but I try to fine-tune it by far more parameters and far more probability approaches I am experimenting with all the time, with ways that appeal to me as likely, as the ones that could lead to private key of low bit BTC puzzle wallet address.

As I already said, ruling out key candidates like that, depending on how many elimination parameters and patterns are being set, results in huge speed-ups. These are those "skip-hash" speed-ups; these can be in tens, hundreds, or even thousands of multiples of the original speed of the device, but naturally, depending on parameters greatly increase the risk of skipping the right solution.

Unfortunately, there is no other choice to me than to risk it with fine-tuned "skip-hash", as I don’t have thousands of GPUs in a hall big as a football stadium to solve it in some reasonable time using one-by-one scanhash with stride 1, I have only a few Nvidia cards, so I must somehow, in a reasonable way, in a reasonable balance between risk, probability, cut solving times from hundreds of years to perhaps months, weeks, or maybe even days with some luck, using various parameters to select private key candidates in my experimental solver in effort to pick cherries from a cake.

That is all there is to it. No mystery.

Your experimental Bitcrack sounds like a mix between a turbocharged race car and a wandering philosopher pondering randomness.

A truly random 66-bit sequence doesn’t have intrinsic “strangeness”, it only appears odd because our pattern-seeking brains demand order in chaos. By defining arbitrary rules like skipping keys with "too many letters" or "too many numbers," you're essentially projecting human biases onto randomness. This is akin to looking at clouds and swearing you see a unicorn, then deciding to search only for dragon-shaped clouds.

From an entropy perspective, eliminating "unlikely" candidates assumes that randomness obeys your intuition. But randomness doesn’t care. If a 66-bit sequence consisting solely of numbers (or letters) bothers you, consider that each sequence, however "weird," has an equal probability of occurring.

Also, rejecting keys based on patterns risks skipping the correct solution entirely.

Your argument about pre-selecting hexadecimal candidates is clever but flawed. If you switched to a different numeral system (e.g., base-7 or base-12), would your rules still apply? Likely not. Randomness transcends such superficial constructs, it’s unbiased by our alphabets or cultural biases.

The promise of skipping unlikely keys sounds appealing, but at what computational cost? Verifying each candidate against arbitrary rules before hashing adds overhead. Imagine a treasure hunt where you ignore maps with "ugly handwriting", you might end up missing the actual treasure! Statistically, your forced exclusions might eliminate enough keys to make computation faster, but the cost is an increased chance of never finding the right key.

Finally, the "fun" element is subjective. Sure, tuning parameters for forced patterns might feel rewarding, but in the cold, unforgiving realm of cryptography, fun doesn’t find private keys = > efficiency does.

Aham. Is that the speed of actually computing and hashing a key, or it's the speed of "hey, let's skip some keys because I think they look unlikely" or "hey, let's use endomorphism even though it's useless for searching a range"?

Because the first wall of real speed is actually computing a full X and Y (to have the parity) so you can correctly go to next step (hashing). If you skip private keys (or use derived X's via endo) you cannot include them as computed, right?

Also, what does it mean to you that a random sequence of 66 bits is "strange"? Letters and numbers are just an alphabet that maps some short sequence of bits to a symbol, what if we change the alphabet, will you then discard the new "letters series" and "too many numbers in a row"? See, you can always arrange something that's random to look like it's "too strange to ever happen", if you simply change the higher-level alphabet. A proper entropy test should be done at binary level, but IMHO it's just a waste of computing time with no real benefits (low-entropy strings are extremely rare to bother about them, for example only 66 strings that have a single "0", out of 2**66 strings).

It would be an advantage for the community if you share your projects now so that we can all work on it together and expand it. Think about it and publish your project on github. Many would thank you very much and it could give us a lot of joy.

For low-bit BTC puzzles, I use my own experimental solver version that I wrote in C++ loosely based on Bitcrack, but with heavily optimized CUDA kernels where its sequential scanhashing is from 80% up to 120% faster, depending on the Nvidia GPU model and architecture, than the original Bitcrack.

My Nvidia GPUs go like this with it, depending on card OC, at 100% power limit up to:
GTX 1080 Ti, 950 Mkey/s
RTX 2080 Ti, 1800 Mkey/s
RTX 3090, 3700 Mkey/s
RTX 4090, 6800 Mkey/s

In addition to significant optimization speed-up per GPU, my version has also modified scanhash search logic to be able to run in "skipping approach" and "forced pattern(s)" mode, where the search is sequential but only on given data candidates. In this mode it doesn’t go one-by-one, one key after another with 1 stride, but instead keys are preselected in real-time over and over again on the fly during running, eliminating certain patterns from hexadecimal "strings" being based on tune-able parameters.

I realize the fact that BTC puzzle keys were generated using a Deterministic wallet randomly, meaning there is no real pattern behind them to search for; however, the purpose of my version of Bitcrack is something else. It is to eliminate very unlike private keys, not compute something that is very unlike. Such as in a 17-character hexadecimal long key range, the ending of the BTC puzzle key #67, which is randomly generated, it is so unlikely that it will contain only "letters" (0x6AFDCBEDCABEFDA) or only "numbers" (0x40124579147074121) that you can put your hand in the fire for the fact.

This is what my own version of Bitcrack can do on my GPUs. It can be ordered by various parameters prior start to skip, or oppose forcibly require, or both at once unlimited times by parameters, puzzle keys that meet fine-tunable criteria, for example to skip numbers only ('0..9') or letters only ('a..f'), skip hexadecimal "string" candidates that go one after another, exact "strings" 0xFF, 0xAAA, 0xCCCC, or exactly unknown "strings" letter-number-letter, or letter-letter-number-number, whatever of this letter-number sort, anywhere in hexadecimal representation of key at any position and any offset, even on multiple locations or unknown locations and offsets, or reverse it can be ordered and forced to do only wanted "strings", various thresholds, equal, less, higher, non-equal to whatever parameter set and much more.

I already described it in my previous post some time ago:
https://bitcointalksearch.org/topic/m.62088633

As I said, I fully realize puzzle keys are in fact random, but to do it this way is still much more fun than by simple one-by-one, 1 stride scanhashing.

I use even more approaches than these, in my experimental solver I simply try algorithmically manipulate chances, moving chances of finding a solution to my side, and skipping non-interesting candidates that are very unlikely without any hashing to balance the risk of skipping the right solution and to balance out this way a low count of GPUs I have. As ruling out key candidates like this results in hardware computational speed-ups that are tens, hundreds, or even thousands multiples of the original speed of the device when searching whole/given range, but naturally depending on parameters greatly increase the risk of skipping the right solution.

Anyway, if I solve some low-bit BTC puzzle with my version and finally the price will arrive to my BTC wallet without being robbed during cashing-out by a bot run by a thief, I will publish my version of Bitcrack, including source code, so anyone can have fun with it then.

Got it, Thanks man.

Since you have a different network ledger (chain), it won't work.

Totally different chain between BTC and wrap BTC (etherium chain / BNB chain). wrap BTC is like you create token on etherium chain or BNB chain and backed with USDT with current BTC value.

I use VanitySearch256.exe.

(Additionally, it has a math calculation that I developed.)

---

Hello friends,

Since I don't have any information and I don't know how it works. I want to ask a question to those who know.

Example: After importing metamask with Private Key 67, when we convert btc to usdt in places like swap (PancakeSwap), will this transaction be visible in the mempool?

Is there anything wrong with doing this?

I use Bitcrack2 for solving the #67 Puzzle. I think its the best for this.

Hello everyone, may I ask what program you are currently using to solve puzzle 67? Please reply to me below. Thank you.

Greetings to all,

I have good offers.

Friends who find the prefix - 1BY8GQbnue and 1BY8GQbnueY, write here and send it for each prefix, when I find the wallet. I will make a separate payment for each prefix.

Like friends like cctv5go and benjaniah.

Thank you in advance.

here i posted something maybe usefull for all of you,
sn hands writen Readme and license files include his first ver of mining and wallet
7 jan 2009

https://bitcointalk.org/index.php?topic=5512858.new#new

---

regarding 18k exposed brain wallets
https://www.blockchain.com/explorer/addresses/btc/11121ioKu4MCB1LLzPF98AVtzFsEg7UYKm

peoples still hunting those addresses by incoming tx, daily bases, as this just before few min pass in my eyes, as i load that list pk after 6 years
cancel and exist from these

Here's a guide to who wants to use Mara, for people who didn't know:

https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/04_2_Creating_a_Raw_Transaction.md

I will also use Mara and will report back here in detail if I ever solve a puzzle in my life :-))
 

I didn't deleted any of my messages what are you talking about?

Maybe you are confused there is another user who tested Mara it was WanderingPhilospher

They are secure, but these puzzles are not, it is not the type of address but the problem is the security of your private key, that is the purpose of the creator, to test the robustness of bitcoin using a series of problems with exponentially increasing difficulty.

(First of all, I don't understand why you deleted the message.)

You said that you tested Mara and stayed for 2 days because of the fee.

After Mara sent the TX, it automatically started any block transaction. Without any mail or communication to Mara, the systems automatically did it.

The result is that MARA was tested. Fee is a good fee, for example, if we do it in the range of 1m-5m/sat, we can say that the result will probably be successful.

I wont say that my knowledge of crypto wallets is very high but I can only assume that this problem exists because these puzzles are all held in older crypto wallets that are only p2pkh focused?   So just doing something simple like trying to direct swap your BTC into another currency first before you try sending it to another wallet that you own probably wont stop the bot theft either.  Newer crypto wallet software however doesnt seem to have this problem since people make transactions constantly.   Interesting ideas though from the AI, might try to read more about lightning networks later.  My first thought was to just put all of the btc into a liquidity pool since that somewhat transforms your transaction immediately and then maybe you could just remove it from the same liquidity pool later using another wallet as long as that liquidity provider allows multiple wallets to connect to it.  Many liquidity providers dont allow multiple wallets from what I know about them though.  So you would probably have to do your own research and find one that does if you became the next puzzle solver.   

But if all legacy wallets have little to no security at all,  I agree with what most of you have already said that its probably hopeless and no way to move the funds.   I am just surprised by this because I thought most crypto wallet software also had options that stopped frontrunning attacks or any type of bot attack for that matter.  Usually such options would just enabled in the wallet settings with a checkbox next to them.  But I have only been involved with crypto for about 1 year so I still have alot to learn,  lol.   Just some of my random thoughts about the situation.  I am more of a crypto investor so I dont mess with coding nearly as often as a fulltime programmer would.    I was often trying to solve puzzle 66 though for about 3 months until that was solved so now I just keep trying to pick at 67 now whenever I have some free time.  I prefer to use python code mostly even though I realize that its not the fastest and its probably putting me at a major disadvantage.  I just overall find it easier to work with the different crypto modules or libraries in python compared to some of the other programming languages.

So, as far as I understand, MARA is the only place that provides this service and its tests are not clear, but it can manage the process best.

Mining your own block and making agreements with other BTC mining pools is a very tedious process.

After getting 1 confirmation, can the thief make changes by increasing the fee again?

Example;

I paid 1,000,000 sat fee, I got 1 confirmation in the block. RBF is also disabled.

Then can someone who paid 5 M fee change the transaction?

I said it as an alternative to MARA. if some day I solve one of those low bits puzzle i am going to use MARA but i am going to documented all the process properly.

What exactly don't you understand about mining and transaction priorization for a block?

Let's assume slipstream.mara.com works as intended. You submit your transaction to it and it will be held hidden and not visible in the public mempools. But of course your transaction fee competes with all public transactions available to mara.com and all hidden ones submitted to slipstream.mara.com. There's nothing fishy with that, totally basic facts.

That's all what you've cited in quotation marks says, nothing more, nothing less. It's just that YOU don't understand basic mining principles and prefer to chime in to all the stupid statements by zero-merits loudmouths here. Pathetic!


What a pile of LLM bullshit suggestions and absolutely none will help to secure a withdrawal of those low-entropy private key puzzles like #67. You would need to be very lucky that merely within very few seconds after you submit your puzzle withdrawal publicly a block is mined and better another one soon, too.

But because mining a block is a random process, you can't rely or hope that your transaction will only live for few seconds in public mempools of miners before a block confirms your transaction. It can take any time between a few seconds or maybe an hour until a confirming block is mined. The roughly ten minutes intervall for new blocks is an average over a difficulty period of 2016 blocks.