Bitcoin Forum
June 14, 2024, 12:05:06 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: June 13, 2024, 11:21:26 PM
I disagree with your reasoning.

We are not talking about ownership or rights to numbers, but to the right to get a reward for the time spent and the result with the technology used. if someone has spent time, money to look for the private key, and you want to use this information (because the transfer will reveal the public key, thus you have the possibility of RBF, and you are only waiting for this public key, not looking for the solution to the puzzle itself) then it is not ethical.

It can be compared to cheating on an exam.

This was probably not the intention of this puzzle, however, greed unfortunately often wins - such is the nature of some people. The end of the topic from my side - everyone is the maker of his own fate. It is interesting to see how this community has changed and what weaknesses this puzzle has uncovered.


This is a cracking contest, an arms race of sorts. People attempting to solve this are basically competing with each other to get there first.

While one can work hard, another person can simply work smarter and snag the reward for themselves.

In this scenario one can only "claim ownership" of a coin after it makes it to an address one controls, and not a second before that.

Let's say I have just enough GPU power to solve a key in two years. After running my tools and paying electricity bills for 23 months you go for the same key with enough hardware to crack it in a day.

You say this is fine, but I'll be left in the dust after I spent time, money and effort just like someone who lost to a bot. Why is it so different?

Such is the nature of this challenge. People can outrun each other with better hardware/cracking tools, so why draw this line there now?

A bot is just another tool one can use, it is code just like Keyhunt or Kangaroo.

That said, I think everyone participating in this bot war will just be contributing to turn 6.6 Bitcoins into a transaction fee, it's sad and probably there will be no personal gain for anyone involved.

But I can guarantee you lots of people will be there doing that when the time comes.

"This was probably not the intention of this puzzle" I'd say this is exactly the intention of this puzzle, finding weakness in the protocol. This is one of them.

In the end it still boils down to "not your keys not your coins" which is a very old saying at this point.
2  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: June 13, 2024, 04:08:59 PM
JLP's kangaroo for example is definitely not fully optimized when it comes to this.


Check out Etarkangaroo if you haven't, it seems to have some improvements, albeit small.

Max range width up to 192 bits and (on my setup at least) it's 1Gk/s faster than JLP's.

I have no idea if it's fully optimized but I'm guessing it could be a better starting point for further improvements, although one potential downside is that it requires PureBasic to compile, which has to be bought.
3  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: June 13, 2024, 11:55:51 AM
Keyhunt does not take long to load, it takes a long time because you do not save the files.
If you add the -S command, your next run will take a very short time.

I did take that into account.

Even with the -S parameter it takes more than one minute to load in with my machine.

In my particular case almost 2 minutes to initialize Keyhunt, 20 seconds for BSGS-CUDA.

4  Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it on: June 11, 2024, 11:27:19 PM


Yes, I have about ~4 Ekeys/s on PC with 64GB RAM.

Code:
./keyhunt -m bsgs -f 65.txt -b 65 -e -t 12 -l compress -q -S -k 4096 

But it's a blast to solve Puzzle 65, 66, 67, 68.  It takes about 60 seconds once we identify the public key from the blockchain.  

Here i tested my toddler bot script on Puzzle 65 = address -> 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe


root@puzzle ~/Test # time python3 toddler_puzzle_bot.py
  • Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
  • Endomorphism enabled
  • Threads : 12
  • Search compress only
  • Quiet thread output
  • K factor 4096
  • Mode BSGS sequential
  • Opening file 65.txt
  • Added 1 points from file
  • Bit Range 65
  • -- from : 0x10000000000000000
  • -- to   : 0x20000000000000000
  • N = 0x100000000000
  • Bloom filter for 17179869184 elements : 58890.60 MB
  • Bloom filter for 536870912 elements : 1840.33 MB
  • Bloom filter for 16777216 elements : 57.51 MB
  • Allocating 256.00 MB for 16777216 bP Points
  • Reading bloom filter from file keyhunt_bsgs_4_17179869184.blm .... Done!
  • Reading bloom filter from file keyhunt_bsgs_6_536870912.blm .... Done!
  • Reading bP Table from file keyhunt_bsgs_2_16777216.tbl .... Done!
  • Reading bloom filter from file keyhunt_bsgs_7_16777216.blm .... Done!
  • Thread Key found privkey 1a838b13505b26867   
  • Publickey 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b
All points were found
Private Key: 1a838b13505b26867
WIF Key: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZM21gaY8WN2CdwnTG57
Starting Electrum ....
starting daemon (PID 41802)
true
Keypair imported: 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
Transaction IDs: []
Daemon stopped
Electrum daemon stopped successfully.

real   2m46.311s
user   1m55.133s
sys   0m59.598s


and the time required to import the key into Electrum and start the redirection of transactions (if they exist ).  


I think for this purpose you could achieve even faster results by using BSGS-CUDA, if you can.

In my experience Keyhunt takes much longer to load in. With BSGS-CUDA; around 18 to 20 seconds to initialize.

Of course, it can vary from one setup to another. This is what I've observated with my rig.

Nice script, the people hating clearly have no idea what they are talking about.  Roll Eyes
5  Local / Português (Portuguese) / Re: Desvendando o BTC Puzzle 130 - Junte-se ao Nosso Esforço Colaborativo on: June 09, 2024, 03:15:56 AM
Olhando os commits na página do GitHub, percebe-se que esse "Kangaroo2" é um fork do programa original que não acrescenta absolutamente nada novo além do "2" no final do nome.

O criador do programa original já deixou claro que não é possível atacar a chave publica #130 com ele sem antes modifica-lo pra suportar larguras de intervalo maiores que 125bits (a largura do intervalo que contém a chave #130 tem 129bits).

Mesmo que a intenção do OP seja honesta (não esteja planejando fazer os outros minerarem DP pra ele pra depois sumir com a recompensa) só vai fazer com que os participantes do projeto dele despedicem tempo e energia elétrica atoa.

Se resolvessem o problema principal (modificando o programa ou usando uma outra ferramenta de ataque) além de ter que depositar confiança em uma conta sem reputação pra dividir a recompensa entre os participantes, um outro problema com esse tipo de iniciativa é que é difícil gerenciar o progresso que é feito.

Um participante malicioso pode encontrar uma forma de submeter trabalhos forjados pra aumentar o próprio credito dentro da pool, ou pra simplesmente trolar / atrasar o esforço coletivo, como já aconteceu em outros projetos desse tipo.

Levando em conta que o OP aparentemente não sabe nem muita coisa a respeito do programa o qual o projeto inteiro dele gira em torno, fica difícil acreditar que o mesmo teria um bom gerenciamento, novamente, SE o programa proposto sequer funcionasse pra essa finalidade.



After quick look at kangaroo code, looks like there is 3-bits of 128-bit value used for something. So, it actually really 125-bit max. I can be wrong and I think only JLP can answer 100%.

Hello,
Yes you are right. The GPU code should also be modified to return good distances.
Do not try to solve this puzzle, it will take years using a rendering farm !
6  Bitcoin / Development & Technical Discussion / Re: BSGS solver for cuda on: May 21, 2024, 10:40:49 PM
so the speed is around 300MKeys, wheres my exakeys? Grin

Cnt:b8c6800000000001 [1][ 316 ] = 316 MKeys/s x2^27.0=2^55.31 Jt:00:05:00 Tt:00:05:03


It says  316Mk/s  x  2^27.0  =  2^55.31

2^55.31  =  44665177000000000

So this is your speed. Around 44 Pk/s (or 0.04 Ek/s).
7  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.
8  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
  
9  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.
10  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
11  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.





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

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


15  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.
16  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
17  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
18  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.
19  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.
20  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!!
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!