Show Posts
|
Pages: « 1 2 [3] 4 5 6 »
|
Hey, fixed a list. 38MK is the speed of 1070. So, 1080 should get 60-70MK, nobody has reported yet.
|
|
|
This VG version can search only decrementally - from starting number, in infinite loop it does minus 1 So for puzzle56 the range is 2^55 - 2^56 1. get your crystal ball, see there the right percentage, let's say it is 42% 2. count a bit. 42% of range is around 51160891766928834 decimal or B5C28F5C28F5C2 hex echo 'obase=16; 2^55/100*42+2^55' | bc -l B5C28F5C28F5C2 p.s. I already searched around 42 and 17 percent for a couple of months at speed 40MK. It's not there...
|
|
|
rico666 is doing an excellent job on Burst thats not reflected in its market value. If you are a fan of rico, support us in the Burst community.
This topic is not about splendid rico and his beautiful shitcoins I have one MSI GTX 1060 3G Gaming X. Try this oclvanitygen it run at speed 27M key. Is it normal or slow.
1050 gets 15MK 1060 gets 25MK 1070 gets 38MK address list can be up to 150-200 thousand keys without big speed penalty I personally run with this 97k list. It contains 4BTC++ addresses without any spends or 15BTC++ with spends. Obviously "15BTC++ with spends" sometime become empty and should be deleted. http://80.211.89.91/92k
|
|
|
If it could use a bloom filter like LBC does, it would be even faster and look for more There is of course a bloom filter in VG, but it's implementation is tuned for around 10k addresses. Mostly it's my fault - I thought that there are 10-20 thousand of fat addresses. Was wrong. So, this part of VG can also be upgraded. Actually, this guy spent only couple of weeks on it. He looks like a pro, but a freelancer, not charity fund There were many things to do, but I wasn't ready to spend more, than $500
|
|
|
In verbose mode it always complains on CPU, even when working OK and finding everything. I didn't ask him what this complain means. If something is not working it is possible that he will fix it for free if you report a bug on github. Because he was doing this work partially for portfolio
|
|
|
oclvanitygen -D 0:0 -f addresses.txt -o found.txt -k lastkey.txt 3000 What's the command you ran to have those return positive?
The command is OK. Are you really talking about NDV fork of oclvanitygen ? Do addresses.txt file contain 160 bounty addresses? Case of chars matters. There is a verbose switch. Post the log.
|
|
|
oclvanitygen -D 0:0 -f addresses.txt -o found.txt -k lastkey.txt 3000 Still doesn't find anything. Can you share a command line that returns a find?
I haven't tried intel gpu, also I didn't even try windows. The command looks fine, although -D 0:0 is not necessary. On nvidia card I've tested first 30 and 52,53,54,55 puzzles - works like a charm.
|
|
|
Do you still need funding to improve the speed?
You can request updates from NDV directly, if you wish. He promised 30-50% boost after rewriting ECC code for around $300-400. You can make the change public or personal. If you are going to use big farm it makes sense. For 1-2 cards (like I have) it's just easier to buy more hardware.
|
|
|
It's an integrated video card. It won't be the final machine I'll be using...just testing. @holy_ship do you have an opinion?
I guess these zillions of leading zeros transform your HEX to some crapy WIF. Also HEX should be uppercase, at least in Linux.
|
|
|
phrase ip addresses (sha256) but there is also not a small figure 4294967296.
4294967296 keys to check is job for 80 seconds. OK, if they are not sequential, let it be - 1 hour. Andzhig, you should write your native language, because when you write in English I always get an impression that you have undertreated meningitis.
|
|
|
The LBC project[/url] is currently running at 346.02 Mkeys/s
Actually LBC is still checking the 2^55 range. So even pasting numbers in http://brain.evilbs.com/ by hand is faster than LBC
|
|
|
Python is not hipsterish enough! True mama's cryptokiddies choose PHP parser of directory.io And adding right magic constant to skip "unnecessary" pages is vital!
So, first you should look at you mom's Crystal Ball to find the magic number!
|
|
|
Not checked if you are right with p1-55 but half of 2^55 is still a job for gf1080 GPU for several years Try to narrow range a bit more, please
|
|
|
The key is from no 36054468590243300 to 71207575465730500
The key is between 36028797018963968 and 72057594037927936 2^55 - 2^56 What is "358 formula"? keys 1-55 are not rounded to decimal hundreds at all.
|
|
|
Can someone discuss with me? pm
Does it really matter, PM with unknown persons or here, in public? Arulbero is good (best here?) at math, but probably is a bit busy.
|
|
|
Also, there are no known collisions for both SHA-256 and RIPEMD-160 hash functions. Not a single one.
Nobody bothered. No, you will not find 50.000 BTC wallet by searching for the solution of this puzzle, I guarantee you that.
You are not authorized to guarantee that unless you're our dear Allah.
|
|
|
That's what anonymous author of the puzzle is telling us, and he backed his claim with all these BTC. If he is wrong, someone would pick the money from this puzzle. Sooo wrong There is no direct relation between 32BTC puzzle and "real wallets". While searching for modest .5BTC puzzle you can discover 50.000BTC wallet due to collision. That's what attracts so many mommies's-crypto-kiddies to LBC One problem is the probability of such discovery....
|
|
|
The selection of key is totally random within the range with all values equally likely.
1. There is no true randomness in computers. 2. Can you count? 30 keys from 55 were in second half. But OK, I've counted myself just now and was expecting a bit more than 30/55 chances
|
|
|
|