It does.

I think I've figured out what's happening: oclvanitygen will only find keys wirh vanity addresses for non-Bitcoin address types.  These commands work:


This doesn't:


The degenerate case where you just want an address appears to only work for Bitcoin.

Did you try it?  http://explorer.litecoin.net/ appears Abe based, and doesn't LTC use scrypt?  I'd suggest asking them if they had to change anything.  They should give you the explorer source.  (If not, I'd like to know...)

Abe does not (yet) contain any special code for scrypt.  That would be nice to add.

Yes this is one Reason, not totally unfamiliar, i probably get it to run but i'm very slow and i have to google a lot, for the Parameters,
after i found this Thread, i'm sure here are probably more sophisticated Cudaminer Users/Dev in here.
I haven't used Cudaminer once.
They probably won't let you mine long enough, but with enough GPU's maybe 1-2 Litecoins are possible.

Just out of curiosity

...and for me, it just runs forever. Just tried it again with a 7750, then with a 6870 and even a Core 2 Duo E8400. What card and ATI driver version are you using? Leaving out the device-selection option causes it to exit with a list of available devices.

Going based on hits/views is one of the easiest systems to manipulate (exploit). I am 100% against this.

I agree 100%. Unthinkingbit and other administrators: is there a way we can make some decision on this?

Got a Invitatiopn for a Test Drive at Nvida GPU HPC http://www.nvidia.com/object/tesla-supercomputing-solutions.html

i guess best would be Cudaminer to try on Nivida Hardware,
but i don't think that im the appropriate Person,
so would one of you like to try it out ?


Got the second Mail yesterday, so not much Time left.



Thank you for registering for NVIDIA GPU Test Drive.

Could you kindly let us know what application/code you would like to run at the GPU Test Drive.

This will help us pick the right Test Drive Partner.

I do believe that it is necessary... I get an error if I don't

~/git/bitcoin-vanitygen$ ./oclvanitygen -X 48 LNoobs
Difficulty: 264104224
Pattern: LNoobs                                                                
Address: LNoobsbG3rDntp8rc86F368SoPVHkW9z8P
Privkey: 6uB3J78ffBB7Uz22y8VH42awwRKiUiX7eqqqS1KkcauWa1qyLjg

I think your device flag is wrong. Also, I'm assuming you don't have more than one GPU because of your flag structure. Try:


The capital D might be why it doesn't identify your GPU.

You're going to need a bitcoin.conf file in order for Armory to be able to talk to Bitcoin-Qt.

If you want to use Armory and Bitcoin-Qt completely anonymously via Tor here is how I'd set it up:

1. Open Bitcoin-Qt, set it use your Tor proxy, then shutdown Bitcoin-Qt.

2. Configure Tor to create a hidden service that forwards to 127.0.0.1:8333 (Assuming you're running Tor on the same machine). Note the hidden service hostname.

3. Find the directory that contains peers.dat and wallet.dat. Delete peers.dat

4. In this same directory create a bitcoin.conf file with the following contents:


5. Start Bitcoin-Qt with the "-onlynet=tor" command line option.

In this way you will only connect to hidden services and Armory will be able to communicate with Bitcoin-Qt.

I did not see that yet. Maybe running out of ram screwed up my valgrind results?  Though I don't even see anything in CheckBlock, in the version I have, that allocates memory off hand.    What assumptions are being made?    CheckBlock also is called regardless of mm being on or not,  it would not explain the rapid growth in memory usage once the mm blocks are hit would it?  Hopefully I can get a new computer soon and actually run i0coin again to get better data.

BTW, could you add block size to the information shown on your blockexporer?

leveldb will not,   some other changes done at the same time will help.   However I am still unconvinced i0coin having memleaks is the root cause of the issue.  I think it is an issue that is present in at least some of the mm patches.   I noticed that at the point that the mm kicks in, the memory usage starts to grow at the rate of about 10x per block as it did before the mm kicks in.

Additionally, I think the same behavior is in nmc test. I also see evidence of it in coiledcoin, and groupcoin.   I think the reason we don't see it for devcoin and nmc, is that the major pools for these form their blocks outside of the *coind codes logic.

http://dot-bit.org/forum/viewtopic.php?f=7&t=972

I just don't have the tools and resources locally set up to dig into this further, and was unable to find a good enough online block explorer to do so.  Since I am pretty much out of disk space on my laptop, it is going to be awhile till I can get back into digging into this, so hopefully someone else can beat me to it.



Are you sure of this?


Why are you so sure it is a memleak?   I think it is simply due to the issue above with mm, and the  number of blocks i0 has compared to the other chains.  dns lookup crap is due to it using ntp internally to enforce shorter windows of timestamps.   I know I used to advocate for a nontp option at least so on systems already keeping good time (running ntp already for example), all this crap can be turned off, and stop the load on the ntp public servers, and network use that is unneeded etc.

+1

After using leveldb in bitcoin, the thrashing my disk took bootstrapping all the merged mining chains was embarrassing.

I found printf, I want to extract only the bitcoin address from it because the output contains the private key and another line as well. Anyone knows how to do that?

I'm trying to do merged mining, but I can't even get I0coin to bootstrap.  It starts with 1 connection, then drops to 0.  Is I0coin dead?

I'm not very familiar with C but I was going through the source code. I wanted to know where the address is generated.
Like, suppose I run vanitygen and it finds an address I want, I wanna know the line that prints the address and its private key on the console.
Thank you

Yes and no ;-)

I changed it a while ago to use ACS_CKBOARD instead of an inverted space but did not notice the ugliness until I downgraded from Xubuntu 12.10 to 12.04 two days ago (there seem to be different fonts in Ubuntu 12.10 that make ACS_CKBOARD look much nicer).

I'm probably going to change it back again (or make it optional because some black&white terminals seem to have problems with inverted characters and inverted spaces can become invisible).