 Show Posts
|
|
Pages: [1] 2 »
|
Server autorestart now works fine. You calmed me down, gentlemen. I must admit that I hope to find # 110 in the next few days ... I will remember you if I do it, and of course about the author of this tool, to which I already owe a lot :-)
Greetings !
How much power are you going to use for this task? I have currently engaged a total power of 460000Mkeys/s. #110 I have at the moment [DP Count 2^26.87 / 2^27.55] Why even bother with #110 with that kind of power? Now theres no point in anyone else even trying to solve it because it's almost certain you will. |
|
|
|
Who else other than you has that kind of GPU power?
Those of us lucky to have 4 2080 Ti's have no chance of solving anything in time.
A lot of miners do, but we do not have a server with the much RAM available to solve the (110-bit interval) problem as fast as possible. So we need to come up with the best time-memory trade-off parameters. Also, I by far are more interested in the intellectual challenge, although the prize (in BTC) can be a very good motivator for some. Why don't you focus on the harder 115 and 120 bit problems and give the smaller people a chance? You have 20-30 times the GPUs of most people here. |
|
|
|
This is the next public key (#110, with a private key in range [ 2^109 , 2^110 - 1], 109 bit) they have been looking for over 7,5 months (about 225 days):
0309976ba5570966bf889196b7fdf5a0f9a1e9ab340556ec29f8bb60599616167d
(address: 12JzYkkN76xkwvcPT6AWKZtGX6w2LAgsJg)
The Pollard's kangaroo ECDLP solver needs 2*(2^(109/2)) = 2^55.5 steps to retrieve this private key, a GPU that computes 2^30 steps/sec would take 2^25.5 seconds, about 550 days.
128 RTX 2080 Tis. Who else other than you has that kind of GPU power? Those of us lucky to have 4 2080 Ti's have no chance of solving anything in time. |
|
|
|
p.s. a bit nitpick-y but there are 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 private keys which is a little smaller than 2 256  I'm trying to understand it but failed. Why not 2^256? They are hashes right? Like strings. All possible combinations. Where is the mistake?  They are not hashes. Public keys are X,Y points on a very large curve which has just under 2^256 points. |
|
|
|
How much energy would be necessary? Well, a lot, according to this infographic:  I was never truly happy with that picture, so your thread got me thinking how to explain the energy requirements in a different way: "If you had a computer that could do those calculations within a human's lifetime and were the size of the earth or smaller, and you actually somehow had an energy source to power it, as soon as you'd turn it on, you'd turn the earth into a supernova."More detailed explanation in a more technical thread about it: https://bitcointalk.org/index.php?topic=5216788I've never liked that image because its misleading. We already know of ways to crack private keys that dont require 2^256 work. |
|
|
|
2019-07-19 13:53:38 62:161##a:0(4)##9:0(4)##8:6(4)##5:28(1)##2:98(9)##1:127(30) C1:373261 Str='11111111122222889a1111111112228a1a19111921811a511119' Av1:2.359 in sec Av2:290692446961262 in sec: CurDec:142042932044673649537278731434510563946471548172750992
2019-07-19 13:56:56 62:161##a:0(4)##9:0(4)##8:6(4)##5:28(1)##2:98(9)##1:127(30) C1:373267 Str='11111111122222889a1111111112228a1a1911192911811a1115' Av1:2.3561 in sec Av2:290329139949209 in sec: CurDec:142042932044673649537278731434510563946471739286467672
2019-07-19 13:59:00 62:161##a:0(4)##9:0(4)##8:6(4)##5:28(1)##2:98(9)##1:127(30) C1:373559 Str='11111111122222889a1111111112228a1a19112111181111959a' Av1:2.3561 in sec Av2:290102131961043 in sec: CurDec:142042932044673649537278731434510563946480663124511842
2019-07-19 14:01:00 62:161##a:0(4)##9:0(4)##8:6(4)##5:28(1)##2:98(9)##1:127(30) C1:374096 Str='11111111122222889a1111111112228a1a1911211119a8111159' Av1:2.3577 in sec Av2:289882730216322 in sec: CurDec:142042932044673649537278731434510563946480663526645012
2019-07-19 14:04:09 62:161##a:0(4)##9:0(4)##8:6(4)##5:28(1)##2:98(9)##1:127(30) C1:374319 Str='11111111122222889a1111111112228a1a19112111811a911159' Av1:2.3563 in sec Av2:289537844712345 in sec: CurDec:142042932044673649537278731434510563946480678146854792
Searcing in range from 62 to 161 bits. Speead over 280 Trillion addresses in second. Finding more than 2 addresses per second, matching a specific pattern. Found applicants are compared with more than 6 thousand addresses. And then sent to another thread to search the current block. PHP and one core on cpu.  PS. Str not hex priv key. This is own format data. And CurDec not deceminal priv key. what script is this? can you share? thanks! Own development. Still in development. Raw to publish in public. how can you generate trillions of keys with a simple cpu and php ? He's likely using a hash table or bloom filter and multiplying the size of that by how many queries he can make per second. |
|
|
|
hi i know displaying any parts of private key is dangerous ( Especially the first character ! )
is possible Brute-force attack ethereum private key missing a 20 character in the end ?! - What time is expected
i think it's possible and Easy Especially ethereum the range ( 0-9 , A-F ) The odds are lower
What do you think about that?
You have all of the private key except 20 characters (80 bits)? Then it is possible and feasible to recover the entire key using baby-step-giant-step or pollard's tho algorithm. It will require 2^40 work, which is a few hours on a GPU. |
|
|
|
|
It takes brain power to come up with ways to check keys fast. Why do you think the BitCrack program can test a billion keys per second on a single video card while the Large Bitcoin Collider could test millions on the same card?
|
|
|
|
I tried to read as much as I can from this thread. I understood how each subsequent key has a bigger interval than the one before it, but I don't understand how the highest keys were also spent?
If this was the hex for the 57th key :
0x00000000000000000000000000000000000000000000000001eb25c90795d61c
which I assume is a random between (57bits)1FFFFFFFFFFFFFF and 100000000000000.
How were the highest outputs spent? Wouldn't they be extremely hard to find because of the massive 256-bit max range? I don't get it..
The creator still knows the private keys. Theres a post around here with him explaining what he did. He realized that the 161 to 256 bit puzzles are pointless since they will never be more difficult than 160 bits as there are only 2^160 possible addresses. So he moved the funds from those puzzles into the lower puzzles. |
|
|
|
|
What's the point of doing a conversion? Better to build a client from scratch that is compliant with the Bitcoin protocol.
|
|
|
|
|
If it's a 2048 word list, then 6 words is 2048^6 = 2^66 possible combinations. Not impossible. That is just over 1 year at 2 trillion keys per second.
|
|
|
|
I am not surprised the OP did a much better job than me with this  What does surprise me is that the donation address is a 1x, I expected a Segwit address from such a sophisticated user. Or is it a case of his 1x address really being a Segwit or script of some kind, last year I remember researching you could translate a 3x to a 1x, but I cannot remember how I am also not surprised I cannot compile out of the box on my VS 2017, all kinds of errors. What does surprise me though is that some code in there, perhaps from the Cuda Toolkit, even tells me "this code will only work in VS 2010.... 2017", so it does not recognize my VS version, WTF! This is a bug in CUDA. It doesn't know what the latest version of Visual Studio is. Edit <Your CUDA toolkit path>/9.2/include/crc/host_config.h so that the header matches your Visual Studio version. e.g.: #if _MSC_VER < 1600 || _MSC_VER > 1911
becomes: #if _MSC_VER < 1600 || _MSC_VER > 1915
|
|
|
|
@arulbero
If you have the public key and the search space is 2^160 how fast can you find the private key?
It would require 2^80 work. That is just beyond what is currently feasible today. But not impossible. |
|
|
|
Is it possible to run LBC on an offline machine and update it manually every week for example?? I know there would be some useless work will be done due to other clients searching the same space before my offline machine does it.
If so, how would I do that??
There's a project where someone made an independent offline client. You can search any key range and address you want: https://github.com/brichard19/BitCrack |
|
|
|
We are developing the fastest ASIC chip for Bitcoin mining. Recently we decided to make our project open sorce. But the community does not even recognize our project, which belongs to Bitcoin. Any attempts to place our topic here - in the branch about Bitcoin mining on ASIC chips, lead to the fact that our topic is thrown into the branch with the Altkoins.
Similarly, the community does not provide any investment for development. Today, we can not even collect $ 750 to register our company in state bodies in order to be able to conclude an NDA contract with a chip manufacturing plant in Taiwan. And this happens at the time of the stagnation of the crypto currency market, when new technologies can make a breakthrough in the crypto economy.
Two questions follow from this:
1) Do anyone need new ASIC technologies for Bitcoin mining?
2) Since when did the development of ASIC for Bitcoin mining begin to be considered the development of Altcoin? And why?
I just want to understand what our team is doing. Maybe we do what no one needs?
In advance I thank for answers. I hope this topic will not be moved to the Altkoins. Otherwise, we will be very disappointed in the modern crypto community.
If your project is open-source, where is it hosted? Can we see your material? Your ASIC designs? |
|
|
|
|
There is another project BitCrack that does the same thing and some people are getting 440 million keys per second on a GTX 1080. Why is it so much faster than VanityGen??
|
|
|
|
|
satoshinnakamoto
It's a fake. And a very low effort one at that.
|
|
|
|
|
There are tools out there for brute-forcing wallet passwords. I'd recommend trying only the open-source ones.
|
|
|
|
|
2^-1 (mod n) = 57896044618658097711785492504343953926418782139537452191302581570759080747169
2 * 57896044618658097711785492504343953926418782139537452191302581570759080747169 = 1 (mod n)
Multiplying a point by this number will "half" the point.
|
|
|
|
|
