Bitcoin puzzle transaction ~32 BTC prize to who solves it

[MrGPBit]

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.

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.

[kTimesG]

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

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).

[nomachine]

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.

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.

[jareso]

...
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"?
...

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.

[Akito S. M. Hosana]

Here is the solution

Google has unveiled a new chip which it claims takes five minutes to solve a problem that would currently take the world's fastest super computers ten septillion – or 10,000,000,000,000,000,000,000,000 years – to complete.

https://www.bbc.com/news/articles/c791ng0zvl3o?xtor

 

[kTimesG]

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.

Yeah, this cherry-picking from a cake approach is still based on luck

Are you sure the cherries you're picking are not actually something around 99.999...% of the entire cake? And the remaining 0.000....1% are the excluded patterns? Because this is what some quick and dirty 9th grade combinational probability would indicate.

You are never seeing your so-called "letter and number" strings (basically hex representation of bytes) not because they can never happen, as you wrongly suggest, but because there are massively much more strings that are apparently scrambled (when using the same high-level representation alphabet). In reality, all keys have the exact same probability, no matter how they look like. Excluding keys based on a pattern would mean that randomness also has a pattern (the pattern of excluding your pattern, or a bias), which is a logical contradiction, because by definition randomness does not have any patterns or biases. So by induction, the initial hypothesis "some strings can't appear or are very unlikely to appear" is wrong, so why do it?

[BdMtFk]

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.
---

I kinda see your logic but it would likely skip the solution, look at this randomly generated (from *.pw/random/puzzle/67):
{
  1) 567f4d3ddd5b6d0df
}

Would this possible solution be skipped by your filtering process? Or I misunderstood the ruleset.

[sneeky777]

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.
---

I kinda see your logic but it would likely skip the solution, look at this randomly generated (from *.pw/random/puzzle/67):
{
  1) 567f4d3ddd5b6d0df
}

Would this possible solution be skipped by your filtering process? Or I misunderstood the ruleset.

Puzzle 110 and 115 would like a word with him about his rule set.

00000000000000000000000000000000000035c0d7234df7deb0f20cf7062444
0000000000000000000000000000000000060f4d11574f5deee49961d9609ac6

[jareso]

Rules of omitting or requiring certain "letters" and "numbers" from the hexadecimal key "string" I mentioned were examples to demonstrate what my experiential finder is capable of. I use various and different patterns and methods of this sort. I change them often, experimenting. That is the reason why I created my version this way, so private key selection can be manipulated based on given "string" criteria.

I needed to choose some criteria by which to manipulate odds and cut down BTC puzzle scanhash times from hundreds of years to something lower, something that can be done in months, weeks, or days, based on given rules, "skip-hash".

Is it rational from a mathematical point of view when speaking about any generic BTC keys?
No, not really at all. Is it ridiculous? Yeah, kind of to some extent, surely. And what?

I really understand everything you mentioned, I get everything. I knew it even before.
I have been programming since the 80s, I have (surprisingly) degrees in mathematics and computer science, and (this is very scary, LOL...) I have been lecturing those for quite some time in the past.
In the late 90s and early 00s, amongst other things, I worked on AAA game titles, programming 3D engines, game physics, logic, and visual renderings in times when it was pretty hardcore and a lot of things needed to be figured out and done "on the knee", not as easy as these days. And many other things related to the field up to this time.

I realize heavy storm clouds can sometimes resemble dragons, or sheep, or something creepy, depending on mood, as it is the way the human brain likes to make associations and tries to find patterns and see things where they are not really. Yes, of course.

Is my experimental Bitcrack version a scientific tool? No, no way. It never was. That was never the intention.

Is it a kind of tool where I can predict, bet, and try searching for private keys, looking at them as "strings" consisting of "numbers" and "letters" and based on given criteria, restrictions, and patterns, where I can experiment with various prediction and probability systems in it? Yes, this is kind of what it is.

Searching for a private key with it is based on luck, as was already told, it can be said "skip-hashing" depending on parameters, my way of picking cherries from a cake approach.

Is it rational? Well, it is my approach, be it rational or not, I still stand by my opinion that it adds effectiveness when searching for BTC puzzle keys. I repeat again - puzzle keys.
As this is what it is about, I do not care about common BTC private keys, generic BTC private keys. I care only about the low-bit BTC puzzle keys.
Yeah, I know they are random too, yes, yes, ... yes, I know that if they were in a different format it would be different.

I had to approach it somehow, so I chose to look at keys as hexadecimal "strings", simply like that, it is nice and appealing to see them as single characters, "numbers" and "letters".

As I already told, I don’t know exactly what BTC puzzle key #67 (the ending part) looks like, but I am pretty sure it doesn’t look like this, for example:
All characters of #67 are "letters"? No. All characters are "numbers"? No.
The first part of the key is only "letters" and the other part is only "numbers"? Or vice versa. No.
It is like exactly "letter-number-letter-number-letter-number..." till the end? No. No way, I would even put my hand in the fire that no. Yes, this approach is about betting on something and holding to it.
Etc.

I made my experimental finder this way basically because already solved puzzle keys are usually published in hexadecimal "string" format, and when I always looked at some already solved BTC puzzle keys, I told myself something like, ahhhhh... I knew that "EE" would be in it, or I thought there would be zero occurrences of "4" anywhere in this one, things like that.

Thus, I made myself a GPU tool exactly for that, so when I want, I can scan a given range fast on my few Nvidia cards using any sort of "string," "letter(s)," or "number(s)" criteria. Such as, I want to scan the given range but omit number "4" anywhere in the "string" I can, I want exactly 2 letters "EE" to be anywhere in it next to each other, I can, I want to have any unknown "letter-letter" anywhere in it, of course, I want to have an occurrence of exactly 5 unknown "letter" in it anywhere, no problem. I want it to skip all private keys containing more than the count 9 of any "letter" anywhere in the string, yes, or at least the count of 3 "number" that has to be lower than <8, sure, things like that, etc.
Any pattern, any sort, operators, conditions, any offset, anywhere, any count.

With this, I test my chances in ways I needed and I test various probability systems and approaches I like, new perspectives I try to figure out, I experiment - it is fun, and I hope for luck.

Anyway, what I wanted to say about it, I already said, speaking about it more again and again now would be going in the cycles round and round.
As I already told, if I ever solve the low-bit BTC puzzle with it and finally the price will arrive at my BTC wallet without being robbed during cashing out by a bot run by a thief, I will publish it, including the source code.

Till then I will be trying my luck with it.
I am pretty stubborn when I bite into something, be it rational or not, I don't care.

[kTimesG]

As I already told, I don’t know exactly what BTC puzzle key #67 (the ending part) looks like, but I am pretty sure it doesn’t look like this, for example:
All characters of #67 are "letters"? No. All characters are "numbers"? No.
The first part of the key is only "letters" and the other part is only "numbers"? Or vice versa. No.
It is like exactly "letter-number-letter-number-letter-number..." till the end? No. No way, I would even put my hand in the fire that no. Yes, this approach is about betting on something and holding to it.
Etc.

Let me summarize your entire approach:

- your program is 1% slower because you cherry-pick the cake
- the cherries are more than 99% of the cake (more like 99.999...9%)
- you lose the certainty of 100% of finding the key, it's now 99.999...9% certainty
- you believe this to be rational and to add effectiveness

I can give you billions of rules for exclusion:

- there's no way the key can be a square of a 33-bit number, right?
- there's no way the key can be a cube of a 22-bit number, right?
- there's no way the key can be a sum of Fibonacci numbers
- there's no way the key can be a power of, let's say, 7 (or any number at all, up to the limit that you consider it to be a really strange case, let's say, up to 1000)
- there's no way the key can form a triangle if you split it in 3 sub-ranges
- there's no way the key embeds some exact portion of pi's digits longer than 10 chars
- there's no way the key contains a single digit when converted to base N (choose whatever N you can think of)
- there's no way the key looks like a circle if you convert it to ASCII art
- etc, etc etc

All of these examples fail your current criteria because they look like exact random bits, but they are definitely something you should exclude.

The main takeover from what people try to argue is that you speak of risks vs betting vs whatever, but in reality you have a 1% slower program that excludes much, much less than 1% of the space that's searched, which if you properly think about, means it is not effective, but simply slower and with less benefits, not more benefits.

[bibilgin]

As I already told, I don’t know exactly what BTC puzzle key #67 (the ending part) looks like, but I am pretty sure it doesn’t look like this, for example:
All characters of #67 are "letters"? No. All characters are "numbers"? No.
The first part of the key is only "letters" and the other part is only "numbers"? Or vice versa. No.
It is like exactly "letter-number-letter-number-letter-number..." till the end? No. No way, I would even put my hand in the fire that no. Yes, this approach is about betting on something and holding to it.
Etc.

Let me summarize your entire approach:

- your program is 1% slower because you cherry-pick the cake
- the cherries are more than 99% of the cake (more like 99.999...9%)
- you lose the certainty of 100% of finding the key, it's now 99.999...9% certainty
- you believe this to be rational and to add effectiveness

I can give you billions of rules for exclusion:

- there's no way the key can be a square of a 33-bit number, right?
- there's no way the key can be a cube of a 22-bit number, right?
- there's no way the key can be a sum of Fibonacci numbers
- there's no way the key can be a power of, let's say, 7 (or any number at all, up to the limit that you consider it to be a really strange case, let's say, up to 1000)
- there's no way the key can form a triangle if you split it in 3 sub-ranges
- there's no way the key embeds some exact portion of pi's digits longer than 10 chars
- there's no way the key contains a single digit when converted to base N (choose whatever N you can think of)
- there's no way the key looks like a circle if you convert it to ASCII art
- etc, etc etc

All of these examples fail your current criteria because they look like exact random bits, but they are definitely something you should exclude.

The main takeover from what people try to argue is that you speak of risks vs betting vs whatever, but in reality you have a 1% slower program that excludes much, much less than 1% of the space that's searched, which if you properly think about, means it is not effective, but simply slower and with less benefits, not more benefits.

Bla bla bla bla...

How about saying something that will really contribute?

@jareso , yes brother. A different and nice idea. I have done it many times before, removing inappropriate letters and numbers etc. etc.

Friends, since you have accepted that this is a place to share information or ideas, shouldn't you respect the sharing or ideas made? (Does he need to be smarter than you?)

Everyone peels an orange differently and eats it, or they can eat it with the peel without peeling it.

So if you don't have "RESPECT" and "RESPECT for ideas", don't expect anyone to share anything with you.

If there is no mathematics, there is no programming!

[White hat hacker]

As I already told, I don’t know exactly what BTC puzzle key #67 (the ending part) looks like, but I am pretty sure it doesn’t look like this, for example:
All characters of #67 are "letters"? No. All characters are "numbers"? No.
The first part of the key is only "letters" and the other part is only "numbers"? Or vice versa. No.
It is like exactly "letter-number-letter-number-letter-number..." till the end? No. No way, I would even put my hand in the fire that no. Yes, this approach is about betting on something and holding to it.
Etc.

Let me summarize your entire approach:

- your program is 1% slower because you cherry-pick the cake
- the cherries are more than 99% of the cake (more like 99.999...9%)
- you lose the certainty of 100% of finding the key, it's now 99.999...9% certainty
- you believe this to be rational and to add effectiveness

I can give you billions of rules for exclusion:

- there's no way the key can be a square of a 33-bit number, right?
- there's no way the key can be a cube of a 22-bit number, right?
- there's no way the key can be a sum of Fibonacci numbers
- there's no way the key can be a power of, let's say, 7 (or any number at all, up to the limit that you consider it to be a really strange case, let's say, up to 1000)
- there's no way the key can form a triangle if you split it in 3 sub-ranges
- there's no way the key embeds some exact portion of pi's digits longer than 10 chars
- there's no way the key contains a single digit when converted to base N (choose whatever N you can think of)
- there's no way the key looks like a circle if you convert it to ASCII art
- etc, etc etc

All of these examples fail your current criteria because they look like exact random bits, but they are definitely something you should exclude.

The main takeover from what people try to argue is that you speak of risks vs betting vs whatever, but in reality you have a 1% slower program that excludes much, much less than 1% of the space that's searched, which if you properly think about, means it is not effective, but simply slower and with less benefits, not more benefits.

Bla bla bla bla...

How about saying something that will really contribute?

@jareso , yes brother. A different and nice idea. I have done it many times before, removing inappropriate letters and numbers etc. etc.

Friends, since you have accepted that this is a place to share information or ideas, shouldn't you respect the sharing or ideas made? (Does he need to be smarter than you?)

Everyone peels an orange differently and eats it, or they can eat it with the peel without peeling it.

So if you don't have "RESPECT" and "RESPECT for ideas", don't expect anyone to share anything with you.

If there is no mathematics, there is no programming!

Cryptographic hash functions are designed to be random and unpredictable. When you input a public key into the hash function, the resulting hash is a seemingly random sequence of numbers and letters.

Even a tiny change in the public key (e.g., flipping a single bit) will completely change the hash due to a property called the avalanche effect.

This randomness ensures there is no discernible pattern in the hash.


When someone makes a statement and if it does makes sense it doesn't mean it's disrespect.

[bibilgin]

Cryptographic hash functions are designed to be random and unpredictable. When you input a public key into the hash function, the resulting hash is a seemingly random sequence of numbers and letters.

Even a tiny change in the public key (e.g., flipping a single bit) will completely change the hash due to a property called the avalanche effect.

This randomness ensures there is no discernible pattern in the hash.


When someone makes a statement and if it does makes sense it doesn't mean it's disrespect.

It does not mention anything about cryptographic hashing. (@jareso)

I think it will not start with "5FFF" and I designed my software accordingly, it just says.

That's why it is an idea, I said it should be respected.

Let me give an example about cryptographic hashing.

If you are looking for another wallet with similar first 10 digits of a wallet starting with 1BY8GQbnu.

You will definitely find between 7800000000009990000 and 7860000000000990000 above or below.

Under normal conditions, a number like 2**56 - 72,057,594,037,927,936 is equal.

But why is there definitely 59,999,999,991,000,000?
Why is it definitely between 7800000000009990000 - 7860000000000990000?

This is also an idea, you can call it ridiculous, a fantasy, wrong or something else. But it is an idea.

[White hat hacker]

If I find private keys with similar patterns like "ddd," "eee," "fff," and so on, which one should I choose? There will be hundreds of such patterns, and so on.

Even though it's an idea it doesn't make any improvement. If you Brute force all the similar patterns, It will just make the code even more slower and there will be no guarantee.

[BdMtFk]

Bla bla bla bla...

How about saying something that will really contribute?

k*G did contribute by showing jareso the potential flaws in his way of iterating through the keyspace and skipping the secret that solves #67.

He comes off incredibly dismissive but probably because of the dozens of users who have claimed they found a magical way of solving the puzzles.

Funny enough, #67 might suffer the same fate as #66 and not solving it would be a blessing in disguise.

[ElonMusk_ia]

#67 6d6exxxxxxxxxxxxx

[bibilgin]

k*G did contribute by showing jareso the potential flaws in his way of iterating through the keyspace and skipping the secret that solves #67.

He comes off incredibly dismissive but probably because of the dozens of users who have claimed they found a magical way of solving the puzzles.

Funny enough, #67 might suffer the same fate as #66 and not solving it would be a blessing in disguise.

My brother, you are right, you are right.

But here is the point where people who are knowledgeable or wrong about this issue come together. You don't have to explain something or write different sentences.

Instead of belittling a person, you can ignore it.
Does anyone know anything 100%?

Sorry, we interrupted our topic a bit. Good luck and open minds to everyone.

[kTimesG]

Bla bla bla bla...

How about saying something that will really contribute?

If there is no mathematics, there is no programming!

Since when pointing out obvious flaws is called disrespect?

Do you really want a mathematical proof that what I said made sense?
It is obvious that any patterns you can think of are a very minuscule part of the remaining "non-patterns". This is simple combinations formulas, the proof is immediate.

Does it make sense to run a program 1% slower while still checking 99.99% of the key space?

Answer: no, assuming that the key is found, the time required will be LONGER, simply because 1.0 is larger than 0.01. If this is something he refuses to understand, it's his problem, not mine.

It's a delusion to think that excluding some keys speeds up anything, it's a fallacy. It is not disrespect to have the truth shown in your face.

Anyway, it's in everyone else's benefit that we shouldn't even point out this flaws, correct? Let them run the slow program while we laugh.

[WanderingPhilospher]

Whew...lot of crazy posts on here lately lol. Crazy, funny, witty, I've enjoyed the reading!

I've not really been working on anything new, just tinkering with 135 and Kangaroo. Nothing to report really as far as faster or efficiency. Up to about 8,000 MKey/s with a 4090.

What I have accumulated whilst tinkering, is a lot of Wild points, DP 32, trailing 0s.

I have at least 64 each DP 32s, in each 68 bit range, starting from 135s public key.

So, public key +100000000000000000, all the way up to:

......
12BB7400000000000000000
12BB7500000000000000000
12BB7600000000000000000

I guess if anything, I set out to figure out how to set better, wider or longer traps, however you want to look at it.
I honestly just have it running in the background on 2 machines, linked to a server that's collecting the points.

I've rented out most of my other GPUs, while I figure out the next plan of attack, if any. But that won't be until after the new year.

For anyone wondering what my DP 32, trailing 0s, points, look like, or what I mean by it:

Code:

58A7BCDDBEF288CED5B91905200000000
BA827FA224D37396FA4C2EC1D00000000
5DCDBC96C8C63DDC66475B46400000000
227F6C3C7B9FB7F1E117E1FD900000000
377FDBB7F595F021874A70EBF00000000
F6349AFC98BE5F91F929A07A900000000
39F64E774D95CC51BDFD4691800000000
9073BC306B6E85634B0F4864900000000

Nothing spectacular or new on my end.

Keep grinding and thinking and tinkering with different programs, maybe one of you will have some breakthrough. I applaud everyone's efforts, even some I see as futile...including some of my own lol.

[fahri.hk]

Hello everyone. let's say I found a solution
is there any chance to safely withdraw money please anyone who understands answer. Thanks in advance
I've been working on this puzzle for 9 months now.