Search content
Sort by
Showing 19 of 19 results by Tamarindei
For 0.005 btc (~50$) you can contact the person here and get a recent dump:
https://balances.crypto-nerdz.org/
Regards
https://balances.crypto-nerdz.org/
Regards
Re: New Testnet Faucet (tBTC, tBCH, tLTC, tDOGE, tDGB)! Testnet-Faucet.com!
Hi Tech1k!
Can you please explain what a faucet is? Sorry I am newbie in this regard.
Maybe this is the wrong category of this forum for a faucet?
Thx and best regards
Tama
Can you please explain what a faucet is? Sorry I am newbie in this regard.
Maybe this is the wrong category of this forum for a faucet?
Thx and best regards
Tama
[
Besides the corners this picture fits all the clues provided in the initial post and comments about green/white monster part.
Besides the corners this picture fits all the clues provided in the initial post and comments about green/white monster part.
Oh it sounds like LoyceV was close.
I tested it, and it's still wrong 
I won't update my screenshot for this.
I won't update my screenshot for this.Yes i think we must wait for additional hints.
@MrFreeDragon: Please add a selection and move selection tool
.⭐ Merited by LoyceV (1)
so the monster's part is green as well.
That's good to know, until now most of the monsters posted here are white.For a green one, I tried Pacman:
http://loyce.club/other/pacman.gif
Edited from an image I found on Google. So partial credits go to this link, which I can't verify because I block that site via my hosts file.
This is a ghost but should be a winner
.Check your corners. They are not correct base.
I am sure #115, #120 and #125 will go to zielar and no pool can compete. gg.
I disagree.
I spent much time to explain in the readme, in this topics or in the code the way to choose best parameters and trap to avoid.
Zielar has also to win his life and cannot spend full time to solve these puzzles.
It is far from sure that Zielar will win all the races.
Anyway, I'm working on the 1.9 in order to integrate mods from PatataFritas and support of -ws for clients.
Edit: You have no idea who Zielar is actually. He is a very competent person in his domain, I must say that from time to time I pain to follow him !
Sorry Jean Luc. I wrote a little offending. I put some resources into the search for #110 so I was little emotional for a moment. I apologize.
In the end Jean Luc took the chance from all with the knowledge of creating a working Pollard Kangaroo for GPU and gave it to those with the power but no knowledge.
I am sure #115, #120 and #125 will go to zielar and no pool can compete. gg.
I am sure #115, #120 and #125 will go to zielar and no pool can compete. gg.
-snip-
-snip-
Code:
error : Designtime build failed for project 'C:\Users\danh\Desktop\kg\Kangaroo-master\VC_CUDA102\Kangaroo.vcxproj' configuration 'Release|x64'. IntelliSense might be unavailable.
Set environment variable TRACEDESIGNTIME = true and restart Visual Studio to investigate.
Set environment variable TRACEDESIGNTIME = true and restart Visual Studio to investigate.
-snip-
Hi Dan.
I am not using Visual Studio.
I googled the problem and found some solutions that say you should repair the project (I think there is a menu option) or upgrade your visual studio.
-snip-
Checking the DPs only for validity does not mean performing the entire work again. Kangaroos are jumping from one point to another based on visited x-coordinate, and as soon as kangaroo lands the x-coordinate with the determined pattern (i.e. coordinate with 25 leading zeros -----snip-
Checking the DPs only for validity does not mean performing the entire work again. Kangaroos are jumping from one point to another based on visited x-coordinate, and as soon as kangaroo lands the x-coordinate with the determined pattern (i.e. coordinate with 25 leading zeros -----snip-
As far as I understand it is important that the DP is from a real kangaroo walk.
The difference:
As soon as a kangaroo hits a point (a point that is not qualified to be a DP by bitmask) that has been visited by a kangaroo of the other type, their walks are synchronized and the next DP they find will definately result in a collision and PK is found.
This is not the case with randomly selected points in the range that fullfill the DP bitmask criteria.
It is possible that there will be a collision with these kind of "not real walk" points though.
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.
Is it really that important a DP was generated by a walk? Why aren't any points that satisfy the DP criteria (bitmask) valid and usefull?
Maybe different approach for parallalelizing the work:
Q = our target pubkey in 115 bit range
If you have 16 GPUs prepare a new set S of pubkeys:
for n = 0 to 16
S[n] = (Q-n)/16
Now you have a set S with 16 new derived pubkeys where only one is in the range targetBitrange-4 (for 115 they are now in 111 bit range).
So it is true that 15 GPUs will work on pubkeys that are in a different range and this work is useless. But one GPU is working in the correct 111 bit range.
Would this be a benefit?
?
...
Now the idea itself .. Why can not we use the experience of previous work?
...
Now the idea itself .. Why can not we use the experience of previous work?
...
It does hot work because after manipulating the old dps they do not fullill the dp mask condition anymore (leading zeros) and you break the jump paths.
The manipulated dps become a random list of points that are unusable for kangaroo algorithm.
I coded the stuff as it is described in the paper using this:
And a of translation of -N/2.G of the public key to solve in order to have as specified:
It found as expected from time to time the symmetric point.
It is slower than the classic version (~2^21.2 on 40bit search) and far from 1.46sqrt(n)
But, they are not very clear on the jumps and especially the average distance of the jumps.
As the wild are on a shorter range, may be steps have to be different than tame's one (not yet tested).
I also didn't coded a stop and retry after a certain number of jump (sqrt(n) ?), i let the algorithm continue outside the range, so it may loose the symmetry...
To be continued...
Code:
T={{a,−a}:a∈[−N/2,N/2]},
W={{n+a,−(n+a)}:a∈[−N/4,N/4]
W={{n+a,−(n+a)}:a∈[−N/4,N/4]
And a of translation of -N/2.G of the public key to solve in order to have as specified:
Quote
Each experiment involved choosing uniformly at random−N/2≤n≤N/2 and solving the DLP for Q= [n]P.
It found as expected from time to time the symmetric point.
It is slower than the classic version (~2^21.2 on 40bit search) and far from 1.46sqrt(n)
But, they are not very clear on the jumps and especially the average distance of the jumps.
As the wild are on a shorter range, may be steps have to be different than tame's one (not yet tested).
I also didn't coded a stop and retry after a certain number of jump (sqrt(n) ?), i let the algorithm continue outside the range, so it may loose the symmetry...
To be continued...
Did you also re-randomize the point after distinguished point was found?
⭐ Merited by joniboini (10) ,Welsh (4) ,suchmoon (4) ,arulbero (3) ,ETFbitcoin (1) ,o_e_l_e_o (1) ,Heisenberg_Hunter (1)
OK i will try this.
But if you don't have a translation of -(k2-k1)/2 on the wilds (or (k2-k1)/2 on the tames), you get a worst case when the private key of P is at the end of the range.
But if you don't have a translation of -(k2-k1)/2 on the wilds (or (k2-k1)/2 on the tames), you get a worst case when the private key of P is at the end of the range.
I think there's a paper about this already:
https://www.iacr.org/archive/pkc2010/60560372/60560372.pdf
You probably need to detect frutiless cycles with this method (stuck kangaroos in a loop without distinguished points).
Re: brute-forcing public keys at amazing speed 2.2 PH/s on CPU [malware warning]
-snip-
But can you treat these points like if they were random? Can you apply in this case the birthday paradox?
But can you treat these points like if they were random? Can you apply in this case the birthday paradox?
The DP method (distinguished points) with a hashtable is used. That means that every subsequent jump is dependent from the x-coordinate of the current location. That means that pseudorandom walks are used for the kangaroos. No need to store all the visited points for this case.
Yes, this is clear, but these points seem to me not to be really (pseudo)random. There is a order. You can move only forward (from private key's point of view). Therefor many collisions are just impossible to get (instead in the birthday paradox, each new distinguished point has the chance to produce a collision with any previous distinguished point, for example that happens in BTCCollider, because in that case you can jump in any position, you go back and forth across the entire space)
Example with only 2 sequences:
If we suppose that W_100 is = (2^37)*G and T_100 is (2^38)*G, than between T_101, T_102, .... , T_2**32 it is no longer possible to find a single distinguished point with the same coordinate of any distinguished point that lies in W_0, W_1, W_2, ....., W_100. For sure.
Then how do you apply in this case birthday paradox?
It is impossible to get a collision in the path of the same tame kangaroo too, because the same kangaroo cannot turn back, then this is a pseudorandom sequence very particular ...
I think that's why the papers you find don't use the birthday paradox to analyze pollard kangaroo. Birthday paradox is used for the very similar gaudry schost algorithm. Gaudry schost algorithm sets the point to a new random location in the interval as soon as a distinguished point is found and saved.
Re: brute-forcing public keys at amazing speed 2.2 PH/s on CPU [malware warning]
I did few optimizations (commited to github), I reached 13.6M giant steps of 2^30 per second on my Xeon X5647 2.93GHz with 12GB of RAM.
It solves the 16 keys of the odolvlobo's set in 3:35:53 from scratch, I mean without any precomputation.
If I convert to the Etar's unit: It does 14.6 PKey/s.
I posted the result in the readme of my program:
https://github.com/JeanLucPons/BSGS/blob/master/README.md
Thanks to odolvlobo to provide this challenge.
Best wishes to Etar to optimize his program and fix his issue on GPU.
It solves the 16 keys of the odolvlobo's set in 3:35:53 from scratch, I mean without any precomputation.
If I convert to the Etar's unit: It does 14.6 PKey/s.
I posted the result in the readme of my program:
https://github.com/JeanLucPons/BSGS/blob/master/README.md
Thanks to odolvlobo to provide this challenge.
Best wishes to Etar to optimize his program and fix his issue on GPU.
Thx. How long would it take you to solve 110 bit range key of puzzle transaction?