Bitcoin Forum
May 21, 2024, 12:09:09 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Development & Technical Discussion / Re: divided Pubkey -> Privkey on: May 20, 2024, 11:45:53 PM
I ran this equation using your example and the 40 bit pvk was found whether I ran the bsgs algo in the 50bit, 40bit or 30bit range. The same public key was found as long as I did not search in a range above 50bit. I don’t understand why it’s finding the same public and private key pair on line 120 in the output file. How is it finding a 40 bit private key in a 50 bit or 30 bit range? Do you know why?


I'm not sure why this would happen as I don't really know much about how these algorithms work.

Maybe the algorithm's precomputed table covers the entire area of these smaller ranges without the need for further calculations?

You can reach out to the person who created the BSGS implementation you are using

I'm sure they will be able to better answer you.
2  Bitcoin / Development & Technical Discussion / Re: divided Pubkey -> Privkey on: April 24, 2024, 10:27:57 PM
Hi sir it works perfectly but when range is 80 or more I cannot find because range is big to find the divided pubkey and do calculation. What can I do in that situation to solve that problem? Example I want to do calculation with 125 bit range pub key.

Unfortunately there's no workaround.

If you reduce too much you will be left with an absurd ammount of offsets which will be impossible to work with.

For a 125bit key:

10bit reduction = 1024 offsets to search in the 115bit range.

25bit reduction = 33.554.432 offsets to search in the 100bit range.

30bit reduction = 1.073.741.824 offsets to search in the 95bit range.

 Sad
  
3  Bitcoin / Development & Technical Discussion / Re: divided Pubkey -> Privkey on: April 23, 2024, 01:47:22 PM
Hi sir can you share real example with that library, thank you.

Let's make this simple. I'm going to use this 50bit keypar:

Initial PBK: 027f3bd8832c4ccc73a0c741b0ab204c0a6bafa5fd57c944e391d06906f6db7d5f
Initial PVK: 0x39c3e0843ac77 [1016215170690167 in decimal]

Code:
python3 PubDiv.py 027f3bd8832c4ccc73a0c741b0ab204c0a6bafa5fd57c944e391d06906f6db7d5f 10 out.txt

This generates our out.txt file with 1024 offsets. Since its a 10bit reduction in this example, at least one offset will be in the 40bit range.

I loaded the out.txt file into the BSGS algorithm and set it to run the 2^40 bit range. It found this offset:

PUB: 03720bd6f652601111001205bf748666b60903777d8bb83dc7e558d42f37c7fb5b
PVK: 0xe70f8210eb [992397627627 in decimal]

This offset is found in the line 120 of my out.txt file, so now we have everything to set up the equation:

Offset PVK = 992397627627
Total Offsets = 1024
Offset's Position = 120


For the sake of simplicity I'll run this on python:

Code:
PVK = 992397627627 * 1024 + 120 - 1
hex_PVK = hex(PVK)
print(hex_PVK)
print(PVK)

Result: 0x39c3e0843ac77, 1016215170690167 in decimal.
4  Bitcoin / Development & Technical Discussion / Re: divided Pubkey -> Privkey on: April 23, 2024, 01:08:01 PM
Original_PVK = Offset_PVK * Total_Offsets + Offset_position - 1

This is how you go from the offset back to the initial private key.  Wink
5  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: April 20, 2024, 12:36:18 AM
When we restore searching from a saved work file, it only shows the first key in input file after the end range, so what happens to other keys we input for search?

And if we have a speed of 1000MK/s, it would divide by the number of keys right? meaning half the speed is used to search for the second key if we input 2 keys? If that is the case then the expected time should double if there is more than 1 key.
Thus having 4 keys to search for a 130 bit key could take up to 2**68 operations, correct?

This program cannot search for multiple keys simultaneously.

It will go over each key in the input file, one at a time.

If a solution is found then it goes to the next.

Someone correct me if I'm wrong, but otherwise I think you need to use the -m parameter to give up the search and start with the next key

In a scenario where the solution could not be found within the given range.





6  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 19, 2024, 12:09:57 AM
One year would be wonderful, whoever could solve 66 in one year! Roll Eyes

I'm not saying that the key is there tho.

What I meant is that my rig would take one year to search that portion of the range.

The key might not be there at all.

Personally I don't feel like wasting a year to find out.

But who knows, maybe someone with better hardware, able to do that range in much less time, might be willing to check it out for themselves.

7  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 18, 2024, 09:52:49 PM
Everything is useless, I have tried many predictions like this, none of them worked Sad

I also tried to predict #66 in a similar way but the ranges I got are still too big to do anything useful. I don't have high end hardware to test the predictions either, and the ranges I got are around 40% of the total range.
Factoring in that most likely the beginning and end of the ranges have been searched already, and doing other basic assumptions, you can reduce the range down but it's still too big.
Furthermore, now I am trying my luck on #130 because why not. It is very unlikely that #66 will get in my hands (or yours) so I just gave up on that.

Exactly. I'm also long done with #66.

I'm currently trying my luck with #130 too cause even brute forcing it could be done in less time than #66.

I shared this not with the intent of actually predicting the correct key, but to maybe narrow down the range.

Still, my rig would take one year to search from 290860e0f31602000:291fff00000000000.

Way more if 290860e0f31602000 is used as mid point instead of starting point.

Anyways, sorry if the idea is dumb, and thanks for your answers.  Smiley
8  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 18, 2024, 09:50:04 AM
use this code to "predict"

Hexadecimal: 0x11f774e94c1ec000         # puzzle 62     0x363d541eb611abee
Hexadecimal: 0x7d556bf6f89d2c00         # puzzle 63     0x7cce5efdaccf6808
Hexadecimal: 0xe7655f0b50acf800         # puzzle 64     0xf7051f27b09112d4
Hexadecimal: 0x1a78fd44662532000      # puzzle 65     0x1a838b13505b26867   
Hexadecimal: 0x290860e0f31602000      # puzzle 66     ?

Yep. Some results get kinda close, others not much.

Could accuracy increase as we append new keys to the sequence?

Can we improve this script somehow?

Code:
spline_rep = splrep(x_values_known, sequence_decimal, k=2)

I've messed with other values for k but 2 seems to yield better results.


9  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 17, 2024, 10:26:06 PM
Well, since we are here I'd like to ask what y'all think of this:

Code:
import numpy as np
import matplotlib.pyplot as plt
from scipy.interpolate import splev, splrep
from decimal import Decimal

sequence = [
1, 3, 7, 8, 21, 49, 76, 224, 467, 514, 1155, 2683, 5216, 10544, 26867, 51510, 95823, 198669, 357535, 863317, 1811764, 3007503, 5598802, 14428676, 33185509, 54538862, 111949941, 227634408, 400708894, 1033162084, 2102388551, 3093472814, 7137437912, 14133072157, 20112871792, 42387769980, 100251560595, 146971536592, 323724968937, 1003651412950, 1458252205147, 2895374552463, 7409811047825, 15404761757071, 19996463086597, 51408670348612, 119666659114170, 191206974700443, 409118905032525, 611140496167764, 2058769515153876, 4216495639600700, 6763683971478124, 9974455244496707, 30045390491869460, 44218742292676575, 138245758910846492, 199976667976342049, 525070384258266191, 1135041350219496382, 1425787542618654982, 3908372542507822062, 8993229949524469768, 17799667357578236628
]

x_values_known = np.arange(len(sequence))
sequence_decimal = [Decimal(value) for value in sequence]
spline_rep = splrep(x_values_known, sequence_decimal, k=2)
extended_x_values = np.arange(len(sequence) + 1)
predicted_next_number = splev(extended_x_values[-1], spline_rep)
predicted_next_number_hex = hex(int(predicted_next_number))
plt.plot(x_values_known, sequence_decimal, label='sequence')
plt.plot(
    extended_x_values,
    splev(extended_x_values, spline_rep),
    label='Recreated Sequence',
    linestyle='dashed'
)
plt.scatter(
    extended_x_values[-1],
    float(predicted_next_number),
    color='red',
    marker='o',
    label='Predicted Next Number'
)
plt.legend()
plt.xlabel('Index')
plt.ylabel('Value')
plt.title('Original vs. Recreated sequence with Prediction')
plt.show()
print(f"Next key: {predicted_next_number}")
print(f"Hexadecimal: {predicted_next_number_hex}")

This is the result when we feed the script the sequence of keys up to #64, in order for it to "predict" #65:

Next key: 3.0520846598475555e+19
Hex: 0x1a78fd44662532000


Is this jesus toast or could we use it to at least try and narrow down the first 2 characters of #66?

Your insights are much appreciated.
10  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 12, 2024, 12:03:03 AM
Hey Guys,, the Question is about Kangaroo. i'm a bit confused..  the kangaroo designed by JeanLucPons. is the program restricted to work only inside the range of 125 bits? if yes what does it mean? because i tried it with a 130 bit range and it seems to work and in the issues section i see people talking about how it wouldn't work for 130 bits can someone tell me what they are talking about ?

The program is limited to a range width of 125 bits or less.

The range width is the upper bound of the range minus the lower bound.

You can find the discussion about this on the kangaroo thread;

https://bitcointalk.org/index.php?topic=5244940.0
11  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 09, 2024, 03:41:27 AM
Are you sure that this API is capable of displaying information from the mempool?

I don't think so, I believe this one is just for confirmed txs.

This is not meant to be used as is in a real scenario, although you could probably consider it a ground work to expand upon.

The goal was to actually see how long the whole operation can take using different tools.

In my end it took roughly a minute to go from a public key on the web to a 70 bit private key stored in a .txt file.

Probably not the best performance too, but scary nevertheless.  Grin
12  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 08, 2024, 05:46:32 PM
Code:
import requests
import time
import os
import subprocess

# Address to monitor
address = "[b]13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so[/b]"

# File path to save the public key once detected
file_path = "[b]C:\\Path\\To\\Your\\Cracking\\Tool\\Folder\\[/b]puzzle.txt"

# Command to execute
cmd = "[b]your_cracking_tool.exe -r 20000000000000000:3FFFFFFFFFFFFFFFF -o FOUND.txt -i[/b] puzzle.txt"

# API endpoint
api_url = f"https://blockchain.info/q/pubkeyaddr/{address}"

def monitor_address():
    start_time = time.time()
    while True:
        try:
            response = requests.get(api_url)
            if response.status_code == 200:
                print("OUTGOING TRANSACTION DETECTED!")
                print("FETCHING COMPRESSED PUBLIC KEY...")
                public_key = response.text
                with open(file_path, 'w') as file:
                    file.write(public_key)
                print("INITIALIZING!")
                os.chdir("[b]C:\\Path\\To\\Your\\Cracking\\Tool\\Folder[/b]")
                subprocess.call(["cmd.exe", "/c", cmd])
                break
            else:
                os.system('cls' if os.name == 'nt' else 'clear')
                elapsed_time = time.time() - start_time
                print(f"Monitoring address: {address}...")
                print(f"[T: {int(elapsed_time)}] No outgoing transaction yet...")
                time.sleep(1)
        except Exception as e:
            print(f"Error: {e}")
            time.sleep(1)

if __name__ == "__main__":
    monitor_address()


This script monitors a given address waiting for an outgoing transaction to be broadcasted.

When this happens, the script will then write the public key to a file named "puzzle.txt" and execute the cracking tool of choice using "puzzle.txt" as the in file.

If someone wants to mess with it just replace "File path to save the public key once detected" and os.chdir("C:\\Path\\To\\Your\\Cracking\\Tool\\Folder") with the actual path

Also replace "Address to monitor" with your target address and "Command to execute" with the actual command to start up the algorithm of choice.

This script is fairly simple and as is it won't be able to compete with more elaborate bots, as it stops after finding the private key.

There's no automation to import the key into a wallet/transfer funds etc.

I made it just to test the response time using different tools.

BSGS-CUDA seems to be one of the best options for this, as it doesn't take too much time to load up.

I got to puzzle #70's private key in less than a minute with it.
13  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: April 06, 2024, 06:54:57 AM
I’m seeing so many variations of software throughout this thread and the other one. If I wanted to randomly let my pc waste electricity on weekends doing a random search for #66, what would be my best bet?

I have a 3070 and can switch to my Ubuntu partition if that’s better. I know my chances are probably like 0.001%, but I just want to feel like I’m joining the big boys on the hunt.

Your best option would be some implementation of KeyHunt-CUDA / Rotor-CUDA. Or BitCrack if you want to mess with the stride option.

In terms of raw performance BitCrack lacks tho.
14  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED== on: January 22, 2024, 09:47:43 PM
There is some tips to speed-up keyhunt-cuda (rotor-cuda):

Apply this then you need less grid size, like 4096x512 will be enough for 4090:

https://bitcointalk.org/index.php?topic=5244940.msg63526413#msg63526413

Also change this:

__device__ __noinline__ void CheckHashSEARCH_MODE_SA(uint64_t* px, uint64_t* py, int32_t incr, uint32_t* hash160, uint32_t* out)
{
   switch (mode) {
   case SEARCH_COMPRESSED:
      CheckHashCompSEARCH_MODE_SA(px, (uint8_t)(py[0] & 1), incr, hash160, out);
      break;
   case SEARCH_UNCOMPRESSED:
      CheckHashUnCompSEARCH_MODE_SA(px, py, incr, hash160, out);
      break;
   case SEARCH_BOTH:
      CheckHashCompSEARCH_MODE_SA(px, (uint8_t)(py[0] & 1), incr, hash160, out);
      CheckHashUnCompSEARCH_MODE_SA(px, py, incr, hash160, out);
      break;
   }
}

to this because doing switch-case in kernel is very bad idea:

__device__ __noinline__ void CheckHashSEARCH_MODE_SA(uint64_t* px, uint64_t* py, int32_t incr, uint32_t* hash160, uint32_t* out)
{
   
   CheckHashCompSEARCH_MODE_SA(px, (uint8_t)(py[0] & 1), incr, hash160, out);
      
}

also maxFound can be completely removed to search puzzle, because we need only one return result anyway

Rotor-cuda speed with this mods:

  [00:17:10] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.453247 %] [R: 0] [T: 6,412,923,043,840 (43 bit)] [F: 0]
  [00:17:11] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.500549 %] [R: 0] [T: 6,421,244,542,976 (43 bit)] [F: 0]
  [00:17:12] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.547852 %] [R: 0] [T: 6,429,566,042,112 (43 bit)] [F: 0]
  [00:17:13] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.595154 %] [R: 0] [T: 6,437,887,541,248 (43 bit)] [F: 0]
  [00:17:15] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.642456 %] [R: 0] [T: 6,446,209,040,384 (43 bit)] [F: 0]
  [00:17:16] [CPU+GPU: 6.72 Gk/s] [GPU: 6.72 Gk/s] [C: 36.689758 %] [R: 0] [T: 6,454,530,539,520 (43 bit)] [F: 0]
  [00:17:17] [CPU+GPU: 6.72 Gk/s] [GPU: 6.72 Gk/s] [C: 36.737061 %] [R: 0] [T: 6,462,852,038,656 (43 bit)] [F: 0]
  [00:17:18] [CPU+GPU: 6.72 Gk/s] [GPU: 6.72 Gk/s] [C: 36.784363 %] [R: 0] [T: 6,471,173,537,792 (43 bit)] [F: 0]
  [00:17:20] [CPU+GPU: 6.72 Gk/s] [GPU: 6.72 Gk/s] [C: 36.831665 %] [R: 0] [T: 6,479,495,036,928 (43 bit)] [F: 0]
  [00:17:21] [CPU+GPU: 6.71 Gk/s] [GPU: 6.71 Gk/s] [C: 36.878967 %] [R: 0] [T: 6,487,816,536,064 (43 bit)] [F: 0]


Thanks.


That's actually very interesting. Could you share your raw files with these mods applied? 

I've tried it on my own files but I can't get it to recompile afterwards, throws a bunch of errors.

Also you've mentioned that you are using Vladimir's version of Rotor, try using Phrutis' version. I think it's a little bit faster.

Thanks!!
15  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: January 11, 2024, 12:43:35 AM

He succeeded in his idea. He showed our cracking capabilities  are poor.

Prize: 988.498 BTC (total), 31.998 BTC (won), 956.5 BTC (remaining)

His 956 BTC is relatively safe even the whole world knows the ranges where the private keys are. Grin

Yeah, for now it seems like the progress is halted, but as tech gets better this challenge will always provide a way of seeing where our capabilities are capping.


I sometimes think that the creator has been withdrawing the BTC from the undisclosed wallets in recent years, I see no reason why someone who unlocks the puzzle should not share their keys anonymously once the wallet is emptied, either that or there is a possible sequence that we are not seeing.

I feel like the people cracking these are keeping the keys for themselves 'cause the creator might send more funds to those wallets one day, as this already happened before.

Didn't #125 have like 1.25 BTC the day it was opened, and later on it got +11 BTC sent to it?

That would be a pretty good reason to keep these keys close to your chest. Grin
16  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: January 09, 2024, 11:50:59 PM
I have found a few interesting hints regarding the puzzle 130, since I don't know the actual private key, I will just leave them here for the author to verify.
Are the following values related to the puzzle 130 in any way? Like being the last characters, first characters, the key being divisible by them etc?
3c8
f2
ec

If yes then I might be onto something. Then I'd need a hint to follow up on it, you might also want to check the inverse key as well.


I think that if the creator was to come here and give us hints, this would defeat the purpose of his creation which is to measure our cracking capabilities.

Can't really be giving out hints in an experiment like this one, we must check our own leads and see what comes out of it.
17  Bitcoin / Project Development / Re: keysubtracter - test - development requests - bug reports on: December 28, 2023, 09:36:44 PM
I've made this simple Python script to process the resulting file from Keysubtractor, removing all the information beyond the pubkeys/hash160/addresses.

The original file will be kept intact as the script creates a new out file, this way you won't lose all the valuable information.


with open('pbks_in.txt', 'r') as file, open('pbks_out.txt', 'w') as outfile:
    for line in file:
        cleaned_line = line.split('#')[0].strip()
        outfile.write(cleaned_line + '\n')



Just have it in the same folder your Keysubtractor file is in, and don't forget to change the names of the in and out files to match yours.

I know this is simple stuff, but I hope this can be of help!
18  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: December 25, 2023, 12:52:29 AM

Yet someone snuck out #64....

It really makes no sense, I guess all that reading I did was wrong, about not using the RBF option, etc.

I guess I'll just have to take my chances.


I've read that most wallets are dropping the option to disable RBF, it's usually on by default now.

One can no longer find this option in the newest Electrum versions for example. Would need a version older than 4.4.0 to get that option back.

Also, #64 had 0.6 BTC back in 2022 when it was cracked.

While I don't consider that to be no little amount, the stakes are much higher now at 6.6 BTC for wallet #66.

I guess the solver would need to wait for the Russians to go to sleep before sneaking out those funds.  Cheesy
19  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: December 25, 2023, 12:02:03 AM
If normally it would not be safe, imagine now with the mempool being congested as it is. It would not be wise to transfer anything out of the lower range wallets for a while if you manage to open one.
20  Bitcoin / Bitcoin Discussion / Re: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED== on: December 16, 2023, 08:49:17 AM
Yes, you could. I implemented a total key counter in mine. It would print to file, total # of keys, that way, even if power went out, I'd have a good starting point.

If you do it this way, make sure you keep/know start and end range. You then need to take total keys ran, divide by the number of threads (grid size) and then take that number and add it to your initial/last start AND end range.

Example:
If you had a start range of 0 and an end range of 1000000 (keep it small for this purpose) and your grid size was 10x10. The program says you have ran/checked 10,000 keys total.
Take 10,000 (total keys) and divide by 10x10=100 (grid size); 10,000 / 100 = 100. So each gpu thread checked 100 keys.
So for your next batch file, you would have a start/end range of 100:1000100.
If you only change the start range by 100, then you are overlapping/possibly missing keys checked on the other threads. If you stop and think about it, or do the math, it'll make sense.
Your first thread checked 0-100 (now on second run it should start at 100 and be on the hook to check up to 10,100); the last thread checked 990,000-990,100. If you don't adjust the end range as well, your last thread will now be checking 999,900 instead of starting where it left off at 990,100.
Lol, again, if you do the math you'll understand. Hope it made some sense.


That's actually a very good explanation, really appreciate it man!
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!