Basically you need to rewrite all the code for this... I did my own approach and it was slower than my current bsgs version.

The Ultra-Lightweight Database version of (mcdouglasx) may solve the speed on bsgs, but it need to pre-process a lot of points near of 2^50 points just to get the same speed of my current version of BSGS on github. (such  pre-process task may need some months alone).

So extending my answer to your question, you need to understand the algorithm  mcdouglasx and rewrite the code, there is NO an easy way to do that, once that you edit that code, you need to pre-process the points up to 2^50 or something like that just to get the same speed of current keyhunt.

@mcdouglasx i watnt to write my toughts onthis topic, because it caused debate and friction between you and other users. I want to order my ideas and write here down for all of you. I am going to do that later.

add



default value is 0x100000000 (32 bits)



Did you know if your changes also compile on Linux in a Non-MAC hardware?


There is as brand called OSX: https://github.com/albertobsd/keyhunt/tree/osx

Where all changes for mac versions should go to no affect others versions, that is only if your changes affect the compilation for Linux.

I haven't checked it yet, I've been busy.

https://www.passwordstore.org/

This password manager for command line use PGP for it all passwords/seeds/privatekeys/ even text files are encrypted with your PGP key.

So to keep this safe i have 2 hard copies of my PGP aditional to 2 backup files

Open source code It is written in that way for review.


There is going to be always programs more stable than yours. Python maybe stable... but faster? NO

And yes almost all users here can write some code in slow python, so please come here when you write something more useful than available options on github

You still need to use range 135...

This is what the program actually do, if you have targe key it create N amount of keys arount that key like a target.

Example for -n 10

All those subtracted keys are near the target key and limited by the range that you select -r  or -b

It was an experiment, but it don't bring any speed boost as I expected so please don't use it.

If a pool is properly developed this should never be a problem, the users will no have way to use the server as oracle, and the users can't lie about what they scan or what they don't scan.

Looks that somebody just offer a single satoshi: https://mempool.space/address/1AkitoSMHosanaQuantumRigxxxunWXyG


HODL!!!

There are so many conspiracy theories driven by the frustrations of those users.

Somebody said that there is no enough power to solve those challenges. I have some word for them, cloud-computing even if that was used without the permission of the owner of those servers, the computing capacity is there and exist without any doubt.

Some other claim about not wasting or move that balance, Maybe they are waiting to bitcoin new highs to recover its investments.
Maybe there are private sponsors paying for that computing power we don't know.
Maybe is some one with a lot of GPUs in a country where electricity is cheap, stolen or free. (I've been reached by people working in gas and oil industries that are trying to pivot to crypto using their excess of energy available from burning gas)

There is a endless of possibilities about the reason of not moving that balance.


Hahaha and you seriously expected that him is going to answer you?
He is not going to reply to ANYONE....

Just imagine having access to thousand of bitcoin and you create some challenge like this, and you start to replying to random strangers over internet, they may try to trick you to enter some links and they will try to record your IP, your browser vulnerabilities and other nasty stuff...

Please you mention that you are based in logic to reach some fallacy conclusions, and you don't see the logic to see that the author of that challenge is not going to answer to anyone?

Current Slipstream minumun fee is 10 Sat/vB to be accepted, 100 sat/vB is ten times that amount it is excessive, right?


Did you know how signatures Works? Once that you signed one, you can't change the fee amount, Now 1000 sat/vb That is ten times excessive from your previous suggest of 100 sat/vB


I never said that, i said that it was the only commercial option available, and its trustfulness need to be tested...


Awasome!! Hope your Rigs are still OK.

To be honest with all of you I am also taking some break from answering post messages, emails and telegrams, since the last two puzzles were solved I start to receive an incredible amount of new emails and messages of all kind all of them asking the same again and again... (I am tired of this repetitive shit)

I am going to keep reading the relevant messages in silent.

I am learning GPU CUDA development at deep level. I am also working in some cool ideas and trying to optimize some things.
Currently i have two jobs to cover my daily spends so i have less time to lose with noob messages. But I am still open to new ideas/messages as long those have some of background research and not just assumptions based on "I think that", "I believe that..."

1. Any wallet is OK to create the Transaction, BUT NOT Broadcast it.
1.1 NO, Even with RBF Off the TX is still replaceable (This depend of miners and their core configurations to accept or not Full RBF)

2. Yes I  said en point 1 Any wallet that allow you see the TX without Broadcast it, this mean that the TX must be signed.
2.1 Salt? What are you talking about?

3. Mining a block by your self or asking to a miner to include the TX in a block BUT WITHOUT BROADCAST it. The available commercial option to do this is Marathon slipstream Service. (But it wasn't tested for this yet for widely known weak addresses.)

I did some test with my laptop with an processor (11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHz)

I query 134217728 random values to the bloom filter already created.

Those 134 Million queries take 5.316306 seconds = 3.960956633090973e-8 seconds per item, so it is 39 Nano seconds per item
or a speed of 25 Million queries per second (25,246,426 queries/s)

Also mention that those 134 Million items give me 30 collision on the bloom filter (Possible false positives) those need to be handled:
- Checking next patter value in out sample if this exists
- Or checking the current item againts your Ultra-Lightweight Database

I also did a test creating keys and creating the bit array (not string)

So in my test i create 4* 2^33 keys ( 8589934592 ) and also create the bit array in the same time it takes 7100 seconds, that is an speed of 4839399 keys per second, but this was using 4 threads, so speed per core is 1,209,849 keys/s (Again the time include creating a bit array of the parity of the X value).

To for this CPU it would take near 0.165 seconds create the 200 thousand keys and their respective bit array. (This time don't include search of patterns or queries to bloom or database)




My previous test database was a database of 17 * 2**33 keys (146028888064)
So 200K times that number is 29205777612800000 keys that is great than 2**54
and that is just to get the same speed, or Am I wrong?


I hope my previous test give and idea of the expected speeds of the code already optimized for your Database:


What do you mean with this? What is the criteria for those  additional patterns ?

Can you elaborate a lite more?

About the size of 15 bits it is 2^15 = 32768 that means that in average you are going to find one match each 32768 keys

for each new item you have a probability of 1/(2**15) that is your pattern

So what is the probability of not finding a match in 200K items

P(NOT finding the item) = 1 - P(Finding the item)

P(NOT finding the item) = (1 - 1/(2**15)) = (2**15 - 1)/2**15

P(NOT finding the item in 200K) = ((2**15 - 1)/2**15 ) **  200000 = 0.002234

That is a probability of 0.2% that means that 2 of each 1000 sets of 200K keys will not find any match

Thank you very much, I also receive your email, it really means a lot to me.

Welcome and have an excellent day.

It may be something with -k 3072



Sadly no, there is not a complete one... If you are developer for MAC there are some issues open or closed:

https://github.com/albertobsd/keyhunt/issues/268
https://github.com/albertobsd/keyhunt/issues/244
https://github.com/albertobsd/keyhunt/issues/202
https://github.com/albertobsd/keyhunt/issues/155
https://github.com/albertobsd/keyhunt/issues/137
https://github.com/albertobsd/keyhunt/issues/87
https://github.com/albertobsd/keyhunt/issues/7

To be honest, with the money that you use to buy a MAC you can buy one or two High end PCs with the last hardware and having 0 issues.

Usually those forks are worthless but in any case you can make some tens bucks with them. You can use Guarda wallet (web app) to move them to another wallet. And you can use changenow.io to exchange them to bitcoin.

How the fuck do you reach these conclusions, Based on what evidence?

There is NO EVIDENCE in one way or in the other. Those are only your opinion.

Please stop spreading FUD

Additional to the extra 128 keys per query I also need to check 65 items to the bloom filter

Original it was to be 64 items but since I already calculate 65 different sets of possible items, from the 128 bits window:

1 to 64 - Item 1
2 to 65 - Item 2
3 to 66 - Item 3
...
64 to 127 - Item 64
65 to 128 - Item 65

Also 1/64 = 0.015625 that is 1.5% more process in this part, so One item extra would be not much noticeable, because bloom filter checks are faster than generate the keys




Yes the database should be at least 200K times great than current database.
And yes my current database can't exceeded the RAM amount that is the big limiting
(A lot of people ask me to use some NVme disk directly for this database instead the RAM,
In this case to compensate the different speed between RAM against Disk the database need to be x1000 times great.
so if you are using 128 GB of RAM, the NVme must be some like 128 TB)
But that is one topic apart



Yes definitely it can be added to BSGS, any method that can query if a public key is between 1 and M keys can be used for BSGS.

Yes also we can add your database to a bloom-filter or any other kind like XOR, Fuse filters.


Let me test and measure it, usually those filters have some constant time to query if the item is inside or not.

So we can pack your items like - Pattern:distance:something-else  (This is preferably in byte formats than strings)



Question here... why we don't limited the search to some easy pattern to recognize like 0000000000000000 or 1111111111111111
To be more efficient those should be stored as bit and some of them may be easily to search from the CPU point of view you know (ANDs ORs and bitshifts)



I think that once that you chose some specific pattern you should store all the matches that exists in your DB no?
Because if we don't store some matches then we may have some missing gaps and hence missing keys (HITS)


That size of 130kb is because the length of the strings that you are storing?

I think that a data structure should use less space but that is something that can be optimized later

Now I get your idea.


150 , 100 , 50.  Thousands, right?

Here is what I understand

Your Ultra-Lightweight Database is more like a reference for some Patterns and their offsets related to next pattern right?

So each time that we need to query if some Random Key X is in our database we need to calculate some 50K to 200K Keys next to our target and looking for those Patterns

If some Patterns match with out database (Pattern and offset against other patterns in our database), we can easily calculate the value of that X Key.

As far I see to get this database of distances and patterns small you are paying with more process to find those matches.


You need a point of comparation, also you need to calculate what is the point where your approach is better than exising methods.

For example, in the test that I send to you using my approach, bloom filter + BSGS the speed was near 16 Petakeys/s ( 15,904,076,907,774,986 keys/s) Using 8GB or RAM

But the current version of keyhunt did 26 Petakeys/s with 4GB of RAM, if I use 8 like the other Test it would do some 50 Petakeys/s

And my program is slow compared it against the kangaroo (kTimesG's version) for CPU than can solve keys under 80 bits in 1 minute.

So I think that we need to calculate how many keys do you  need to have in your database just to become competitive against the existing tools.

First thinks that you need to do is measure how many time a CPU or GPU can calculate the 200K keys sequentially and search for the patterns.
And then calculate how many keys need the database to reach some Exakey/s, Zettakeys/s o Yottakey/s.

One good think Good about your approach is that the database can grows on demand you only need to keep calculating keys and search the patterns once that you found one just append it to the DB.

To be honest I think that It would be difficult beat to kangaroo but with enough DB it may be possible.

Lets do some calculation:

(2**80) / 60 seconds = 20148763660243819578436

Suppose that you take 1 Second in determine if the pattern is in our database or not

That would mean that you need a database with at least 20148763660243819578436 elements

>>> 2**75  <=  20148763660243819578436
False
>>> 2**74  <=  20148763660243819578436
True


So its something between 2**75 and 2**74, well those are just rounded numbers real database maybe near 2^70 or something low
But one thing comes to my mind, we can't solve a 2^65 with  pure brute-force alone.

How you plan to build a database that rounds the 2^60 items to compete against kangaroo.

If we have enough computer power to build a 2^60 or 2^70 database we may have some chances to be able to try something against 135.

Well those are just round numbers that comes to my mind in this moment.

I don't know if such person/people is reading us but...

A clever way to disclose the private key is the next:

Take all the inputs to your address but leave some dust input behind (all those wallets has always some dust inputs)
Then once that you cleared all the balances in all chains except one dust, make a special TX where you manually chose a repeated Nonce value or one with some difference small to be solvable with some math.
Broadcast that TX and someone should notice that repeated or weak R value and the key should be solved easily.

Well Yes I did it, in my previous example that was done. Since almost all the times those 128 items need to be calculated, I calculate all those keys and generate all the array of 64 items all of them of 64 bits, then I proceed to check them against the bloom filter.

---

Thank you for your example actually that is what i want to ask next, let me check and analyze it, to see what i can do.

Well that is a possibility? But unless you provide some evidence, all it a pure speculation.


Same, he/they can be a single person, a group of people, we DON'T KNOW.


Many Replacements can be done until almost 100% of the balance become in a Fee for the miner.

But this depends of how many time a miner takes to mine that specific block, it can be 1 second from your TX or some hours from IT, that is something that we don't control.