NotATether
Legendary
Offline
Activity: 1694
Merit: 7171
In memory of o_e_l_e_o
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2021, 08:47:47 AM |
|
Question, i have say 1000 keys in my config, does it crack them all simultaneously?
Yes (if for loop iteration counts as simultaneous ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Only the GPU truly cracks the keys simultaneously up to a certain number at once) Also if i wanted to check the entire keyspace for 128bit keys (yes i know this makes it astronomically harder and likely impossible) what would the first two lines of config file look like?
Its currently
0 FFFFFFFFFFFFFFFFFFFFFFFFF
Yeah that looks about right, if it doesn't work, pad them with zeros on the left until they are 64 characters long each. Sorry for the newbie questions, this is for a school project, so help would be appreciated.
![Shocked](https://bitcointalk.org/Smileys/default/shocked.gif) That's very cool, first time I saw one interested in discrete log solvers.
|
|
|
|
Bobermart
Newbie
Offline
Activity: 3
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2021, 08:52:45 AM |
|
Question, i have say 1000 keys in my config, does it crack them all simultaneously?
Yes (if for loop iteration counts as simultaneous ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Only the GPU truly cracks the keys simultaneously up to a certain number at once) Also if i wanted to check the entire keyspace for 128bit keys (yes i know this makes it astronomically harder and likely impossible) what would the first two lines of config file look like?
Its currently
0 FFFFFFFFFFFFFFFFFFFFFFFFF
Yeah that looks about right, if it doesn't work, pad them with zeros on the left until they are 64 characters long each. Sorry for the newbie questions, this is for a school project, so help would be appreciated.
![Shocked](https://bitcointalk.org/Smileys/default/shocked.gif) That's very cool, first time I saw one interested in discrete log solvers. Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how do i program it to crack that, or is it just automatic? By using 0 FFFFFFFFFFFFFFFFFFFFFFFFF will that check the entire keyspace of a standard 128bit key?
|
|
|
|
fxsniper
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 406
Merit: 47
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2021, 10:37:19 AM |
|
Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how do i program it to crack that, or is it just automatic?
By using
0 FFFFFFFFFFFFFFFFFFFFFFFFF
will that check the entire keyspace of a standard 128bit key?
Can you code? for very high 128bit key, or 256bit key you need to upgrade or find the way works better and smart than current kangaroo for reduce time use find key now puzzle 120 bits keys still un solve
|
|
|
|
NotATether
Legendary
Offline
Activity: 1694
Merit: 7171
In memory of o_e_l_e_o
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2021, 11:24:56 AM Last edit: March 12, 2021, 07:21:37 PM by NotATether |
|
Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how do i program it to crack that, or is it just automatic?
By using
0 FFFFFFFFFFFFFFFFFFFFFFFFF
will that check the entire keyspace of a standard 128bit key?
The size to search in (and the keys which can be cracked) is determined by (end range - start range), second - first line. Any range bigger than 125 bits currently isn't possible. The range variable itself has 126 bits free but there is some operation I can't recall right now that's done on it which limits the range to 125 bits. I'm working on a patch to fix this. I have no ETA for it though, but I would like to get it ready within a week or two. EDIT: Wheee, I have to play GPU availability roulette again, this sucks ![Angry](https://bitcointalk.org/Smileys/default/angry.gif)
|
|
|
|
Bobermart
Newbie
Offline
Activity: 3
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2021, 11:54:46 AM |
|
Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how do i program it to crack that, or is it just automatic?
By using
0 FFFFFFFFFFFFFFFFFFFFFFFFF
will that check the entire keyspace of a standard 128bit key?
The size to search in (and the keys which can be cracked) is determined by (end range - start range), second - first line. Any range bigger than 125 bits currently isn't possible. The range variable itself has 126 bits free but there is some operation I can't recall right now that's done on it which limits the range to 125 bits. I'm working on a patch to fix this. I have no ETA for it though, but I would like to get it ready within a week or two. Excellent! i look forward to this, i would donate for this. So what did original 2009 - 2012 bitcoin wallets generate? 64bit keys?
|
|
|
|
NotATether
Legendary
Offline
Activity: 1694
Merit: 7171
In memory of o_e_l_e_o
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2021, 01:05:25 PM |
|
So what did original 2009 - 2012 bitcoin wallets generate? 64bit keys?
I am not aware of any wallet software (Bitcoin Core or otherwise) that used anything other than 256-bit keys. At one point in time, people made private keys out of so called "brain wallets" which are just random strings SHA256'ed into a hash that generated public and private keys. [Some people even used public base58 addresses as input to SHA256.]
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1120
Merit: 235
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2021, 01:13:53 PM |
|
Question, i have say 1000 keys in my config, does it crack them all simultaneously?
Also if i wanted to check the entire keyspace for 128bit keys (yes i know this makes it astronomically harder and likely impossible) what would the first two lines of config file look like?
Its currently
0 FFFFFFFFFFFFFFFFFFFFFFFFF
Sorry for the newbie questions, this is for a school project, so help would be appreciated.
If you have 1000 keys in your input file, and you don't know if they exist in the range or not, you will have to use the -m option or the program will search for the first key from now until infinity times infinity...
|
|
|
|
fxsniper
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 406
Merit: 47
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 12, 2021, 01:42:48 PM |
|
So what did original 2009 - 2012 bitcoin wallets generate? 64bit keys?
I am not aware of any wallet software (Bitcoin Core or otherwise) that used anything other than 256-bit keys. At one point in time, people made private keys out of so called "brain wallets" which are just random strings SHA256'ed into a hash that generated public and private keys. [Some people even used public base58 addresses as input to SHA256.] Right and I try already bitcoin original from alpha version bitcoin-nov08.tgz bitcoin-0.1.0.rar bitcoin-0.1.3.rar all are 256 bits from 2009 (2008 develop) everything 256 bits very good for over thinking bitcoin address if develop fit use, may be bitcoin are hack done already all real money bitcoin use 256 bit have only Brainwallet have problem for human crack
|
|
|
|
CrunchyF
Jr. Member
Offline
Activity: 54
Merit: 26
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2021, 09:52:24 AM |
|
Hello everybody,
I am newly interested in the resolution of puzzle # 120 (119 bits private key) pubkey : 02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630 (hash 160: 17s2b9ksz5y7abUm92PCTzK8jEl5y7abUm92PCTzK8jEl5y7abUm92cHZK8jElc). a short calculation shows the difficulty of it with the excellent (probably the most optimised) GPU solver from Jean-Luc Pons.
n=2*sqrt(0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFF-0x40000000000000000000000000000)
best_GPU_card_speed=4*10**9 #(I read that RTX3090 can achieve around 4Giga Keys /s with Kangaroo ECDLP SOLVER) excepted_days=n/best_GPU_card_power/86400
so ... around 833 excepted days!
if u consider a rent of gpu cloud at the minimal price (around 1000$ per week for 8x3090) u can expected to resolve it in 100 days (about 15 weeks) 15*1000=15000$ (very rentable in comparison of 60000$/BTC market price) (1.2*60000 72000$ on wallet)
But u forget that -that someone else can be faster than u, -u can be unlucky because the Kangaroo Lambda algorithm is a probabilistic algorithm. -Bitcoin price can dip while u are in!
Are my calculation are correct?
Have u heard of an implementation of SEC256K1 addition on FPGA or ASIC (ASIC miner have only optimised implementation for sha256)?
Regards
Fanch
|
|
|
|
BASE16
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 180
Merit: 38
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2021, 10:25:27 AM |
|
Have u heard of an implementation of SEC256K1 addition on FPGA or ASIC (ASIC miner have only optimised implementation for sha256)?
Regards
Fanch
ASIC == Application Specific Integrated Circuit. It's baked specifically for one task (SHA256) and can not be easily made to do something else. Ok thanks, so lets say i wanted to attempt to solve/crack a private key for a 128bit key, or 256bit key, is there a setting, or how do i program it to crack that, or is it just automatic?
By using
0 FFFFFFFFFFFFFFFFFFFFFFFFF
will that check the entire keyspace of a standard 128bit key?
You can do zero padding like this: 000000000000000000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFFF But realize that it's a large number: 1267650600228229401496703205375
|
|
|
|
_Counselor
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 107
Merit: 61
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2021, 12:39:44 PM |
|
Are my calculation are correct?
To solve #120 you need about 2^60.5 group operations. If GPU speed is 4 billion op/s (~2^32), then it will takes 2^28.5 seconds to solve. 2^28.5 seconds is ~4393 days 4393 days / 8 GPUs = ~549 days to solve. There calculations on Kangaroo Github, that #120 will require ~2 months with 256x V100 (~2 billion op/s each)
|
|
|
|
CrunchyF
Jr. Member
Offline
Activity: 54
Merit: 26
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2021, 01:38:02 PM |
|
To solve #120 you need about 2^60.5 group operations. If GPU speed is 4 billion op/s (~2^32), then it will takes 2^28.5 seconds to solve. 2^28.5 seconds is ~4393 days 4393 days / 8 GPUs = ~549 days to solve.
There calculations on Kangaroo Github, that #120 will require ~2 months with 256x V100 (~2 billion op/s each)
Ok thanks for the correction so the average cost will be 549/7 *1000 about 78000 $ (not profitable ;( ) ASIC == Application Specific Integrated Circuit.
It's baked specifically for one task (SHA256) and can not be easily made to do something else.
Yes I know that but i want to know if it feasible to develop such of "specific circuit" by a man or in team in is garage ( ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) )for a relative low cost ? this study gives diagrams for implementing SECP256K1 addition/multiplication/modular inversion on 256bits integers on a FPGA. https://cse.iitkgp.ac.in/~debdeep/osscrypto/psec/downloads/PSEC-KEM_prime.pdfBut i dont know what sort of performance it can have on FPGA (op/s) ? If it is fast for relative low cost parrellised FPGA chips can may be an alternative to GPU?? Maybe is it possible to "convert" this diagram to develop an ASIC.?
|
|
|
|
BASE16
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 180
Merit: 38
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2021, 05:43:13 PM |
|
To solve #120 you need about 2^60.5 group operations. If GPU speed is 4 billion op/s (~2^32), then it will takes 2^28.5 seconds to solve. 2^28.5 seconds is ~4393 days 4393 days / 8 GPUs = ~549 days to solve.
There calculations on Kangaroo Github, that #120 will require ~2 months with 256x V100 (~2 billion op/s each)
Ok thanks for the correction so the average cost will be 549/7 *1000 about 78000 $ (not profitable ;( ) ASIC == Application Specific Integrated Circuit.
It's baked specifically for one task (SHA256) and can not be easily made to do something else.
Yes I know that but i want to know if it feasible to develop such of "specific circuit" by a man or in team in is garage ( ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) )for a relative low cost ? this study gives diagrams for implementing SECP256K1 addition/multiplication/modular inversion on 256bits integers on a FPGA. https://cse.iitkgp.ac.in/~debdeep/osscrypto/psec/downloads/PSEC-KEM_prime.pdfBut i dont know what sort of performance it can have on FPGA (op/s) ? If it is fast for relative low cost parrellised FPGA chips can may be an alternative to GPU?? Maybe is it possible to "convert" this diagram to develop an ASIC.? Maybe you can look at it from a different angle then trying to use the same concept that is used for mining and the use of ASIC/FPGA for these tasks. It does not have to be 256 bit integers, it only has to be 256 bit integers if you are trying to travel to your public point that belongs to your known 256 bit private key. You will visit a lot of intermediate points, which all correspond to valid bitcoin addresses on your way to bit 256. It's possible that you visited some point/address at for example bit 122 that had 100 BTC in it, but you will never know it if you don't look for it and just skip it and discard the data. But make sure that you understand that the nearest public point, if you are not trying to solve a known 256 bit key, is not 256 bits away but just one bit away since it is K+1 or Q+1G. So that is 1 bit and not 256 bits. Make sure you understand this so that you can use it to optimize your ideas, when it comes to collisions it can also be modified from SECP256K1 to SECP1K1 so realize that its not always 256 or an average of 128 point calculations there is a difference between talking about a specific point, and talking about any point. A specific point will need to go through the entire loop of 256 bits, but any point is just any point on which you can throw any number of *G's. For example if the (first) last bit of your private key is a 1 then this will rule out the entire key space below that number and it's only one step to get into that range, not 256 or 128.
|
|
|
|
Stroncow
Jr. Member
Offline
Activity: 38
Merit: 13
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2021, 05:47:22 PM |
|
I know the specific range, but I don't know my public key, as no money was sent from my wallet address. Therefore, I cannot use the kangaroo software. If possible, my request from you; I want you to add the RIPEMD-160 focused option. You may be short on time or you may wish not to. I would like to know if this is possible. So can I run the software focused on RIPEMD-160?
|
|
|
|
_Counselor
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 107
Merit: 61
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2021, 05:58:35 PM |
|
I know the specific range, but I don't know my public key, as no money was sent from my wallet address. Therefore, I cannot use the kangaroo software. If possible, my request from you; I want you to add the RIPEMD-160 focused option. You may be short on time or you may wish not to. I would like to know if this is possible. So can I run the software focused on RIPEMD-160?
This is impossible, all known ECDLP algorithms works with public key. Without knowing the public key, the only possible option to find out the private key is bruteforce.
|
|
|
|
bigvito19
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2021, 07:17:15 PM |
|
This is just not true. The RAM consumed/used is not dependent on the bits being search...it comes down to your DP setting and how often you save the work file. I don't see your settings/flags when starting the program but you are using a very low -d setting or that plus using a long save to file time.
I can see now that searching a 256-bit interval will become feasible if we use 128+ bits of DP mask ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Seems like some good news pertaining with kangaroo.
|
|
|
|
CrunchyF
Jr. Member
Offline
Activity: 54
Merit: 26
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 15, 2021, 09:55:28 PM |
|
Maybe you can look at it from a different angle then trying to use the same concept that is used for mining and the use of ASIC/FPGA for these tasks. It does not have to be 256 bit integers, it only has to be 256 bit integers if you are trying to travel to your public point that belongs to your known 256 bit private key. You will visit a lot of intermediate points, which all correspond to valid bitcoin addresses on your way to bit 256. It's possible that you visited some point/address at for example bit 122 that had 100 BTC in it, but you will never know it if you don't look for it and just skip it and discard the data. But make sure that you understand that the nearest public point, if you are not trying to solve a known 256 bit key, is not 256 bits away but just one bit away since it is K+1 or Q+1G. So that is 1 bit and not 256 bits. Make sure you understand this so that you can use it to optimize your ideas, when it comes to collisions it can also be modified from SECP256K1 to SECP1K1 so realize that its not always 256 or an average of 128 point calculations there is a difference between talking about a specific point, and talking about any point. A specific point will need to go through the entire loop of 256 bits, but any point is just any point on which you can throw any number of *G's. For example if the (first) last bit of your private key is a 1 then this will rule out the entire key space below that number and it's only one step to get into that range, not 256 or 128 Sorry but i'm not sure to fully understand what you said about bits (1 vs 256). I understand about the kangaroo algorithm that it forces you to perform a group addition at every jumps of every kangaroo of the herd (wild or tame) in affine coordinate you have to calculate the next jump with this function (whatever the range size) X(i+1)=X(i)+deterministic_random_walk[G,2G,4G...] m = (y1 - y2) * inverse_mod(x - xG,P) xQ = pow(m,2,P) - x1 - xG yQ = y1 + m * (xQ - x1) Q = (xQ %P -yQ %P) knowing that P is about 2^256, you cannot reduce the size of the integers used in this function below 256bits because the result coordinate of point Q will be (about randomly) between (x,y) = ([1 -- 2^256],[1 -- 2^256]) and u need all this information to compute the next point (whatever DP bits used) it is this costly addition function that i want to implement in my hypothetical ASICs of FPGA's chips (parrellised). Storing the X coordinates (masked with DP) of every jump (calculate with the dedicated devices) in a hash table could be achieved with a centralized computer with a lot of ram.
|
|
|
|
NotATether
Legendary
Offline
Activity: 1694
Merit: 7171
In memory of o_e_l_e_o
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2021, 04:34:54 AM |
|
I know the specific range, but I don't know my public key, as no money was sent from my wallet address. Therefore, I cannot use the kangaroo software. If possible, my request from you; I want you to add the RIPEMD-160 focused option. You may be short on time or you may wish not to. I would like to know if this is possible. So can I run the software focused on RIPEMD-160?
If any transaction has been made to the address then it's public key will be exposed on the blockchain and you can inspect it's value inside the public script using a block explorer. If not, which is the case here, then it means that you're trying to solve an address with no bitcoins inside (a purely academic problem) and you need to use BitCrack instead, which does work with RIPEMD160.
But i dont know what sort of performance it can have on FPGA (op/s) ? If it is fast for relative low cost parrellised FPGA chips can may be an alternative to GPU?? Maybe is it possible to "convert" this diagram to develop an ASIC.?
AWS has some rentable FPGAs, but it'll be incredibly hard finding an FPGA developer.
knowing that P is about 2^256, you cannot reduce the size of the integers used in this function below 256bits because the result coordinate of point Q will be (about randomly) between (x,y) = ([1 -- 2^256],[1 -- 2^256]) and u need all this information to compute the next point (whatever DP bits used)
it is this costly addition function that i want to implement in my hypothetical ASICs of FPGA's chips (parrellised).
Storing the X coordinates (masked with DP) of every jump (calculate with the dedicated devices) in a hash table could be achieved with a centralized computer with a lot of ram.
Fortunately the jump distance can be reduced to, well, as low as you want. Part of the costly addition is deriving Y from X, which slows down the number of keys that can be solved. Given that nobody fills up their DP table it makes sense to cache Y as well in the DP table (which btw can be reduced to a vector if we stop using the entire lower qword of X as the dp ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) and also test its NOT in collision tests )
|
|
|
|
CrunchyF
Jr. Member
Offline
Activity: 54
Merit: 26
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2021, 03:40:57 PM |
|
AWS has some rentable FPGAs, but it'll be incredibly hard finding an FPGA developer.
Ok thanks i' don't know that, (amazon EC2 F1 on AWS) I made some search about FPGA performance on secp256k1 operations. https://github.com/ZcashFoundation/zcash-fpga/blob/master/zcash_fpga_design_doc_v1.4.2.pdf
this paper (from Zcash fondation) presents some benchmarks of a well optimised group operation on secp256k1 implementating on an AWS FPGA (Zcash has the same curve than bitcoin). Point addition is "only" about (1.9M op/s). maybe it is possible to optimise it for the kangaroo algorithm but we are far away from the Giga op / s with the latest GPU.
|
|
|
|
NotATether
Legendary
Offline
Activity: 1694
Merit: 7171
In memory of o_e_l_e_o
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2021, 06:40:11 PM |
|
Quick someone give me sample start and end range with public keys, I think my 256-bit extension mod is done but I need to test it.
|
|
|
|
|