Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 123. (Read 1153691 times)
I'm quite interested - is this basicaly bruteforcing? Also, what happens to all the adresses that are generated? Are they just going to a waste forever or do they "recycled", also, how many addresses can be brought into total existance? I generate a LOT of keys per second and I'm curious, am I wasting a lot of addresses?
Why are some addresses harder to find than others when you change only 1 characters case. For example at the vanitypool there's work for a 1bitpoin, and my computer says it will find one for it in ~10 days, but when I search for 1Bitpoin it can find it in 5 minutes...?
The answer is exactly two pages back (again). That's called dedication to not looking for the answer before asking...
Why are some addresses harder to find than others when you change only 1 characters case. For example at the vanitypool there's work for a 1bitpoin, and my computer says it will find one for it in ~10 days, but when I search for 1Bitpoin it can find it in 5 minutes...?
The answer is exactly two pages back (again). That's called dedication to not looking for the answer before asking...
Sorry for not wanting to search through 60+ pages of text for a answer someone could click three times to quote the answer to my problem. My bad, how selfish of me.
Question: Is there a way of making a deterministic vanity wallet?
Answer: I believe there is a way of supplying a randomly generated root / chain / whatever key, then a specific deterministic method of address generation, and outputting a sequence of vanity addresses that is the same each time. However, the sequence will take as much time as needed for every single vanity key.
Example: 100 vanity bitcoin addresses all beginning with 1dice, 1Dabs, 1whatever will take on average 100 times it takes to generate a single one.
More food for thought: This might be extended to make vanity public addresses (watch only) without knowing the private keys. Some wallets can already do this on non-vanity addresses using a master root / chain key (that knows the private keys) and a public root / chain key that knows the equivalent public bitcoin addresses only.
Request: Use compressed keys by default for all future projects.
Answer: I believe there is a way of supplying a randomly generated root / chain / whatever key, then a specific deterministic method of address generation, and outputting a sequence of vanity addresses that is the same each time. However, the sequence will take as much time as needed for every single vanity key.
Example: 100 vanity bitcoin addresses all beginning with 1dice, 1Dabs, 1whatever will take on average 100 times it takes to generate a single one.
More food for thought: This might be extended to make vanity public addresses (watch only) without knowing the private keys. Some wallets can already do this on non-vanity addresses using a master root / chain key (that knows the private keys) and a public root / chain key that knows the equivalent public bitcoin addresses only.
Request: Use compressed keys by default for all future projects.
Why are some addresses harder to find than others when you change only 1 characters case. For example at the vanitypool there's work for a 1bitpoin, and my computer says it will find one for it in ~10 days, but when I search for 1Bitpoin it can find it in 5 minutes...?
The answer is exactly two pages back (again). That's called dedication to not looking for the answer before asking...
Why are some addresses harder to find than others when you change only 1 characters case. For example at the vanitypool there's work for a 1bitpoin, and my computer says it will find one for it in ~10 days, but when I search for 1Bitpoin it can find it in 5 minutes...?
That seems like a large variation for changing 1 digit. Normally the max is around 50X change. Maybe 10 days down to 5 hours?
It's due to the weirdness of the encoding system.
This is probably more detail than you want
.Your prefix gets converted into a 25 byte integer range. The first byte is the network prefix (zero for BTC). The next 20 are the hash of your key and the final 4 are the checksum.
The first byte has to be zero (to give the leading one in all bitcoin addresses). This happens automatically.
The next byte can't be zero, or your address would be 11...... Note: for prefixes of the form 11something, the calculation has to be adjusted.
So, your address must be a number with the first byte zero and 2nd byte at least 1. This means it has to be between these 2 numbers.
(Numbers are hex and _ is just a spacer every 4 bytes/8 characters)
00_FFFFFFFF_FFFFFFFF_FFFFFFFF_FFFFFFFF_FFFFFFFF_FFFFFFFF
00_01000000_00000000_00000000_00000000_00000000_00000000
Other than that, your number depends on the actual letters used. If you add an extra letter the allowed range drops by 58.
Another feature is that if a number gives the right prefix, if you multiply it by 58, it will give the same prefix (though the address will be longer).
"Bitpoin" has the following allowed ranges
Max: 00_759d92ad_aa9cbac1_7b8e094d_c5ae2dbe_ed97d9e9_5fffffff
Min: 00_759d92ad_a95fe99b_8977a9c8_b4d2895e_e5968fe0_bc000000
Max: 00_0207216c_ecdf6452_c8c03df4_197a2ced_390fdc08_6fffffff
Min: 00_0207216c_ecd9edf5_70b70757_5290df0e_e0a5e7ff_76000000
The bottom range multiplied by 58 gives the top range. Both have the first byte as zero and the 2nd byte as non-zero, so they are both valid.
If you divide by bottom one by 58, the first two bytes would be zero, so it is illegal. Likewise, if you multiply the top one by 58, it would have the first byte as non-zero.
"bitpoin" has the following allowed range
Max: 00_06911d18_3fbe86a5_63524509_2534ef9a_74fdec84_6fffffff
Max: 00_06911d18_3fb91048_0b490e6c_5e4ba1bc_1c93f87b_76000000
If you mutiply it by 58, it goes above the top limit and if you divide by 58, it goes below the lower limit.
According to the encoding system, "b" is worth 34 and "B" is worth 10. If you multiply the lower limit of Bitpoin by 3.4, you get bitpoin's range (since "b" is 3.4 times greater than "B").
This is the first reason that bitpoin is harder, it has only one target range.
Another reason is if the middle of a range is a larger number, the size of the range is generally larger. The Bitpoin top range is bigger than the bitpoin range, so again, Bitpoin is faster.
Why are some addresses harder to find than others when you change only 1 characters case. For example at the vanitypool there's work for a 1bitpoin, and my computer says it will find one for it in ~10 days, but when I search for 1Bitpoin it can find it in 5 minutes...?
I mined addresses in the vanity pool without using the miner application (simply using a wordlist via gen). I'm assuming I'm not eligible to redeem them because I didn't use the public keys provided; Either way, if anyone wants 1PussyCum or 1Stunna1 (both were in the pool), I have keys for them. Of course, they're not generated using split-pairs, but nonetheless. :S
In case anyone can not be bothered to get the old versions of the driver installed you can always use us at:
https://bitcoinvanity.appspot.com/
We just reduced prices another 20%.
And short addresses still free.
https://bitcoinvanity.appspot.com/
We just reduced prices another 20%.
And short addresses still free.
Question: Why does the vanityminer only search for 1 specific address from the bounty pool? Wouldn't it be better if it were to compare the calculated address with all the ones requested in the pool?
They must be hashed independently per pool customer due to the key of the customer being part of the generated address, so only the customer can spend from the vanity address.From a glance-through read, it would appear that one would only be able to generate addresses for a single client at a time. Am a wrong, that the hashing and checking will find an address that would work for just one client. Currently, you hash once and see if the public address has any matches from an arbitrary list.
This is a challenge...
Has anyone looked into implementing this yet?
Got my hands on a 5870 real cheap ($120 shipped). ^_^
Running at over 28 MKey/s unoptimized. Any advice on getting more keys out of my card? Using the built in Catalyst OC I get to 30 MKey/s maxing out the clocks.
Question: Why does the vanityminer only search for 1 specific address from the bounty pool? Wouldn't it be better if it were to compare the calculated address with all the ones requested in the pool?
Running at over 28 MKey/s unoptimized. Any advice on getting more keys out of my card? Using the built in Catalyst OC I get to 30 MKey/s maxing out the clocks.
Question: Why does the vanityminer only search for 1 specific address from the bounty pool? Wouldn't it be better if it were to compare the calculated address with all the ones requested in the pool?
Cool tool. I did some testing with it and found a lot of prefixes that i wanted to use. It was found a lot faster then the JAVA based solution did which i used before. Thanks! Is there a donation adres?
I tried using the official -22 with the older openssl and that actually did work under windows 8. I was using the -catalyst version previously (don't remember where/how/why I got that, has a slightly newer openssl). Yay.
pretty noob at linux, so I am not sure how to get opencl working. I got ubuntu 12.04, installed 12.1 driver here: http://support.amd.com/us/gpudownload/windows/previous/12/Pages/radeon_linux.aspx?os=Linux%20x86&rev=12.10 and it installed fine. When I try to run make oclvanitygen I get:
Edit: got it working from changing makefile CFLAGS to CFLAGS=-ggdb -O3 -Wall -I/opt/AMDAPP/include/
Thanks RaTTuS!
So now it compiles, but I don't think I installed OpenCL correct. My GPU does not show up on the list of Available OpenCL platforms and oclvanitygen only lets me select my CPU... bah.
Wiped my ubuntu since I pretty much screwed it up lol. Gave it a try on Xubuntu and got my GPU to show up! But...
lol... getting closer... I think? Weird thing is when I run cgminer it mines just fine. I just can't get this damn vanitygen working.
Code:
fatal error: CL/cl.h: No such file or directory
Edit: got it working from changing makefile CFLAGS to CFLAGS=-ggdb -O3 -Wall -I/opt/AMDAPP/include/
Thanks RaTTuS!
edit Makefile and change the line
CFLAGS to be like
CFLAGS=-ggdb -O3 -Wall -I/opt/ati-stream-sdk-v2.1-lnx64/include/
^ or where ever your included path is for opencl
see 2.3 or if using nvidia then somewhere else
to find where try
locate /cl.h
CFLAGS to be like
CFLAGS=-ggdb -O3 -Wall -I/opt/ati-stream-sdk-v2.1-lnx64/include/
^ or where ever your included path is for opencl
see 2.3 or if using nvidia then somewhere else
to find where try
locate /cl.h
So now it compiles, but I don't think I installed OpenCL correct. My GPU does not show up on the list of Available OpenCL platforms and oclvanitygen only lets me select my CPU... bah.
Wiped my ubuntu since I pretty much screwed it up lol. Gave it a try on Xubuntu and got my GPU to show up! But...
lol... getting closer... I think? Weird thing is when I run cgminer it mines just fine. I just can't get this damn vanitygen working.
yes, Tahiti (7950) was around 34Mkeys/s, Pitcairn should work as well...
https://bitcointalksearch.org/topic/m.2819593
https://bitcointalksearch.org/topic/m.2819593
so funny, only win tards having problems...
Do the 7xxx GPUs work with VG in Linux?
so funny, only win tards having problems...
I need some help compiling in win32 w/ VS 2010
Code:
E:\Bitcoin_Stuff\vanitygen-master>nmake /fMakefile.Win32
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
vanitygen.c
e:\bitcoin_stuff\vanitygen-master\winglue.h(47) : error C2062: type 'char' unexp
ected
e:\bitcoin_stuff\vanitygen-master\winglue.h(47) : error C2143: syntax error : mi
ssing ';' before '{'
e:\bitcoin_stuff\vanitygen-master\winglue.h(47) : error C2447: '{' : missing fun
ction header (old-style formal list?)
NMAKE : fatal error U1077: '"E:\Program Files (x86)\Microsoft Visual Studio 10.0
\VC\BIN\cl.EXE"' : return code '0x2'
Stop.
Code:
CC = cl
OPENSSL_DIR = C:\OpenSSL-Win32
PTHREADS_DIR = C:\pthreads
PCRE_DIR = C:\pcre-7.9-src
CURL_DIR = C:\curl-7.26.0-x86\builds\libcurl-release-static-ssl-static-ipv6-sspi
OPENCL_DIR = "C:\Program Files (x86)\AMD APP"
OPENCL_INCLUDE = /I$(OPENCL_DIR)\include
OPENCL_LIBS = $(OPENCL_DIR)\lib\x86\OpenCL.lib
CURL_INCLUDE = /I$(CURL_DIR)\include /DCURL_STATICLIB
CURL_LIBS = $(CURL_DIR)\lib\libcurl_a.lib
CFLAGS_BASE = /D_WIN32 /DPTW32_STATIC_LIB /DPCRE_STATIC /I$(OPENSSL_DIR)\include /I$(PTHREADS_DIR) /I$(PCRE_DIR) /Ox /Zi
CFLAGS = $(CFLAGS_BASE) /GL
LIBS = $(OPENSSL_DIR)\lib\libeay32.lib $(PTHREADS_DIR)\pthreadVC2.lib $(PCRE_DIR)\pcre.lib ws2_32.lib user32.lib advapi32.lib gdi32.lib /LTCG /DEBUG
OBJS = vanitygen.obj oclvanitygen.obj oclengine.obj oclvanityminer.obj keyconv.obj pattern.obj util.obj winglue.obj
all: vanitygen.exe keyconv.exe
vanitygen.exe: vanitygen.obj pattern.obj util.obj winglue.obj
link /nologo /out:$@ $** $(LIBS)
oclvanitygen.exe: oclvanitygen.obj oclengine.obj pattern.obj util.obj winglue.obj
link /nologo /out:$@ $** $(LIBS) $(OPENCL_LIBS)
oclvanityminer.exe: oclvanityminer.obj oclengine.obj pattern.obj util.obj winglue.obj
link /nologo /out:$@ $** $(LIBS) $(OPENCL_LIBS) $(CURL_LIBS)
keyconv.exe: keyconv.obj util.obj winglue.obj
link /nologo /out:$@ $** $(LIBS)
.c.obj:
@$(CC) /nologo $(CFLAGS) /c /Tp$< /Fo$@
oclengine.obj: oclengine.c
@$(CC) /nologo $(CFLAGS_BASE) $(OPENCL_INCLUDE) /c /Tpoclengine.c /Fo$@
oclvanitygen.obj: oclvanitygen.c
@$(CC) /nologo $(CFLAGS_BASE) /c /Tpoclvanitygen.c /Fo$@
oclvanityminer.obj: oclvanityminer.c
@$(CC) /nologo $(CFLAGS_BASE) $(CURL_INCLUDE) /c /Tpoclvanityminer.c /Fo
clean:
del vanitygen.exe oclvanitygen.exe oclvanityminer.exe keyconv.exe $(OBJS)
Any idea how to stop the vanity miner from stopping on this error?
It runs for a while, but inevitably, it halts.
Win7 64-bit. driver @ 320.49
C:\Users\xxxx\Desktop\vanitygen>oclvanityminer64.exe -u https://vanitypool.appspot.
com/ -a 1NfaEu8CC84dCpJnQEwjoLFvuE57UbZpAU
Searching for pattern: "17Strykes" Reward: 0.088000 Value: 0.000006 BTC/MkeyHr
Difficulty: 50656515217834
[22.58 Mkey/s][total 192538214400][Prob 0.4%][50% in 17.9d] clWaitForEv
ents(NDRange,1): CL_OUT_OF_RESOURCES
clEnqueueUnmapMemObject(0): CL_INVALID_COMMAND_QUEUE
vg_ocl_context_callback error: CL_INVALID_COMMAND_QUEUE error executing CL_COMMAND_UNMAP_M
EM_OBJECT on GeForce GTX 570 (Device 0).
Device: GeForce GTX 570
Vendor: NVIDIA Corporation (10de)
Driver: 320.49
Profile: FULL_PROFILE
Version: OpenCL 1.1 CUDA
Max compute units: 15
Max workgroup size: 1024
Global memory: 1342177280
Max allocation: 335544320
Device: GeForce GTX 570
Vendor: NVIDIA Corporation (10de)
Driver: 320.49
Profile: FULL_PROFILE
Version: OpenCL 1.1 CUDA
Max compute units: 15
Max workgroup size: 1024
Global memory: 1342177280
Max allocation: 335544320
clEnqueueMapBuffer(4): CL_INVALID_COMMAND_QUEUE
ERROR: Could not map row buffer for slot 0
ERROR: allocation failure?
It runs for a while, but inevitably, it halts.
Win7 64-bit. driver @ 320.49
C:\Users\xxxx\Desktop\vanitygen>oclvanityminer64.exe -u https://vanitypool.appspot.
com/ -a 1NfaEu8CC84dCpJnQEwjoLFvuE57UbZpAU
Searching for pattern: "17Strykes" Reward: 0.088000 Value: 0.000006 BTC/MkeyHr
Difficulty: 50656515217834
[22.58 Mkey/s][total 192538214400][Prob 0.4%][50% in 17.9d] clWaitForEv
ents(NDRange,1): CL_OUT_OF_RESOURCES
clEnqueueUnmapMemObject(0): CL_INVALID_COMMAND_QUEUE
vg_ocl_context_callback error: CL_INVALID_COMMAND_QUEUE error executing CL_COMMAND_UNMAP_M
EM_OBJECT on GeForce GTX 570 (Device 0).
Device: GeForce GTX 570
Vendor: NVIDIA Corporation (10de)
Driver: 320.49
Profile: FULL_PROFILE
Version: OpenCL 1.1 CUDA
Max compute units: 15
Max workgroup size: 1024
Global memory: 1342177280
Max allocation: 335544320
Device: GeForce GTX 570
Vendor: NVIDIA Corporation (10de)
Driver: 320.49
Profile: FULL_PROFILE
Version: OpenCL 1.1 CUDA
Max compute units: 15
Max workgroup size: 1024
Global memory: 1342177280
Max allocation: 335544320
clEnqueueMapBuffer(4): CL_INVALID_COMMAND_QUEUE
ERROR: Could not map row buffer for slot 0
ERROR: allocation failure?
Jump to: