not every input creates a valid "bitcoin address". Shouldn't every ECDSA key -> pubkey -> hashamahash -> base58check- > address be valid? Granted, vanitygen might not take those exact steps - or I'm mistaken  use the -t threads option instead of running multiple instances. By default it already runs with 8 threads on that machine, but just for kicks: vanitygen.exe -t 8 -k -q -o out.log 1
[74.97 Kkey/s][total 903612][Found 3665]
vanitygen.exe -t 1 -k -q -o out.log 1
[70.36 Kkey/s][total 876884][Found 3412] dont use it with winblows, its slower. Undoubtedly, but I was looking at relative performance. Maybe you can run some tests under AmigaOS. the vanitygen your using is not the standard one too Ah, you're right - I was using the lifeboat one for the 'compressed key' support. I'll re-run (minus the compressed key tests) on v0.22 proper. mea culpa. use -mtune=native Pretty sure running my own compile optimized for my system would be more efficient overall, but I'm not sure how that would affect the relative values - or the conclusion. just showing your build/windows/src is not a good combination. A laptop with Core i5 2450M gives this: $ ./vanitygen 1K1773R
Difficulty: 15058417127
[481.98 Kkey/s][total 2934016][Prob 0.0%][50% in 6.0h] your CPU is far better than mine, but you only reach 70 Kkey/s. And this is the result of a bad laptop GPU (the one in your laptop is probably also much better): $ ./oclvanitygen 1K1773R
Difficulty: 15058417127
[1.68 Mkey/s][total 71303168][Prob 0.5%][50% in 1.7h]
|
|
|
|
Just to get back to the performance bit of non-ocl vanitygen (standard v0.22), some figures (applicable to the i7-4702MQ 2.2GHz config). Ran each test for 5 minutes. Relative efficiency is based only on the number of 'found' keys in that timespan. | type | command | generated keys | 'found' keys | % matched | relative efficiency | | regex | vanitygen.exe -o file.lst -k -q -F compressed -r .* | 21,262,638 | 82,797 | 0.38940% | 98.72% | | standard | vanitygen.exe -o file.lst -k -q -F compressed 1 | 21,534,544 | 83,874 | 0.38949% | 100.00% | input list
(1A,1B,..,1a,1b,..,11,12,..) | vanitygen.exe -o file.lst -k -q -F compressed -f input.lst | 21,688,744 | 84,499 | 0.38960% | 100.75% | | case insensitive | vanitygen.exe -o file.lst -k -q -F compressed -i 1 | 21,917,217 | 85,410 | 0.38969% | 101.83% | | non-compressed | vanitygen.exe -o file.lst -k -q 1 | 22,324,562 | 87,019 | 0.38979% | 103.75% | | 64-bit version | vanitygen64.exe -o file.lst -k -q -F compressed 1 | 27,455,567 | 106,980 | 0.38965% | 127.55% | | 64-bit, non-compressed | vanitygen64.exe -o file.lst -k -q 1 | 29,042,542 | 113,150 | 0.38960% | 134.90% | | 64-bit, non-compressed, four processes | vanitygen64.exe -o file.lst -k -q 1 | 104,220,011 | 406,105 | 0.38966% | 484.18% |
Using compressed keys adds a few percent overhead, so dropping that might be a reasonable idea (remember though that 'compressed keys' are preferred). The 64bit version is quite a bit faster than the 32bit version as well. Combining the two there's a pretty reasonable speed gain. There's maybe a bit more to gain with the case-insensitive option, but I'd have to run much longer tests to see if that's a real gain or just a wee bit of luck in that run. Running four concurrent processes was much faster still - apparently there's a good bit of overhead of code that doesn't/can't be run multithreaded when using such short prefixes. The other thing that stands out is that even though there's a significant number of keys generated, vanitygen only selects a very, very small portion of them as matches - even though every single one of them should be valid. This is primarily why a program that's specifically written for the task would be much better. In fact, given how few vanitygen actually returns here, I wouldn't be surprised if one of the existing python libraries or even javascript (bitaddress.org's bulk generator is slower, but there might be some performance to gain in their implementation as well) would perform much better. It also reminds me of that weird bounty/'rendezvous points' hunt, which - at least for CPU - might be an easier starting point for modification (if not starting from scratch) A comparison against longer patterns: | type | command | generated keys | 'found' keys | % matched | relative efficiency | | '1' | vanitygen.exe -o file.lst -k -q -F compressed 1 | 21,534,544 | 83,874 | 0.38949% | 100.00% | | '1A' | vanitygen.exe -o file.lst -k -q -F compressed 1A | 16,982,045 | 66,152 | 0.38954% | 78.87% | | '1AA' | vanitygen.exe -o file.lst -k -q -F compressed 1AA | 72,843,612 | 49,592 | 0.06808% | 59.13% | | '1AAA' | vanitygen.exe -o file.lst -k -q -F compressed 1AAA | 256,016,211 | 3,419 | 0.00134% | 4.08% |
One thing that stands out here is that the percentage that 'matched' is the same for patterns '1' and '1A', which I think shouldn't be the case. The other thing is the total number of keys generated. '1A' having generated fewer than '1', while '1AA' and '1AAA' generated more and far more respectively. tl;dr: vanitygen is weird when used for purposes other than what it was designed for not every input creates a valid "bitcoin address". also, use the -t threads option instead of running multiple instances. dont use it with winblows, its slower. the vanitygen your using is not the standard one too use -mtune=native |
|
|
|
Is there a way check balance of vanity addresses automated? You'll have to be more specific in what you're trying to achieve. 'vanity' addresses are just like regular addresses. I know.I mean check balances automated. seems you are trying to bruteforce addresses and check if some BTC are available with a given privkey. simply said -> forget it, wont happen! if you really want to be stupid and ignore the math behind it, you can try "Deep Space Vagabond"... |
|
|
|
1) # dpkg -s libssl-dev | grep Version
Version: 1.0.1e-2+deb7u14
2) My GPUs are not the newest ones, I have 4x MSI Twinfrozr 7950. I'll try to find a patch. Thanks. For me I have a Nvidia 9500 Gt (2.5G) its so slow for this tool , I run it sometime 20 minutes for a 3 key pattern and the speed is 216 key/s . Is my graphic card the only slow here ? or 216 is good ? thats a ancient card. be happy that it even works! |
|
|
|
Hi, I have a question to oclvanitygen users. I successfully compiled the software under Debian linux. I have old mining rig with 4 GPU. Everything seems to work but the load of the cards is quite low: 70-90% and not stable. Nothing that I'm used to when I recall old mining times with stable 99% load in cgminer. How to increase the load to 99% ? It lowers performance a lot with ~80%. Second question. I'm unsure how to read the results. vanitygen provides simple and clear output: Example: ./vanitygen 1tst
Difficulty: 4553521
Pattern: 1tst
Address: 1tstajg1J32HDSVnFDpCoQ8rTCxmNRYvy
Privkey: 5KUruEhXzvmmCJuKhEUtzadNe51DgQzHuGA7EFeBM5mcwRDR2C1
oclvanitygen provides something different. Example: ./oclvanitygen -D 0:0 -D 0:1 -D 0:2 -D 0:3 1tst
Difficulty: 4553521
Match idx: 0
CPU hash: a159f76402d9bab648b806082fbc347818825e98
GPU hash: 09cfb112e8f825a6a2ea5b6f83b96e33ac70c459
Found delta: 5955016 Start delta: 1
How to convert it to normal BTC address and private key? I also noticed when I turn on single GPU workload rises to 97-98%. 1) are you using libssl 1+? 2) newer gpus have a problem that results in incorrect hashes (the message you get from oclvanitygen). search this thread for a post of nasty with a patch for it. |
|
|
|
I think that's a different gpc, addresses are different it is different. |
|
|
|
Pear shape looser. that what all you are.. Im making money at the other sites, wile you guys wait for block.. By the way guys have you notice that the pool is under 1phs... lmao
you really believe that joining a big pool earns you more coins? ah well... all "hope" lost. you will never understand it... |
|
|
|
Greed, impatience & lust for profit can often temporarily blind people to reality, causing them to wander around from pool to pool in search of faster & greater profits, until eventually their vision has cleared & it becomes clear that not only are there no fast profits to be made in mining, but also that p2pool is the highest paying pool there is anyway. See you soon Chupacabras  Patman, I never said this is not the best pool. It is just dry cause of the users hoping habits. I will be back when i see stability. Thanks. if your looking for stability wrt payout, you will always earn less than you could |
|
|
|
Bter down. Theft of BTC  they were using IIS, what do you expect? |
|
|
|
will there be support for CUDA (with compute capability 2.1) ?
it already works with 2.1 AFAIK. |
|
|
|
Yeah. But who owns these 100 addresses? 100 real ANC community members or one ANC core dev & his three friends? Currency is about trust. No one gonna trust ANC if ownership is so uncertain IMHO. Why are you using fiat money then? there you even know less who owns the currency  so its an invalid argument. |
|
|
|
Isn't there a fundamental problem with ANC, that people don't know who the big holders (whales) are?
Or how the distribution is? How many big holders?
Like in other anon coins its know who the big holders are. How coin is distributed over the community.
But in ANC not so much.
because we are not interested in pump'n'dump. move along... |
|
|
|
Wonderful ! Great to hear back from you. Great! Its been awhile since I've checked in here, so I'd like to give everyone just a very brief update on what we have been doing lately. First of all, we have a new Anoncoin web site, and we have reorganized the Anoncoin wiki for clarity. If you have any suggestions, or if you would like to help out with editing content on the wiki, please let me know. Second, for the past several months we have been working with GroundRod, who is now an Anoncoin core developer. He has experience working with other crypto projects, and has been instrumental in upgrading our code to 0.9.4. We are running beta versions of 0.9.4 now, and are working on fixing a few bugs. You are welcome to build the current version on the develop branch at github: if you do so, let us know if you encounter any errors. Unless you are brave, you might want to hold off on this for about a week. I'm hesitant to give a deadline for when we will have a release ready, but I would be surprised if this would take more than a month. Third, if you want to keep up to date, we have a developement schedule on the wiki that we update on a regular basis. As you can see, our next big project will involve updating the difficulty algorithm and changing to 3-chain mulitPOW merge-mining. We consider this essential for securing the blockchain and to avoid the problems we encountered late last year. This will involve a hard fork, and we have already made some progress on implementing this. As for Zerocoin, this is still the primary goal of the project, but we have decided to stop all such development until after our next release. Lastly, if you are unhappy with the pace at which we are progressing, we are looking for all types of volunteers and coders. We still have a few bounties that are open on the wiki. Even if you can't code, there is graphic design work that could be done, or work in contacting businesses to use ANC. Given that we are very close to a release, you can expect to get more regular updates here. Regardless, the best way to keep informed is by IRC on the #anoncoin channel. Most of our discussions are currently on the developer channel (there are pages of uninteresting error messages and tests), but if you ask a question at #anoncoin, someone should get right back to you. Cheers, my anoncoin wallet does not sync why? that in my debug: trying connection 46................. lastseen=7804.4hrs 2015-02-07 17:32:52 connection timeout 2015-02-07 17:32:52 trying connection dnsseed01.anoncoin.net lastseen=0.0hrs 2015-02-07 17:32:57 connection timeout 2015-02-07 17:32:57 trying connection 90........... lastseen=6588.9hrs 2015-02-07 17:33:02 connection timeout 2015-02-07 17:33:02 trying connection anoncoin.dnsseed.coinpool.in lastseen=0.0hrs 2015-02-07 17:33:07 connection timeout 2015-02-07 17:33:08 trying connection 16.............. lastseen=480.1hrs 2015-02-07 17:33:13 connection timeout 2015-02-07 17:33:13 trying connection dnsseed01.anoncoin.net lastseen=0.0hrs 2015-02-07 17:33:18 connection timeout 2015-02-07 17:33:18 trying connection 91................ lastseen=104.1hrs 2015-02-07 17:33:23 connection timeout 2015-02-07 17:33:23 trying connection anoncoin.dnsseed.coinpool.in lastseen=0.0hrs 2015-02-07 17:33:28 connection timeout 2015-02-07 17:33:29 trying connection 86.................lastseen=4382.0hrs 2015-02-07 17:33:34 connection timeout 2015-02-07 17:33:34 trying connection dnsseed01.anoncoin.net lastseen=0.0hrs 2015-02-07 17:33:39 connection timeout 2015-02-07 17:33:39 trying connection 18................... lastseen=3890.0hrs 2015-02-07 17:33:44 connection timeout 2015-02-07 17:33:44 trying connection anoncoin.dnsseed.coinpool.in lastseen=0.0hrs 2015-02-07 17:33:49 connection timeout 2015-02-07 17:33:50 trying connection 12................... lastseen=166.8hrs 2015-02-07 17:33:55 connection timeout 2015-02-07 17:33:55 trying connection dnsseed01.anoncoin.net lastseen=0.0hrs 2015-02-07 17:34:00 connection timeout 2015-02-07 17:34:00 trying connection 2............... lastseen=652.8hrs 2015-02-07 17:34:02 connection timeout 2015-02-07 17:34:02 IRC connect failed 2015-02-07 17:34:02 IRC waiting 138 seconds to reconnect 2015-02-07 17:34:05 connection timeout 2015-02-07 17:34:05 trying connection anoncoin.dnsseed.coinpool.in lastseen=0.0hrs 2015-02-07 17:34:10 connection timeout 2015-02-07 17:34:11 trying connection 17.................... lastseen=5864.9hrs 2015-02-07 17:34:16 connection timeout 2015-02-07 17:34:16 trying connection dnsseed01.anoncoin.net lastseen=0.0hrs why did you addnode some VERY WEIRD nonexisting fake DNS seeds? |
|
|
|
latest x13 optimisations are not compatible with 6xxx and 5xxx radeons
Best way is to run with -d switch - pointing to your 7970 and another instance using x13modold/marucoin-modold , again with -d but pointing to 6950 card
Best speed achieved by 6970 is ~ 1.4MH/s for x13
I'm mining with 280x using sgminer 4.2.2-298-g3bb4 with wolf and got 8,2Mh/s for single card and 34 Mh/s with 4 280x here my bat.file for single card. sgminer.exe --kernel darkcoin-mod --api-listen -o stratum+tcp://cann.suprnova.cc:4442 -u xxxx -p xxxxx -w 64 -g 2 --thread-concurrency 8192 --intensity 21 --lookup-gap 2 --no-submit-stale --gpu-powertune 20 --gpu-fan 55 --temp-cutoff 95 --gpu-engine 1150 --gpu-memclock 1450 From sgminer screen sgminer 4.2.2-298-g3bb4 - Started: [2015-02-06 01:21:49] - [0 days 00:24:53] -------------------------------------------------------------------------------- (5s): 8.017M (avg):6.683Mh/s | A:2 R:0 HW:0 WU:0.094/m ST: 2 SS: 5 NB: 25 LW: 1557 GF: 0 RF: 0 Connected to cann.suprnova.cc (stratum) diff 0.022 as user xxxxxxxx Block: 4bd89bcc... Diff:37 Started: [01:46:42] . can you link that kernel please? |
|
|
|
Has anyone experience with SSL secured connections with sgminer ?
AFAIK with ccminer you can put certificates using the -cert flag for securing the stratum connection, does sgminer allow that too ?
if not, just use stunnel Hmm, yes, but I want to connect to a server via SSL, i can only access my side, not the other.. The other side wants a SSL connection though (certificate).. then create an instance that listens on localhost:X and forwards everything to server:Y just another tool you would have to start |
|
|
|
Has anyone experience with SSL secured connections with sgminer ?
AFAIK with ccminer you can put certificates using the -cert flag for securing the stratum connection, does sgminer allow that too ?
if not, just use stunnel |
|
|
|
Is there any way to find out if our miners submitted any shares in p2pool?
I can see only minefast.CoinCadence.com node has detailed statistics on shares submitted etc. All other nodes dont have any stats except graphs of hashrate.
Is it something node owner has to install or integrate inorder to display shares submitted by miners?
the goal of p2pool is to run p2pol locally. your doing it wrong! |
|
|
|
I am using wolf’s bin for x11 but something is odds for me, on other algorithms when a work is done with one GPU the result is shown in the bottom section as accepted /////// GPU# and then at the top section A: will increase respectively, but in this case A: increase very slowly in compare with the accepted shares. is something wrong with my setting?
some count the accepted shares (A:) as the count of accepted shares, other the cumulative difficulty. |
|
|
|
Fresh nodes February 2015
---snip---
please, dont do that... connectivity has to be distributed. if you need peers and dont have a recent ANC build, add the seednodes via addnode=, it will resolve to a random WORKING peer. currently there are 2 dns seeds. |
|
|
|
can anyone share how big the blockchain is currently ??
I would also like to know. Or a description of how to find this information? Thanks $ du -sh .datacoin/blocks/
1.1G .datacoin/blocks/
|
|
|
|
|
Show Posts
