Search content
Sort by
Showing 20 of 30 results by BitCrack
hi @BitCrack
Will you consider releasing a server-client version of bitcrack ?
Will you consider releasing a server-client version of bitcrack ?
Yes, I have been working on it for a little while.
https://github.com/brichard19/eclambda
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
I tried your tool (DP18) on a V100.
Code:
[2020-06-22.11:35:35] [Info] DP: 0 TP: 0 853.74 Mpt/s (64 iter/s)
[2020-06-22.11:35:37] [Info] Verifying 40336 results
[2020-06-22.11:35:45] [Info] DP: 0 TP: 0 992.50 Mpt/s (75 iter/s)
[2020-06-22.11:35:48] [Info] Verifying 40362 results
[2020-06-22.11:35:55] [Info] DP: 0 TP: 0 991.18 Mpt/s (75 iter/s)
[2020-06-22.11:35:37] [Info] Verifying 40336 results
[2020-06-22.11:35:45] [Info] DP: 0 TP: 0 992.50 Mpt/s (75 iter/s)
[2020-06-22.11:35:48] [Info] Verifying 40362 results
[2020-06-22.11:35:55] [Info] DP: 0 TP: 0 991.18 Mpt/s (75 iter/s)
Kangaroo on a server too, configured in the same way, however, it is not clear how many kangaroo are running in parallel with your program and what grid setting is used.
Code:
GPU: GPU #0 Tesla V100-PCIE-16GB (80x64 cores) Grid(160x128) (207.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^21.32 kangaroos [11.2s]
[2000.07 MK/s][GPU 2000.07 MK/s][Count 2^37.48][01:52][Server OK]
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^21.32 kangaroos [11.2s]
[2000.07 MK/s][GPU 2000.07 MK/s][Count 2^37.48][01:52][Server OK]
It says exactly how many kangaroos are running in parallel:
Code:
eclambda --name testjob85 --gpu-mem-usage 0.9 --device 2
______ ______ __ ___ __ ___ ____ ____ ___
/ ____// ____/ / / / | / |/ // __ ) / __ \ / |
/ __/ / / / / / /| | / /|_/ // __ |/ / / // /| |
/ /___ / /___ / /___ / ___ | / / / // /_/ // /_/ // ___ |
/_____ / \____/ /_____//_/ |_|/_/ /_//_____//_____//_/ |_|
EC LAMBDA CLIENT
VERSION 1.1.1 ALPHA
[2020-06-22.16:26:33] [Info] Connecting to 127.0.0.1
[2020-06-22.16:26:34] [Info] Target public key:
[2020-06-22.16:26:34] [Info] X:F1367CC260779F7EA6C7E4B7258A4D31A4C41D6282C5200571CE10E748A4AADE
[2020-06-22.16:26:34] [Info] Y:0743F0CA057C7F39A9D9A20D4A93555B19F712920EEEF2F267466A2F3D08662E
[2020-06-22.16:26:34] [Info] Distinguisher: 24 bits
[2020-06-22.16:26:34] [Info] Sending results to server every 10 minutes
[2020-06-22.16:26:34] [Info] Initializing GeForce RTX 2080 SUPER
[2020-06-22.16:26:34] [Info] Compiling OpenCL kernels...
[2020-06-22.16:26:34] [Info] Initializing...
[b][2020-06-22.16:27:09] [Info] Generating 58,395,776 starting points (7184.1MB)[/b]
[2020-06-22.16:27:37] [Info] 10.0%
[2020-06-22.16:27:42] [Info] 20.0%
[2020-06-22.16:27:48] [Info] 30.0%
[2020-06-22.16:27:50] [Info] 40.0%
[2020-06-22.16:27:50] [Info] 50.0%
[2020-06-22.16:27:50] [Info] 60.0%
[2020-06-22.16:27:51] [Info] 70.0%
[2020-06-22.16:27:51] [Info] 80.0%
[2020-06-22.16:27:52] [Info] 90.0%
[2020-06-22.16:27:52] [Info] 100.0%
[2020-06-22.16:27:54] [Info] Refilling GPU cache (319.3MB)
[2020-06-22.16:27:54] [Info] 10.0%
[2020-06-22.16:27:54] [Info] 20.0%
[2020-06-22.16:27:55] [Info] 30.0%
[2020-06-22.16:27:55] [Info] 40.0%
[2020-06-22.16:27:55] [Info] 50.0%
[2020-06-22.16:27:55] [Info] 60.0%
[2020-06-22.16:27:55] [Info] 70.0%
[2020-06-22.16:27:55] [Info] 80.0%
[2020-06-22.16:27:55] [Info] 90.0%
[2020-06-22.16:27:55] [Info] 100.0%
[2020-06-22.16:27:55] [Info] Tuning started
[2020-06-22.16:27:55] [Info] Results collection thread started
[2020-06-22.16:28:05] [Info] DP: 0 TP: 0 587.62 Mpt/s (10 iter/s)
[2020-06-22.16:28:15] [Info] DP: 0 TP: 0 1212.69 Mpt/s (20 iter/s)
[2020-06-22.16:28:25] [Info] DP: 0 TP: 0 1170.13 Mpt/s (20 iter/s)
[2020-06-22.16:28:28] [Info] Tuning complete
[2020-06-22.16:28:35] [Info] DP: 0 TP: 0 1187.71 Mpt/s (20 iter/s)
[2020-06-22.16:28:40] [Info] Verifying 2785 results
[2020-06-22.16:28:45] [Info] DP: 0 TP: 0 1325.58 Mpt/s (22 iter/s)
[2020-06-22.16:28:55] [Info] DP: 0 TP: 0 1322.54 Mpt/s (22 iter/s)
[2020-06-22.16:29:05] [Info] DP: 0 TP: 0 1315.67 Mpt/s (22 iter/s)
______ ______ __ ___ __ ___ ____ ____ ___
/ ____// ____/ / / / | / |/ // __ ) / __ \ / |
/ __/ / / / / / /| | / /|_/ // __ |/ / / // /| |
/ /___ / /___ / /___ / ___ | / / / // /_/ // /_/ // ___ |
/_____ / \____/ /_____//_/ |_|/_/ /_//_____//_____//_/ |_|
EC LAMBDA CLIENT
VERSION 1.1.1 ALPHA
[2020-06-22.16:26:33] [Info] Connecting to 127.0.0.1
[2020-06-22.16:26:34] [Info] Target public key:
[2020-06-22.16:26:34] [Info] X:F1367CC260779F7EA6C7E4B7258A4D31A4C41D6282C5200571CE10E748A4AADE
[2020-06-22.16:26:34] [Info] Y:0743F0CA057C7F39A9D9A20D4A93555B19F712920EEEF2F267466A2F3D08662E
[2020-06-22.16:26:34] [Info] Distinguisher: 24 bits
[2020-06-22.16:26:34] [Info] Sending results to server every 10 minutes
[2020-06-22.16:26:34] [Info] Initializing GeForce RTX 2080 SUPER
[2020-06-22.16:26:34] [Info] Compiling OpenCL kernels...
[2020-06-22.16:26:34] [Info] Initializing...
[b][2020-06-22.16:27:09] [Info] Generating 58,395,776 starting points (7184.1MB)[/b]
[2020-06-22.16:27:37] [Info] 10.0%
[2020-06-22.16:27:42] [Info] 20.0%
[2020-06-22.16:27:48] [Info] 30.0%
[2020-06-22.16:27:50] [Info] 40.0%
[2020-06-22.16:27:50] [Info] 50.0%
[2020-06-22.16:27:50] [Info] 60.0%
[2020-06-22.16:27:51] [Info] 70.0%
[2020-06-22.16:27:51] [Info] 80.0%
[2020-06-22.16:27:52] [Info] 90.0%
[2020-06-22.16:27:52] [Info] 100.0%
[2020-06-22.16:27:54] [Info] Refilling GPU cache (319.3MB)
[2020-06-22.16:27:54] [Info] 10.0%
[2020-06-22.16:27:54] [Info] 20.0%
[2020-06-22.16:27:55] [Info] 30.0%
[2020-06-22.16:27:55] [Info] 40.0%
[2020-06-22.16:27:55] [Info] 50.0%
[2020-06-22.16:27:55] [Info] 60.0%
[2020-06-22.16:27:55] [Info] 70.0%
[2020-06-22.16:27:55] [Info] 80.0%
[2020-06-22.16:27:55] [Info] 90.0%
[2020-06-22.16:27:55] [Info] 100.0%
[2020-06-22.16:27:55] [Info] Tuning started
[2020-06-22.16:27:55] [Info] Results collection thread started
[2020-06-22.16:28:05] [Info] DP: 0 TP: 0 587.62 Mpt/s (10 iter/s)
[2020-06-22.16:28:15] [Info] DP: 0 TP: 0 1212.69 Mpt/s (20 iter/s)
[2020-06-22.16:28:25] [Info] DP: 0 TP: 0 1170.13 Mpt/s (20 iter/s)
[2020-06-22.16:28:28] [Info] Tuning complete
[2020-06-22.16:28:35] [Info] DP: 0 TP: 0 1187.71 Mpt/s (20 iter/s)
[2020-06-22.16:28:40] [Info] Verifying 2785 results
[2020-06-22.16:28:45] [Info] DP: 0 TP: 0 1325.58 Mpt/s (22 iter/s)
[2020-06-22.16:28:55] [Info] DP: 0 TP: 0 1322.54 Mpt/s (22 iter/s)
[2020-06-22.16:29:05] [Info] DP: 0 TP: 0 1315.67 Mpt/s (22 iter/s)
It automatically finds the best grid size, so I do not know if it's useful to even display it.
Increasing --gpu-mem-usage increases performance. By default it's low to avoid timing out/crashing for people testing it on display GPUs.
https://github.com/brichard19/eclambda
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
Will you commit your source ?
I have not yet decided if I want to.
https://github.com/brichard19/eclambda
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
Can anyone try my tool on a 2080ti? On a 2080S it gets around 1300MKeys/sec when using 24-bit DP.
@mrxtraf
In the private key group (mod n) we can add, negate, and invert - this allows for multiplication and division.
In the public key group (elliptic curve mod p of size n) we can add, negate, and double only. This leads to multiplication by a scalar.
One public key corresponds to exactly one private key, and vice versa. The proof is very easy. Let G is the generator of secp256k1. Let P=k*G is a point on the curve. Let also P=k'*G. Then (k-k')*G=O => (k-k') divides n. But n is prime, hence k=k' (mod n).
That is, you can’t divide the public key by 10?In the private key group (mod n) we can add, negate, and invert - this allows for multiplication and division.
In the public key group (elliptic curve mod p of size n) we can add, negate, and double only. This leads to multiplication by a scalar.
One public key corresponds to exactly one private key, and vice versa. The proof is very easy. Let G is the generator of secp256k1. Let P=k*G is a point on the curve. Let also P=k'*G. Then (k-k')*G=O => (k-k') divides n. But n is prime, hence k=k' (mod n).
Give me any public key from which you know the private key, I will divide it by 10. And I will give in return the result in the form of a public key. And you yourself divide the private key by 10, get the public key from it and compare.
The multiplication (and division, which is multiplication with the inverse) is by scalar only. You cannot multiply two public keys without solving ECDLP first. And if you somehow can, then all coins are belong to you.
mrxtraf is saying they can "divide" the public key by 10 by multiplying the public key by the multiplicative inverse of 10 mod n.
apply your algo and show me pubkey div by 789 for
03D041CF467F485A96AB21EC0E1E1E26A344B28A12244320C4BDE48C123653D88F
Sure.
The inverse of 789 mod n = 90549707299650307447836879278023370272751301850683416988678562304583910826370
Multiply your public key by that and you get:
035776B3684B6A5E9A6307AA53C3D484AABB90244E6371405C114CF8910A9A3BD0
@mrxtraf
In the private key group (mod n) we can add, negate, and invert - this allows for multiplication and division.
In the public key group (elliptic curve mod p of size n) we can add, negate, and double only. This leads to multiplication by a scalar.
One public key corresponds to exactly one private key, and vice versa. The proof is very easy. Let G is the generator of secp256k1. Let P=k*G is a point on the curve. Let also P=k'*G. Then (k-k')*G=O => (k-k') divides n. But n is prime, hence k=k' (mod n).
That is, you can’t divide the public key by 10?In the private key group (mod n) we can add, negate, and invert - this allows for multiplication and division.
In the public key group (elliptic curve mod p of size n) we can add, negate, and double only. This leads to multiplication by a scalar.
One public key corresponds to exactly one private key, and vice versa. The proof is very easy. Let G is the generator of secp256k1. Let P=k*G is a point on the curve. Let also P=k'*G. Then (k-k')*G=O => (k-k') divides n. But n is prime, hence k=k' (mod n).
Give me any public key from which you know the private key, I will divide it by 10. And I will give in return the result in the form of a public key. And you yourself divide the private key by 10, get the public key from it and compare.
The multiplication (and division, which is multiplication with the inverse) is by scalar only. You cannot multiply two public keys without solving ECDLP first. And if you somehow can, then all coins are belong to you.
mrxtraf is saying they can "divide" the public key by 10 by multiplying the public key by the multiplicative inverse of 10 mod n.
It's available here: https://github.com/brichard19/eclambda
Basically, start the server, use the jobsubmit program to submit the problem details (public key, key length, DP bits) to the server, and use the client to retrieve work from the server and submit results back to the server.
Basically, start the server, use the jobsubmit program to submit the problem details (public key, key length, DP bits) to the server, and use the client to retrieve work from the server and submit results back to the server.
Etar, if you are talking about 100 bitcoin challenge competition, all the addresses have the pattern: their 1st (big endian) bit always equals to '1'. You can see for every found private key and present it in binary format, and you can see that the 1st bit always '1' (i mean the 1st of unknown part, without leading zeros).
For example, the key for 80bit address was 0xEA1A5C66DCC11B5AD180, and it is in binary:
11101010000110100101110001100110110111001100000100011011010110101101000110000000
The 1st is '1'.
HardwareCollector absolutely right saying that 80bit address has 79bit search range. And this applies to any other key: n-bit address has (n-1) bit search range.
But every key in 80 bit range will have a "1" at the 80 bit marker, or else it would be a different bit. Turn that 1 into a 0 and if it's followed by a 1, then it's a 79 bit key.For example, the key for 80bit address was 0xEA1A5C66DCC11B5AD180, and it is in binary:
11101010000110100101110001100110110111001100000100011011010110101101000110000000
The 1st is '1'.
HardwareCollector absolutely right saying that 80bit address has 79bit search range. And this applies to any other key: n-bit address has (n-1) bit search range.
The puzzle creator had to make the last bit always 1, otherwise it would be possible that two private keys would be in the same search range when doing a sequential brute-force search. Making the high bit 1 guarantees that the next puzzle will be 1 bit longer than the previous.
⭐ Merited by Tamarindei (1)
I am working on pool to solve keys together.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
-----
So far, the biggest problem is the verification of DP. The CPU is not able to check every DP, it simply does not have enough resources for this.
As an option, in order to prevent forged DPs, HelpServer can check a few percent of the sent.
And send to the ban if the client sends the wrong points.
Maybe someone knows how to easily and effectively check points, because multiplying the distance by G is a resource-intensive process.
Are you sure?
key #110 was solved with 2^30.55 DP in 2 days
A normal cpu can compute consecutive keys very fast, my cpu computes almost 30 Mkeys/s, let's say 2^24 keys/s; it would take less than 2 minutes to check 2^30 points
computing random points is slower, but even if it takes x100, we are talking about 3 hours for the entire hash table.
With a simple python script I can get 2^12 keys/s, but it is not tailored for the public keys with private keys so short (under 128 bit) it could reach at least 2^13 keys/s with keys so short.
If you need it I can put together a C program, I think at least 100k key/s are possible, then 2^30 points in less than 3 hours; what speed do you think you need? How much DPs you want to check per hour?
You would need to check that the DP is actually valid though. That involves performing the entire walk. If you did this for every DP you would be re-doing the entire computation.
One way to do this would to include a checksum with the DP whete the checksum is the count of each jump point that makes up the DP. To verify it the server multiplies and adds the counts and the jump points together. This would involve more work for the client since it would need to keep count for every walk.
I think some people are drastically underestimating the cost of producing an ASIC. ASICs cost millions of dollars to design and manufacture.
FPGAs are a possibility. I'm not sure how much faster an FPGA will be than a GPU though. You will basically be re-creating the hardware multipliers that already exist on the GPU.
FPGAs are a possibility. I'm not sure how much faster an FPGA will be than a GPU though. You will basically be re-creating the hardware multipliers that already exist on the GPU.
https://cdn.discordapp.com/attachments/511921983655641109/717044247831773184/Unbenannt.PNG
what does all these values mean ?
what is important here the Dp counter all other counters show 2^-inf
btw is someone open to share some workfiles for merge together ?
what does all these values mean ?
what is important here the Dp counter all other counters show 2^-inf
btw is someone open to share some workfiles for merge together ?
DP count is most important. You are running at DP 25, so it will take 2^57 (whatever expected group ops is for 115) - 2^25 (your DP setting) so roughly you want your DP count up to 2^32 to be getting close to solving.
I have files for DP 30. So I need to get close to 2^27 to be getting close to solving. 2^57(expected ops) - 2^30(my DP setting) = 2^27 DP count .
The number of points represented by the DPs is most important. If you are using a 30-bit distinguisher on GPUs, it is going to take way more than 2^27 DP's to solve #115.
How long say you, or better yet, how many DPs do I need? 2^what?
That 2^27 figure assumes the average walk length is 2^30. The GPU works by doing many slow walks in parallel e.g. 60 million walks that do 20 iterations per second. At that rate, it will take 2^30 / 20 seconds = 1.7 years before any of the walks are 2^30. Your DP count is going to be a few powers of 2 higher than 27.
https://cdn.discordapp.com/attachments/511921983655641109/717044247831773184/Unbenannt.PNG
what does all these values mean ?
what is important here the Dp counter all other counters show 2^-inf
btw is someone open to share some workfiles for merge together ?
what does all these values mean ?
what is important here the Dp counter all other counters show 2^-inf
btw is someone open to share some workfiles for merge together ?
DP count is most important. You are running at DP 25, so it will take 2^57 (whatever expected group ops is for 115) - 2^25 (your DP setting) so roughly you want your DP count up to 2^32 to be getting close to solving.
I have files for DP 30. So I need to get close to 2^27 to be getting close to solving. 2^57(expected ops) - 2^30(my DP setting) = 2^27 DP count .
The number of points represented by the DPs is most important. If you are using a 30-bit distinguisher on GPUs, it is going to take way more than 2^27 DP's to solve #115.
bitcrack you got some new software that works?
I have software that works. I am preparing to release it soon. I was running it non-stop since March 31st without any issues in my attempt to solve #110.
wow now one more question, you The bitcrack developer or not?
great release soon, thank you in advance.
Yes, that is me (brichard19).
bitcrack you got some new software that works?
I have software that works. I am preparing to release it soon. I was running it non-stop since March 31st without any issues in my attempt to solve #110.
There seems to be some kind of mistake in this puzzle#110
A huge number of GPU capacities have already been spent and no one could find the key.
I checked the range borders with bsgs, there is no key there.
This was the only version why we could not find the key for so long.
But she is not true. The key is not near the edge.
Someone has an idea why we can’t find the key .. even with the possibility of 400 GPU?
A huge number of GPU capacities have already been spent and no one could find the key.
I checked the range borders with bsgs, there is no key there.
This was the only version why we could not find the key for so long.
But she is not true. The key is not near the edge.
Someone has an idea why we can’t find the key .. even with the possibility of 400 GPU?
I think folks are just being impeded by storage and network issues.
-snip-
There are about 2^256 points, then 2^255 different X-coordinates (k*G and -k*G have the same x-coordinate).
-snip-
There are about 2^256 points, then 2^255 different X-coordinates (k*G and -k*G have the same x-coordinate).
-snip-
Is this proved fact?
I mean why every private key leads to the unique X-coordinate? (except for symmetry point).
In other words, if k and (order-k) leads to x-coordinate Xk, how could we be sure that there are no other key m leads to Xk as well? (m differs from k and (order-k) )
Because it is proved that:
1) for each private key there is only 1 point (n private keys, n points, n is the order of the curve)
2) for each x-coordinate, the y-coordinate must fulfil this relation: y^2 = x^3 + 7 mod n;
each equation of the form y^2 = a has or 2 opposite solutions (+y and -y -> k*G / -k*G), or has no solution.
Therefor there can't be 3 different points with the same x-coordinate and with 3 different y-coordinate, because there are no 3 different y solutions for the equation y^2 = a mod n.
We know that there are exactly (n-1)/2 different x-coordinates (and (n-1)/3 different y-coordinates)
That's how the math works. The points on the curve form a group (https://en.wikipedia.org/wiki/Group_%28mathematics%29) and the point G is a generator of that group.
