This thread broke my motivation to keep searching. I'm thinking of pausing the search if there isn't any definitive solution.

RBF activation and deactivation option is available in Bitcoin Core.

If I transfer the private key to Bitcoin Core and disable the RBF option from there, will there be a definitive solution if I start the transfer process from there?

Yes, I'm sure they'll find it in such a short time. They can create RBF in 1 minute in total. Do you have an idea as a solution to this?

My computer has been searching for about a year, and I'm not hopeful.

However, today it occurred to me that the transfer of the person who finds the 64th puzzle may be cancelled.

In other words, after the transfer process starts, the public key will be revealed and thieves who do not deserve it will find the public key within minutes with Kangoroo. Then they will open a double trade with RBF by spending high, the transfer of the person who finds it will be cancelled.

It occurred to me that the thief would figure it out in about 3 minutes.

The average bitcoin transfer confirmation takes 10 minutes and can be canceled without 3 confirmations. (I could be wrong, please correct me.)

How can you get 3 confirmations in 5 minutes in Bitcoin transfer?

Interesting List you have. I would have given merits If I had some.

I don't think that they can be effectively searched in parallel. You have to divide each pubkey and check it with the babysteps. So not only do you need to make very expensive global memory lookup (GPU has slow global and super fast local memory) and load each key.

So if you would search multiple keys you would effectively reduce the performance by them. Like 10 keys in parallel means 10 times slower. 2800 keys means 2800 times slower.

I am sure there will be a limit, but it is probably in the millions. For similar programs, it usually caps out at around 30 million addresses, pubkeys, xpoints...

a.a.
Have you ran this program yet? It's just that some of your answers make it seem like you have not ran it at all.

The program does not check keys in parallel, it runs range with one pubkey, once finished, it moves to the next, until the last pubkey has been checked for that specific range.

New release v1.4.0
supported compressed/uncompressed format public keys
removed binsort program (don`t need sorted array any more)
baby array need only first time to create HT (or rebuild HT when -htsz changed)
After HT created and saved, next time you will need less ram and only HT, giant array to launch.
...

here i see post related to compress to uncompress and uncompress to compress (codes)
https://bitcointalk.org/index.php?topic=5244940.msg57700007#msg57700007

It is my implementation of BigStepGiantStep algorithm for Nvidia card (Cuda and Windows x64 only)
https://github.com/Etayson/BSGS-cuda
Let me know of your speed results.

I tried many ways to check addresses that start with 3 if it's segwit or not but I couldn't find any tool that can check the address if it's segwit or not.

Except to those addresses that already have spent transactions.

Not without knowing the redeem script used in these P2SH addresses.
That requires the owner to spent from that address at least once and reveal that redeem script, then it is trivial to look at it and know the details.

What do you mean by saying “similar private keys” and “distances”?

My bad, thanks for correcting me!

Indeed, the keys are - fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140. I confused the total private keys with - fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f - which is p and F_p the finite field of secp256k1.

I updated my post.

I'll show you how detailly and decimally how many private keys can create the same address. So there are 2²⁵⁶-2³²-977 valid private keys. That's:

Total combinations of a 160-bit number are 2¹⁶⁰ which is:

So, each address should averagely have the division of those two numbers;


That's:

Each time you spend bitcoins from one of your addresses, you're signing using 1 of the 79,228,162,514,264,337,593,543,950,336 different and valid, on average, private keys.

You mean how many private keys give the same compressed address? As said, approximately 2²⁵⁶ / 2¹⁶⁰ = 2⁹⁶. That's true for uncompressed addresses too.