 Show Posts
|
|
Pages: « 1 [2] 3 »
|
Error! =========================== VanBitCrackenS1-Distributed-Puzzle-66-Address-Scanner =================================Enter the last range you are scanning: 3BCF5000000000000:3BCF5ffffffffffffResumming your scan...Sorry.. This Range does not exist in the list. Press any key to exit. Why can't I set my range? |
|
|
|
Anyone here knows how to divide a point by 3, 4, 5, 6, 7, 8, 9 and 10 and get a correct result?
Give me a few minutes, you will be amazed, I need to prepare the sample keys on laptop. Stay tuned.😉
Look forward to explanations! Good luck bro! 
5- another form of successive subtraction import secp256k1 as ice
target_public_key = "023d62d9d64a7164a2ae6f0561f7e8317e69b4a1ee61048fe768a1316b39b1d3a7"
target = ice.pub2upub(target_public_key)
num = 10 # number of times.
sustract= 1000 #amount to subtract each time.
sustract_pub= ice.scalar_multiplication(sustract)
res= ice.point_loop_subtraction(num, target, sustract_pub).hex()
print(res) Tell me how to make each pub write from a new line, and not all in one line? |
|
|
|
Alright, after numerous calculations, I've come to the point where I need someone who is interested in puzzle 66 and capable of counting 48 bits within a few minutes. I have a total of 588 ranges for them to work on, with the opportunity to claim the prize of 6.6 BTC. Alternatively, if the author of the puzzle – the one who created this challenge to test the difficulty of increasing bits – has come across my post, I challenge them to assist me in improving my counting speed. I am confident in my ability to crack puzzle 66 in a matter of days.
Hello. Write to me, we will calculate the ranges. |
|
|
|
Hey guys, instead of wasting your eye sight on long and useless base58 WIFs which literally represent 0s in hexadecimal, let me share a little secret regarding public keys. Here is how you can find half of your public key, it's not straight forward method but I bet many of you didn't know about it. First we need to extract 1 and half of our public key then we can subtract our p which is 1 from it's 1.5 to get it's 0.5 half. Though we could just divide it by 2 without all this trouble, this is a hint to make you dive deeper in to this vast ocean of numbers and equations. Target pub: 03219b4f9cef6c60007659c79c45b0533b3cc9d916ce29dbff133b40caa2e96db8 Target priv: Our multiplier inverse or not doesn't matter, +n will give you +n result and vice versa. Scalar : aka n/2+1 half n +1 or 1 and half of n. 7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a2 If you multiply our target pub with scalar above, you will get this : Pub2 : 02161c6cbee1483deaf6f9b395c817eb019228cda5afac5857295ba10959dffc96 Priv : Now if we subtract target from pub2, we will get : Pub3, half of target : 0313d1ffc481509beee68f17d8ff41c2590f4c85f15268605087eda8bab4e218da Priv : We didn't even use division, *chop chop and good luck diving.😅 * = hurry! Get to work. Now, if it were possible to calculate an even target pub or an odd one, then 130 puzzle could be solved in a few hours. |
|
|
|
my code is ready and running now for puzzle 66, but with 250,000 keys per second it will take 1 to 10 months  , I'm improving to have at least 1Mk/s, a dream would be 300Mk/s  What is your code running on ? and is it on github? is running in cuda c++ with a gtx 1650 4GB Unfortunately I can't share the code yet, because as I said a few days ago, people with more resources or experience will find the keys and my work for months will have been in vain, I dedicated everything to this project and I am absolutely sure that This is the way. Okay that's nice. Take all the time you need, get 66,67,68 and 69 then share the code when you have gotten enough resources. The sky is the limit. as of right now, if everyone else were thinking the same way you're thinking, Pollard Kangaroo would still be hidden until now, he'd be hoping to solve all the puzzle before releasing the code. what do you think the puzzles are about? 1+1? The 1+1 stages are all over right now. the bruteforcing part we currently are trying to solve is 66 bits. i know you have a magical code though but if it takes you 1 year on your code it takes everyone else nothing more than 100 years, in regard to the resources or more years for some other people without the resources needed, if you waste too much money to get the resources and it turned out to be unprofitable. what point does it make then? because after you calculate the expenses to run all that machine then you would understand what it's called. left alone, 67 bits is double 66 bits so imagine you will take 2 years to solve that one. If the resources stops becoming profitable then what point does it make trying to bruteforce a key that won't yield any profit after expenses and time spent has been calculated. we can all let you know that puzzles are for fun and not for funds. when you finally realize that, you will think twice after wasting about 5 years using your code without finding any keys whereas if you had made it public, someone might develop it and make it better for your hardwork. You're right, I'm just sad to think that all the work wouldn't be paid, I really bet a lot on it, but I'll share the logic and count on everyone's humility. Hello. It would be interesting to understand the logic of how you managed to reduce the number of possible keys. Respect for your work. |
|
|
|
I don't think you understand the algorithm completely. That algorithm generates 65536 pubkeys and does this as binary in the method used when creating a normal btc wallet address. As a result of this 65536 pubkey, one of them will reduce the pubkey to 109 bits. Our main goal is to find the correct bit range. The algorithm performs the test from the test. The bit sequence is 65536, which is equivalent to 16 bits. The correct sequence of 16 bits is one in 65536. You can multiply this, but it will also increase your processing load. If you examine the bit by bit processes with the code you wrote instead of using ready-made libraries, you will see the result. In other words, the algorithm reduces 125-16=109 bits and 1 pubkey to 109 bits. 65536*65536 =2^32 , Within 2^32 bit addresses, that is, 4294967296 addresses, 1 of them is a pubkey reduced to 2^93 bits. Now, of course, for this 125th puzzle. Depending on your bsgs speed it may take some time to solve. The problem is not that the last digit is even or odd, but because it operates with 0 or 1, it doesn't matter if it's a single even, change the leading bit with the same bit order, you will get different results, so it cannot be solved with even or odd. It can be solved with bits in the correct order So my algorithm works, it outputs a little too many pubkey results.
Yes, your algorithm works! Can you explain why it outputs only odd pubkey results and skips even ones? For example, when dividing by 2, we get: 1,2,5,7 odd pubkeys, and 3,4,6 even pubkeys. The odd ones will be in the list your algorithm outputs, but the even ones won't. |
|
|
|
Interested here is a question. If the end of the key is known, but there is no possibility of reverse recovery. Is it possible to restore the full key in this case? I remember there used to be a wif-solver-cuda program for wif, but is there such a program for hex private key?
https://github.com/Mizogg/Tkinter-Power-MiniWIF HEX DEC Recovery Tools  |
|
|
|
But mine all end with DP of 29 Can you tell me what is dp of 29, you mean the keys ending with 29? DP - number of trailing zeros distinguished point |
|
|
|
I'm sorry, but I can't run your code.
Writes this:
Traceback (most recent call last):
File "D:\user\test.py", line 22, in <module>
print(ters(pub,x))
File "D:\user\test.py", line 14, in ters
if ScalarBin[le-i] == "0":
IndexError: string index out of range
How to fix? Help me please.
from sympy import mod_inverse
import secp256k1 as ice
pub=ice.pub2upub('0433709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e2a1c304a39a77775d3579d077b6ee5e4d26fd3ec36f52ad674a9b47fdd999c48')
N=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
k=mod_inverse(2,N)
neg1=ice.point_negation(ice.scalar_multiplication(1))
def ters(Qx,Scalar):
ScalarBin = str(bin(Scalar))[2:]
le=len(ScalarBin)
for i in range (1,le+1):
if ScalarBin[le-i] == "0":
Qx=ice.point_multiplication(k,Qx)
else:
Qx=ice.point_addition(Qx,neg1)
Qx=ice.point_multiplication(k,Qx)
return ice.point_to_cpub(Qx)
for x in range(1,65536):
print(ters(pub,x)) [/quote] Launched! Thank you very much! |
|
|
|
Yeah .. He, most likely, generated 256 keys and manually updated the first character on the left whenever necessary.
You really think he just changed 1 digit? Some one who is an expert in cryptography would know better, but maybe he didn't want to make it very difficult and really used randomly generated keys. But if I were him, I'd have changed a few characters to make it really really hard, for example having a few 0s in a key will make it hard to reverse engineer a key manually, and brute force/kangaroo, well they have their limits. One other thing could be placing a key outside a bit range, I'm curious did Satoshi ever confirmed that the keys are truly in the assumed bit ranges or we just hope the amounts of transactions are enough of a proof that the keys are exactly there? But you know what I'd like to see? A large amount in a key with no exactly known bit range, somewhere between 160 and 180 bit not lower and not higher, then solving that key would be a global challenge, though not any amount which someone could spend half of it to use special tools and grab it, something which could only be solved by math and new methods. For example, I haven't seen any tool/ algorithm capable of adding or subtracting 1 to a key and then divide it by 2, kangaroo engages square root calculations, BSGS looks for a match after adding/subtracting calculations, but no tool does + or - 1 then divide! Now I look at it from a different angle. In binary, the program is more practical, for example, I know the last 8 bits of the private key anyway, because 8 bits equals a maximum of 256 digits. There was a friend who said that if the curve math is 0, multiply, if 1, add, knowing the last bit means solving ecdsa, the last 8 bits are 1 in 256, you can find the rest. If you say the last 16 bits, there is 1 possibility in 65536, these numbers can be tried, you will reduce 125 bits -16 bits =109bits. This is the code
from sympy import mod_inverse
import secp256k1 as ice
k=mod_inverse(2,N)
neg1=ice.point_negation(ice.scalar_multiplication(1))
def ters(Qx,Scalar):
ScalarBin = str(bin(Scalar))[2:]
le=len(ScalarBin)
for i in range (0,le):
if ScalarBin[le-i] == "0":
Qx=ice.point_multiplication(k,Qx)
else:
Qx=ice.point_addition(Qx,neg1)
Qx=ice.point_multiplication(k,Qx)
return ice.point_to_cpub(Qx)
for x in range(65536):
print(ters(pub,x))
If the last bit is 1, it moves the point forward when divided by (2). 7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1 + if the last bit is 0 then normal divides You trying to do mod_inverse using N. But N what is? N=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 The code doesn't work. NameError: name 'pub' is not defined How to fix? pub=ice.pub2upub('0433709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e2a1c304a39a77 775d3579d077b6ee5e4d26fd3ec36f52ad674a9b47fdd999c48') I'm sorry, but I can't run your code. Writes this: Traceback (most recent call last): File "D:\user\test.py", line 22, in <module> print(ters(pub,x)) File "D:\user\test.py", line 14, in ters if ScalarBin[le-i] == "0": IndexError: string index out of range How to fix? Help me please. |
|
|
|
Yeah .. He, most likely, generated 256 keys and manually updated the first character on the left whenever necessary.
You really think he just changed 1 digit? Some one who is an expert in cryptography would know better, but maybe he didn't want to make it very difficult and really used randomly generated keys. But if I were him, I'd have changed a few characters to make it really really hard, for example having a few 0s in a key will make it hard to reverse engineer a key manually, and brute force/kangaroo, well they have their limits. One other thing could be placing a key outside a bit range, I'm curious did Satoshi ever confirmed that the keys are truly in the assumed bit ranges or we just hope the amounts of transactions are enough of a proof that the keys are exactly there? But you know what I'd like to see? A large amount in a key with no exactly known bit range, somewhere between 160 and 180 bit not lower and not higher, then solving that key would be a global challenge, though not any amount which someone could spend half of it to use special tools and grab it, something which could only be solved by math and new methods. For example, I haven't seen any tool/ algorithm capable of adding or subtracting 1 to a key and then divide it by 2, kangaroo engages square root calculations, BSGS looks for a match after adding/subtracting calculations, but no tool does + or - 1 then divide! Now I look at it from a different angle. In binary, the program is more practical, for example, I know the last 8 bits of the private key anyway, because 8 bits equals a maximum of 256 digits. There was a friend who said that if the curve math is 0, multiply, if 1, add, knowing the last bit means solving ecdsa, the last 8 bits are 1 in 256, you can find the rest. If you say the last 16 bits, there is 1 possibility in 65536, these numbers can be tried, you will reduce 125 bits -16 bits =109bits. This is the code
from sympy import mod_inverse
import secp256k1 as ice
k=mod_inverse(2,N)
neg1=ice.point_negation(ice.scalar_multiplication(1))
def ters(Qx,Scalar):
ScalarBin = str(bin(Scalar))[2:]
le=len(ScalarBin)
for i in range (0,le):
if ScalarBin[le-i] == "0":
Qx=ice.point_multiplication(k,Qx)
else:
Qx=ice.point_addition(Qx,neg1)
Qx=ice.point_multiplication(k,Qx)
return ice.point_to_cpub(Qx)
for x in range(65536):
print(ters(pub,x))
If the last bit is 1, it moves the point forward when divided by (2). 7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1 + if the last bit is 0 then normal divides You trying to do mod_inverse using N. But N what is? N=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 The code doesn't work. NameError: name 'pub' is not defined How to fix? |
|
|
|
Sorry man, but you are getting confuse:
Private key #65 = 00000000000000000000000000000000000000000000001a838b13505b26867
Public key #65 = 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b
On the second point you are talking about, what you are doing is subtracting PK #65 to N, and the result is:
Private key for second point = fffffffffffffffffffffffffffffebaaedce6af48a03a1799ad57ca83d8da
Public key for second point = 0330210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b
PK #65 =/= PK second point
Your confusion strive on the fact that both points share the same x-coordinate, because one is the "reflection" of the other, but the PKs are not the same; and as you can see, none of them are "negatives". There are no negative numbers on ECC.
Good luck to you too, man.
Good luck to you too, man. |
|
|
|
|
This key you call the closest one could have a size half the 2^124.
I might be wrong but somehow I can say with 50% certainty that #125 starts with 0x1c. If I'm right it could help a lot in further lowering the bit range, this has taken me more than 45 days and I am still not sure.
[/quote]
Hello digaran.
Why do you think #125 starts with 0x1c?
|
|
|
|
The thing is that the "x" coordinate of #125 is: 33709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e; so I don't see how do you add "F" to 03 x coordinate of #125. Not only that, but if you switch "02" to "03" on a public key, you are talking about a very different privet key, so 0333709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e is no longer #125.
And BSGS don't use dp, it actually works in a sequential manner, deterministic, and not probabilistic like Kangaroo.
Thanks anyway man, but I think you should re-learn ECC, I can see you are confused on how it works.
Cheers.
Hello. You apparently did not carefully read what @digaran wrote to you. If you change #125 02 to 03, you will get the same private key as #125 but with a minus sign "-"! The public key 0333709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e is also on the EC, but on the other hand. For example, puzzle #65: Private key: 00000000000000000000000000000000000000000000001a838b13505b26867Public key: 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1bPrivate key: fffffffffffffffffffffffffffffebaaedce6af48a03a1799ad57ca83d8daPublic key: 0330210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1bNow do you understand? Well, it's amazing that even you wrote it yourself, you don't realize what your saying. As you can clearly see on your own example "0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b" and "0330210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b" have different privet keys, which is what I wrote, Now do you understand? BTW, there are no privet keys 'with a minus sign "-"!' For example, puzzle #65: Private key: 00000000000000000000000000000000000000000000001a838b13505b26867 = 000000000000000000000000000000000000000000000000000000000000000 + 1a838b13505b26867Public key: 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b Private key: fffffffffffffffffffffffffffffebaaedce6af48a03a1799ad57ca83d8da = fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 - 1a838b13505b26867Public key: 0330210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b As you can see, the key is the same, only in one case it is added, in the other it is subtracted. Now do you understand? |
|
|
|
So If I have to start from a range on BSGS according to your mathematical calculations, which key is the closest that you almost thought could have hit puzzle 125... lets search within that range on BSGS. then we can all share some funds together too.
The closest one is 03ed01ff219ed5c1afc12d991a82e3063ddcee1fd53b46f7cad52a0d87a7112aed, it should be searched for in the 124 range. |
|
|
|
The thing is that the "x" coordinate of #125 is: 33709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e; so I don't see how do you add "F" to 03 x coordinate of #125. Not only that, but if you switch "02" to "03" on a public key, you are talking about a very different privet key, so 0333709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e is no longer #125.
And BSGS don't use dp, it actually works in a sequential manner, deterministic, and not probabilistic like Kangaroo.
Thanks anyway man, but I think you should re-learn ECC, I can see you are confused on how it works.
Cheers.
Hello. You apparently did not carefully read what @digaran wrote to you. If you change #125 02 to 03, you will get the same private key as #125 but with a minus sign "-"! The public key 0333709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e is also on the EC, but on the other hand. For example, puzzle #65: Private key: 00000000000000000000000000000000000000000000001a838b13505b26867Public key: 0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1bPrivate key: fffffffffffffffffffffffffffffebaaedce6af48a03a1799ad57ca83d8daPublic key: 0330210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1bNow do you understand? |
|
|
|
Digaran @
You can't offer anything useful. An endless stream of insanity.!
Look who is talking! Why would I offer something which could help breaking ECC? I can only hint at them, but there are already resourceful people around here explaining everything in details.
I wonder, how many halving do I need to reduce a 125 bit key down to 40 bit? You can always halve a key. However, if your key will be odd, then after halving it, you will end up in a worse situation. SHA-256("125-bit")=c383a1ae19ff4401f72fdfbb4ffeb6fc7a38c6692b07b188edcbdc31b0160ee7
mask125=0000000000000000000000000000000020000000000000000000000000000000
(hash%mask125)=key=000000000000000000000000000000001a38c6692b07b188edcbdc31b0160ee7
key/2=7fffffffffffffffffffffffffffffff6a73d1a7ed2828e256cf1d5f40262814
key-1=000000000000000000000000000000001a38c6692b07b188edcbdc31b0160ee6
(key-1)/2=000000000000000000000000000000000d1c63349583d8c476e5ee18d80b0773See? You can reach a key with less bits, only if you know if it is even or odd. So, if you want to go from 125-bit key to 40-bit key, then guess what: you have to know the last 85 bits. I already know that, we don't want +n key to be odd, halving it would halve the entire -n key which is a number near 2^256, and when we reach the middle range the halving reverses. Complex stuff! 😉
digaran
If you are surprised by the doubling of the original key, then you are still at the very beginning of this "jungle". numbers
I will share with you a little bit what the future holds for you if you have the strength and inspiration to explore the Bitcoin curve.
There are amazing things that can make 100 hours of your work useless and make you happy in the most unexpected place and time of working with a curve.
There are special numbers on the curve that can be used to get exactly 1 digit less.
A third of the number you are looking for.
A quarter of the sought number.
You can get the mirror part of the number you are looking for, which can also be compared with the original.
And this is not even a 10th part of what is there.
You can get a lot.
But by carrying out various manipulations with the numbers on the curve, as vjudeu said, you can get into an even more difficult situation and get a .....................labyrinth.
I wish you success.
Mirror, quarter, third, one digit less, I'm not interested in those, I'm interested to find new ways and equations to solve a puzzle. I live in this jungle, and I rather not pursuit shadows, they take you to dark parts of the woods. Good luck to you too, may the help of God be with you all brothers! We can do this. 🤣 My algorithm is working, it will be smoother with a few minor adjustments. I tried with Puzzle 115 pubkey and reduced it to 2**28 bits in 2 seconds. It took 1 second for the collider application to find the pubkey. Now writing the code to reverse the Algorithm . I don't like working, my brain is almost numb from the blood pressure pills i can't think I'm sorry my English is bad, I'm writing from translate, but I hope you understand what I mean. Hello. Could you share your algorithm? I wonder how you managed this: "Puzzle 115 pubkey and reduced it to 2**28 bits in 2 seconds". Sincerely, be healthy. |
|
|
|
@JBRai
wif missing is less then 6 at any place that can be recovered in 60min more or less. but if you missing checksum in wif it may take while but still possible.
i have made tool for cuda to practically test all possible pair with there checksum. but there are many false positive too.
my tool approach is different what PawGo coded. i use base58 decode and checksum match effort to validate it.
Do you have gpu ? i can send you app for testing.
Hello. Can you please send me your program for testing on the GPU. I sent you a telegram. |
|
|
|
Puzzle 120 solver, definatly very well know about these threads, related developments, bitcrack, kangaroo, vantisearch, keyhunt, bsgs etc,
options are for puzzle 64 and 120, solver never post prvkeys,
maybe puzzle creator ... just for make puzzle live, as no new development, group based attempts by developer, gpu farmers, and individual attempts by useing other develop apps,
reason, puzzle 120 pickup to new address, and no used,
in past every solved puzzle's were cash out by thier solver, for their needs, if they are developer, finder, coder, etc, every one need money, upon they find, they cashout, put puzzle 120 solver too easy, not picked up fork's, and nor cashout, simple transfer to an other address and waiting, what people try new things,
and here threads once asked prvkey, and no more talks, seems every one no more interest, due to silence from solver
*** Puzzle #64 *** Address: 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN PrivKey Hex: 000000000000000000000000000000000000000000000000F7051F27B09112D4 PrivKey WIF: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ6FxoaD5r1kYegmtbaT Pubkey Compressed: 03100611c54dfef604163b8358f7b7fac13ce478e02cb224ae16d45526b25d9d4d |
|
|
|
|
