If we run their program or vanitygen on it, how many keys/s can it archived?
I would recommend to try it by yourself
Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 8. (Read 1153691 times)
I would recommend to try it by yourself
Now, why would one need a million keys .... You might want to take a look at VanitySearch if you need an updated vanity generator.
Hi, everybody.
Tell me can I generate keys in hex format using Vanitygen?
More precisely, I need to generate millions of keys in hex format with the output of each key in a new line without any additional characters.
Tell me can I generate keys in hex format using Vanitygen?
More precisely, I need to generate millions of keys in hex format with the output of each key in a new line without any additional characters.
You don't use vanitygen for such a simple task! All you need is a simple random number generator.
https://onlinehextools.com/generate-random-hex-numbers
This does exactly what you're looking for but you would have to copy and paste them to a file.
The beauty is the website uses your computer for the calculations and there's a copy to clipboard button. Simply input the number you want ie millions and then the length in bytes 64...
Careful though, 100k took about 10 seconds on my machine - (pretty kick-ass CPU in it though it pales in comparison to some of the newer AMD options available) - and one million took around 3 minutes. Copy pasting was quick though. Here's a sample output of 10 @ 64 bytes
Code:
f8dbb4a211807d7c4ee0f2b3b6bc6d09bd5ca2905aa7336492e52dcd0701bf47
723a08ff247985f1146aa44c7201644c332c05d3e1bb4b03333c0bce3b2087f7
4e2f2c5c9e1ac2f625722543d53d86606c1caf7f4910c2a6feea08591f5b16f4
82f150ca4fbfce98781dce40d76cf0ff62fbe2eb80fba193a5e2f83be74ccaa9
bcd2656310ae4550892912e4a3b7b71be24ef576bf801a3adf0afedf497574e1
adc643900ecfeac846e81ec272e97bcf50637d791e8c36442738c9ac216418ce
5421806c8591586f3cc052482b2c1a5a5311f0f98bdcec8b4cfc50a60face784
02a96ca8378edb26df582361f7f87b18282db3640a555f5b29cad2703ebcde86
4ac41466859c92e94389168378c3a74d847080fe2a36b4f0fa7aca41554f71a4
c27685199166d8819095b8e649e8c2bb15465e17b645d12f84c5cfdcb0528ab7
723a08ff247985f1146aa44c7201644c332c05d3e1bb4b03333c0bce3b2087f7
4e2f2c5c9e1ac2f625722543d53d86606c1caf7f4910c2a6feea08591f5b16f4
82f150ca4fbfce98781dce40d76cf0ff62fbe2eb80fba193a5e2f83be74ccaa9
bcd2656310ae4550892912e4a3b7b71be24ef576bf801a3adf0afedf497574e1
adc643900ecfeac846e81ec272e97bcf50637d791e8c36442738c9ac216418ce
5421806c8591586f3cc052482b2c1a5a5311f0f98bdcec8b4cfc50a60face784
02a96ca8378edb26df582361f7f87b18282db3640a555f5b29cad2703ebcde86
4ac41466859c92e94389168378c3a74d847080fe2a36b4f0fa7aca41554f71a4
c27685199166d8819095b8e649e8c2bb15465e17b645d12f84c5cfdcb0528ab7
More precisely, I need to generate millions of keys in hex format with the output of each key in a new line without any additional characters.
You might need Bitcrack instead of Vanitygen to do that. [Bitcointalk Thread | Github Repo]I haven't tried the software (so read the thread's previous replies for more info) but the -o or --out argument's description looks similar to what you need:
Quote from: Github - BitCrack
-o, --out FILE
Append private keys to FILE, one per line
Append private keys to FILE, one per line
Hi, everybody.
Tell me can I generate keys in hex format using Vanitygen?
More precisely, I need to generate millions of keys in hex format with the output of each key in a new line without any additional characters.
Tell me can I generate keys in hex format using Vanitygen?
More precisely, I need to generate millions of keys in hex format with the output of each key in a new line without any additional characters.
This post is reserved for the status of the previous one.
Status:
At the moment, the correction in the previous post is not final and not fully verified, you use it at your own risk.
At the moment, the correction in the previous post is final and fully tested.
This is an old unresolved fundamental bug in kernel openCL, and I will help all of us fix it.
Fact: all known cases are united by - Nvidia+other(without AMD), yes, its a "green bug"
progress tests
[v] rigGPU (nvidia) acceleratedly searches the crash key
[v] the crash key found and the crash is reproduce stable
[v] after used fix kernel - the crash is stopped
[v] rigGPU (nvidia) acceleratedly checking fix kernel, stability test
[v] the crash key is not reproduce the crash if vliw(amd) macros are used
[v] rigGPU (nvidia) acceleratedly searches the crash key, using vliw(amd) macros
[v] the crash key not found and vliw(amd) macros no have this bug
################
Further will provide a detailed analysis of the problems, how and why they arose for those who are interested in understanding.
This bug occurs as a result of the implementation of the library of Bignum, using type int32 overflow.
The following error occurred under boundary conditions during max+1/min-1
overflow mechanics as a cycle
min=0x00000000
max=0xffffffff
max+1=min(overflow!)
min-1=max(overflow!)
Note for newbies:
We cant add/sub/mult one bignumA by bignumB at a 1time, but we can do it in N steps.
Bignum X (e.g. 256bits) split into N=8 words (e.g. 32bits each) (32x8=256bit)
Here, bn_subb_word() is macros for calculate (bignumA - bignumB), step-by-step, (n_wordA - n_wordB) + transfer 1 to next step(n+1) if overflow happend.
orig code:
r - result (a-b)
a - n_wordA of bignumA
b - n_wordB of bignumB
t - tmp var 32bit, sensitive to overflow
c - carry 1digit, it transfer flag, +/-1 to next word if overflow happened(c==1)
look to:
if [a!=0, a==b, c==1], than [a-(b+c) = max(+overflow)], this result correct but overflow not be detect!
we can add compare to fix:
dont add - we need replace it, we can it because it includes previous compare
Fact: after this replace - the crash stopped!
final fix bn_subb_word():
Alternative fix - you can force the use of vliw(amd) macros for Nvidia.
Just add str to head of calc_addrs.cl:
################
And a little more about possible optimization.
1) The main problem is the slow openssl lib, moving to secp256k1 lib will already improve performance.
2) When calculating the compressed key, the vanitygen calculates the Y coordinate, although this is not necessary.
In fact, the program always considers an uncompressed key, and compresses it at the end if requested.
3) Squaring requires fewer multiplications than multiplying two different numbers.
My attempts to create bn_sqr_mont () failed, as adding IF() inevitably breaks the parallelism of the GPU.
IF can be bypassed, but at the cost of increasing spill register. Montgomery and the GPU are a very problematic couple.
4) Symmetric rather than sequential calculation of the inversion batch is also be get acceleration.
5) Symmetric Y and endomorphism(lambda/betta) of ecdsa is also be get acceleration.
All these optimizations are possible, but it’s a waste of time.
Because VanitySearch came out, deprived of all the above disadvantages.
https://bitcointalksearch.org/topic/vanitysearch-yet-another-address-prefix-finder-5112311
Now the only advantage VanityGen is OpenCL and the expanded support for altcoins in exploitagency/vanitygen-plus.
################
Final edit at Aug 15 2019
Status:
At the moment, the correction in the previous post is final and fully tested.
This is an old unresolved fundamental bug in kernel openCL, and I will help all of us fix it.
Fact: all known cases are united by - Nvidia+other(without AMD), yes, its a "green bug"
progress tests
[v] rigGPU (nvidia) acceleratedly searches the crash key
[v] the crash key found and the crash is reproduce stable
[v] after used fix kernel - the crash is stopped
[v] rigGPU (nvidia) acceleratedly checking fix kernel, stability test
[v] the crash key is not reproduce the crash if vliw(amd) macros are used
[v] rigGPU (nvidia) acceleratedly searches the crash key, using vliw(amd) macros
[v] the crash key not found and vliw(amd) macros no have this bug
################
Further will provide a detailed analysis of the problems, how and why they arose for those who are interested in understanding.
This bug occurs as a result of the implementation of the library of Bignum, using type int32 overflow.
The following error occurred under boundary conditions during max+1/min-1
overflow mechanics as a cycle
min=0x00000000
max=0xffffffff
max+1=min(overflow!)
min-1=max(overflow!)
Note for newbies:
We cant add/sub/mult one bignumA by bignumB at a 1time, but we can do it in N steps.
Bignum X (e.g. 256bits) split into N=8 words (e.g. 32bits each) (32x8=256bit)
Here, bn_subb_word() is macros for calculate (bignumA - bignumB), step-by-step, (n_wordA - n_wordB) + transfer 1 to next step(n+1) if overflow happend.
orig code:
Code:
#define bn_subb_word(r, a, b, t, c) do { \
t = a - (b + c); \
c = (!(a) && c) ? 1 : 0; \
c |= (a < b) ? 1 : 0; \
r = t; \
} while (0)
t = a - (b + c); \
c = (!(a) && c) ? 1 : 0; \
c |= (a < b) ? 1 : 0; \
r = t; \
} while (0)
r - result (a-b)
a - n_wordA of bignumA
b - n_wordB of bignumB
t - tmp var 32bit, sensitive to overflow
c - carry 1digit, it transfer flag, +/-1 to next word if overflow happened(c==1)
look to:
Code:
c = (!(a) && c) ? 1 : 0;
hmm.. how about:if [a!=0, a==b, c==1], than [a-(b+c) = max(+overflow)], this result correct but overflow not be detect!
we can add compare to fix:
Code:
c = (c && (a == b)) ? 1 : 0;
but +1 str in kernel cycle with billions interations - bad idea!dont add - we need replace it, we can it because it includes previous compare
Fact: after this replace - the crash stopped!
final fix bn_subb_word():
Code:
#define bn_subb_word(r, a, b, t, c) do { \
t = a - (b + c); \
c = (c && (a == b)) ? 1 : 0; \
c |= (a < b) ? 1 : 0; \
r = t; \
} while (0)
t = a - (b + c); \
c = (c && (a == b)) ? 1 : 0; \
c |= (a < b) ? 1 : 0; \
r = t; \
} while (0)
Alternative fix - you can force the use of vliw(amd) macros for Nvidia.
Just add str to head of calc_addrs.cl:
Code:
#define DEEP_VLIW 1
################
And a little more about possible optimization.
1) The main problem is the slow openssl lib, moving to secp256k1 lib will already improve performance.
2) When calculating the compressed key, the vanitygen calculates the Y coordinate, although this is not necessary.
In fact, the program always considers an uncompressed key, and compresses it at the end if requested.
3) Squaring requires fewer multiplications than multiplying two different numbers.
My attempts to create bn_sqr_mont () failed, as adding IF() inevitably breaks the parallelism of the GPU.
IF can be bypassed, but at the cost of increasing spill register. Montgomery and the GPU are a very problematic couple.
4) Symmetric rather than sequential calculation of the inversion batch is also be get acceleration.
5) Symmetric Y and endomorphism(lambda/betta) of ecdsa is also be get acceleration.
All these optimizations are possible, but it’s a waste of time.
Because VanitySearch came out, deprived of all the above disadvantages.
https://bitcointalksearch.org/topic/vanitysearch-yet-another-address-prefix-finder-5112311
Now the only advantage VanityGen is OpenCL and the expanded support for altcoins in exploitagency/vanitygen-plus.
################
Final edit at Aug 15 2019
I quite often get the following "out of resources" error when running oclvanitygen, sometimes after a few minutes and sometimes after several hours (nothing else is running at the time). Is there a way to reduce the load on the GPU (similar how you can reduce the number of cores on the CPU version)? Or anyone know how I might fix this? What does "grid" do, btw? Thanks
>oclvanitygen.exe -D 0:0,grid=2048x2048 -v -k -f 2patterns.txt -o 2matches.txt
[59.74 Mkey/s][total 206519140352][Prob 1.2%][50% in 2.3d] clWaitForEvents(NDRange,1): CL_OUT_OF_RESOURCES
clEnqueueMapBuffer(4): CL_INVALID_COMMAND_QUEUE
ERROR: Could not map row buffer for slot 1
ERROR: allocation failure?
>oclvanitygen.exe -D 0:0,grid=2048x2048 -v -k -f 2patterns.txt -o 2matches.txt
[59.74 Mkey/s][total 206519140352][Prob 1.2%][50% in 2.3d] clWaitForEvents(NDRange,1): CL_OUT_OF_RESOURCES
clEnqueueMapBuffer(4): CL_INVALID_COMMAND_QUEUE
ERROR: Could not map row buffer for slot 1
ERROR: allocation failure?
I know about this problem and i have fix.
Dedicated to anyone who wanted to use vanitygen for a long time, but could not.
Fact: all known cases are united by - Nvidia+other(without AMD), yes, its a "green bug" (Red fans cheering!..)
This bug has been at the center of the openCL kernel, beginning with version 0.14, from 2011 to this day.
All forks, everyone who seriously uses vanitygen in their projects,.. - all of you must update calc_addrs.cl !
4 const messages contained in this error:
Code:
clWaitForEvents (NDRange, 1): CL_OUT_OF_RESOURCES
clEnqueueMapBuffer (4): CL_INVALID_COMMAND_QUEUE
ERROR: Could not map row buffer for slot 0/1
ERROR: allocation failure?
clEnqueueMapBuffer (4): CL_INVALID_COMMAND_QUEUE
ERROR: Could not map row buffer for slot 0/1
ERROR: allocation failure?
This bug occurs as a result of the implementation of the library of Bignum, using type int32 overflow.
This is the exactly piece of code that vanitygen crashes:
Code:
#define bn_subb_word(r, a, b, t, c) do { \
t = a - (b + c); \
c = (!(a) && c) ? 1 : 0; \
c |= (a < b) ? 1 : 0; \
r = t; \
} while (0)
if you follow the logic then, u see wrong detect transfer +/-1 if a!=0 and a==b and c==1. t = a - (b + c); \
c = (!(a) && c) ? 1 : 0; \
c |= (a < b) ? 1 : 0; \
r = t; \
} while (0)
Therefore, some of the keys are considered to be incorrect, and some result in the crash of the program.
Just replace in notepad(edit calc_addrs.cl) this macros:
Code:
#define bn_subb_word(r, a, b, t, c) do { \
t = a - (b + c); \
c = (c && (a == b)) ? 1 : 0; \
c |= (a < b) ? 1 : 0; \
r = t; \
} while (0)
Alternative fix - you can force the use of vliw(amd) macros for Nvidia.t = a - (b + c); \
c = (c && (a == b)) ? 1 : 0; \
c |= (a < b) ? 1 : 0; \
r = t; \
} while (0)
Just add str to head of calc_addrs.cl:
Code:
#define DEEP_VLIW 1
Statistically, the crash of the program occurs once a day at 50Mkeys/sec.
When Samr7 developed this code in 2011, the performance of a vanitygen on 1 top-end videocard at that time did not exceed 10M. Thus, it takes a week of work to catch this rare bug. In the case of a rigGPU - a day, but where is the guarantee that the code is buggy, not iron and something else, right? And once a week it is easier to restart a vanitygen than to look for a hard-to-reproduce error in thousands of lines of code. The debugging situation was complicated by the built-in randomizer of the initial key, restarting every rekey_at=100M (for security reasons).
Also, montgomery cl kernel bn_from_mont() up to ver<=0.16 is faster +20% per GPU than the later ones.
Because Samr7 introduced a couple of corrections to increase the efficiency of the CPU -> due to new macros -> a variable that could be calculated once and to be calculated every interaction of the cycle -> ...
I have attached several versions of calc_addrs.cl, replace and check the performance directly on the equipment used.
https://github.com/exploitagency/vanitygen-plus/files/3499203/cores-vanitygen.zip
Code:
>oclvanitygen-plus-v1.53_rekey -v -D 0:0 -F compressed 12345678
Device: GeForce GTX 980
Driver: 430.64
Version: OpenCL 1.2 CUDA
Max compute units: 16
Max workgroup size: 1024
Grid size: 4096x4096
Modular inverse: 16384 threads, 1024 ops each
calc_addrs_orig.cl
[44.53 Mkey/s][total 662700032][Prob 0.1%][50% in 3.8h]
calc_addrs_fixsubb.cl
[44.51 Mkey/s][total 570425344][Prob 0.1%][50% in 3.8h]
calc_addrs_fixvliw.cl
[44.52 Mkey/s][total 570425344][Prob 0.1%][50% in 3.8h]
calc_addrs_fixsubb_mont022m.cl
[55.60 Mkey/s][total 662700032][Prob 0.1%][50% in 3.1h]
calc_addrs_fixsubb_mont016.cl
[57.30 Mkey/s][total 427819008][Prob 0.1%][50% in 3.0h]
calc_addrs_fixsubb_mont016m1.cl
[58.74 Mkey/s][total 486539264][Prob 0.1%][50% in 2.9h]
calc_addrs_fixsubb_mont016m2.cl
[60.22 Mkey/s][total 1275068416][Prob 0.1%][50% in 2.8h]
Device: GeForce GTX 980
Driver: 430.64
Version: OpenCL 1.2 CUDA
Max compute units: 16
Max workgroup size: 1024
Grid size: 4096x4096
Modular inverse: 16384 threads, 1024 ops each
calc_addrs_orig.cl
[44.53 Mkey/s][total 662700032][Prob 0.1%][50% in 3.8h]
calc_addrs_fixsubb.cl
[44.51 Mkey/s][total 570425344][Prob 0.1%][50% in 3.8h]
calc_addrs_fixvliw.cl
[44.52 Mkey/s][total 570425344][Prob 0.1%][50% in 3.8h]
calc_addrs_fixsubb_mont022m.cl
[55.60 Mkey/s][total 662700032][Prob 0.1%][50% in 3.1h]
calc_addrs_fixsubb_mont016.cl
[57.30 Mkey/s][total 427819008][Prob 0.1%][50% in 3.0h]
calc_addrs_fixsubb_mont016m1.cl
[58.74 Mkey/s][total 486539264][Prob 0.1%][50% in 2.9h]
calc_addrs_fixsubb_mont016m2.cl
[60.22 Mkey/s][total 1275068416][Prob 0.1%][50% in 2.8h]
I note that for the program to work fully on modern powerful equipment, especially rigGPU, recompilation with an increased value of rekey_at (default 100M) is necessary!
It's been 7 years. One Titan is able to generate 100Mkeys/sec. And updating the starting point is an extremely resource-intensive procedure (the same thing happens when program starts). That is why vanitygen fiercely sagging speed on rigGPU. It is enough to recompile with the increased rekey_at value up to 1000-10000M and the performance becomes proportional.
Also, there is incorrectly determined video memory, because after 7 years the amount of mem exceeded 4Gb (int32 overflow). Because of what the gridSize is calculated incorrectly.
https://github.com/exploitagency/vanitygen-plus/files/3499151/vanitygen-plus-PLUS1.53_rekey.zip
...Also, the best fork exploitagency/vanitygen-plus/releases distributes windows binaries only x32bit.
(maybe because need absent "cmd VS (2010) x64"?..)
For a CPU, this is a 50% loss in speed, and for a GPU it is the inability to use more than 2GB (large gridSize), which is also 10-40% of the speed, especially for modern gpu.
The link above from me contain fix opencl kernel, increased rekey, fixed auto-detection of the gridSize, release is x32 and x64bit. Enjoy!
Reference of
https://github.com/exploitagency/vanitygen-plus/issues/32
https://github.com/exploitagency/vanitygen-plus/issues/35
https://github.com/exploitagency/vanitygen-plus/issues/170
Reference of
https://bitcointalksearch.org/topic/m.1105033
https://bitcointalksearch.org/topic/m.1354949
https://bitcointalksearch.org/topic/m.2270470
https://bitcointalksearch.org/topic/m.2822415
https://bitcointalksearch.org/topic/m.12460635
https://bitcointalksearch.org/topic/m.17731262
https://bitcointalksearch.org/topic/m.18029056
https://bitcointalksearch.org/topic/m.18102435
https://bitcointalksearch.org/topic/m.21201238
https://bitcointalksearch.org/topic/m.33028351
https://bitcointalksearch.org/topic/m.36751974
Final edit at Aug 15 2019
Quote
this has been posted before and the reason is there is no need. it woudlnt work the way you think it does as the private keys dont go in any linear value.. its not like you can only check the private keys that start with a certain prefix to get public ones that do..
you dont go 1, 2, 3, 4, 5, 6, to get a, b, c, d , e.
also i think it would take a significant amount of cpu time and make things really slow.
you dont go 1, 2, 3, 4, 5, 6, to get a, b, c, d , e.
also i think it would take a significant amount of cpu time and make things really slow.
Disagree with you , let's say you are generating private keys in Sequence (1 2 3 4 5 6 .... ) ( i = 0; i < ptarraysize; i++) & calculating addresses of generated keys ~~ now even a small cpu can handle i++ with
significant speed . Lets say you set prefix and told in codes generate private keys after this prefix of 20 (e.g. you want keys after 20 so 20 21 22 23 24 25 26 27 .... . .. .) that will double the speed of generation & will be lot easy for even low end cpu as he just need to count i++ nothing else.
what would be the point exactly tho?? if you are say looking for an address 1aaron it wont matter if you are looking in order or random.
if you think that it would be better to go in order so you dont miss any, it wont matter. you can start and stop and never hit the same address twice. this is the way bitcoin works.
also, this program skips a bunch of keys.. i dont think a cpu exists that can keep up with the gpu.
Quote
this has been posted before and the reason is there is no need. it woudlnt work the way you think it does as the private keys dont go in any linear value.. its not like you can only check the private keys that start with a certain prefix to get public ones that do..
you dont go 1, 2, 3, 4, 5, 6, to get a, b, c, d , e.
also i think it would take a significant amount of cpu time and make things really slow.
you dont go 1, 2, 3, 4, 5, 6, to get a, b, c, d , e.
also i think it would take a significant amount of cpu time and make things really slow.
Disagree with you , let's say you are generating private keys in Sequence (1 2 3 4 5 6 .... ) ( i = 0; i < ptarraysize; i++) & calculating addresses of generated keys ~~ now even a small cpu can handle i++ with
significant speed . Lets say you set prefix and told in codes generate private keys after this prefix of 20 (e.g. you want keys after 20 so 20 21 22 23 24 25 26 27 .... . .. .) that will double the speed of generation & will be lot easy for even low end cpu as he just need to count i++ nothing else.
Vanitygen is not true brute force , it is randomizing all the time
/* Generate a new random private key */
EC_KEY_generate_key(pkey);
if (vcp->vc_privkey_prefix_length > 0) {
BIGNUM *pkbn = BN_dup(EC_KEY_get0_private_key(pkey));
i was wondering how can we set a reference prefix from where vanity address generator will start and vanity have to generate all keys in series rather than randomly. i guess that will boost generation 2x as compared to current hash rate.
/* Generate a new random private key */
EC_KEY_generate_key(pkey);
if (vcp->vc_privkey_prefix_length > 0) {
BIGNUM *pkbn = BN_dup(EC_KEY_get0_private_key(pkey));
i was wondering how can we set a reference prefix from where vanity address generator will start and vanity have to generate all keys in series rather than randomly. i guess that will boost generation 2x as compared to current hash rate.
this has been posted before and the reason is there is no need. it woudlnt work the way you think it does as the private keys dont go in any linear value.. its not like you can only check the private keys that start with a certain prefex to get public ones that do..
you dont go 1, 2, 3, 4, 5, 6, to get a, b, c, d , e.
also i think it would take a significant amount of cpu time and make things really slow.
Vanitygen is not true brute force , it is randomizing all the time
/* Generate a new random private key */
EC_KEY_generate_key(pkey);
if (vcp->vc_privkey_prefix_length > 0) {
BIGNUM *pkbn = BN_dup(EC_KEY_get0_private_key(pkey));
i was wondering how can we set a reference prefix from where vanity address generator will start and vanity have to generate all keys in series rather than randomly. i guess that will boost generation 2x as compared to current hash rate.
/* Generate a new random private key */
EC_KEY_generate_key(pkey);
if (vcp->vc_privkey_prefix_length > 0) {
BIGNUM *pkbn = BN_dup(EC_KEY_get0_private_key(pkey));
i was wondering how can we set a reference prefix from where vanity address generator will start and vanity have to generate all keys in series rather than randomly. i guess that will boost generation 2x as compared to current hash rate.
Good spotting feryjhie, it's a confirmed scam.
I've posted this on Youtube:
@riskyfire: please follow up, promoting a scam is not appreciated on Bitcointalk.
I've posted this on Youtube:
Quote
bitcoinvanitySCAMgen.com (URL intentionally broken) is a scam. See https://bitcointalk.org/index.php?action=trust;u=303026
Please remove it from the links and video, it's making a great video look very shady. Thanks, LoyceV.
Please remove it from the links and video, it's making a great video look very shady. Thanks, LoyceV.
@riskyfire: please follow up, promoting a scam is not appreciated on Bitcointalk.
is there a video guide for noobs? i wish i could search for random privatekeys (i just want to waste my time)
Hi, I created a beginners video a little while back
How to Create a Custom Bitcoin Vanity Address | 1BEERxdex...
https://www.youtube.com/watch?v=k7VKvgK6s58
i just watch the video but i saw that you use bitcoinvanitygen.com on your video but i think that website is a scam website.
because they stole your bitcoin's from the address you created there, and you can read more info here https://bitcointalksearch.org/topic/--1476782
is there a video guide for noobs? i wish i could search for random privatekeys (i just want to waste my time)
Hi, I created a beginners video a little while back
How to Create a Custom Bitcoin Vanity Address | 1BEERxdex...
https://www.youtube.com/watch?v=k7VKvgK6s58
Please advise me! I have a list of 15 million compressed public keys, as well as Bitcoin Address. Using "Vanitygen" is it possible to find at least one private key from any public key from the list from the large list of compressed public keys secp256k1?
Public keys: https://drive.google.com/drive/folders/1HByDJR9Ck5CdIwTl-v_IzcaVhsG8aKaA
Bitcoin Address: https://drive.google.com/file/d/1KFTPpH8fmw_44Ns0F3mEOFXXjzOQecVG
EMAIL: [email protected]
Public keys: https://drive.google.com/drive/folders/1HByDJR9Ck5CdIwTl-v_IzcaVhsG8aKaA
Bitcoin Address: https://drive.google.com/file/d/1KFTPpH8fmw_44Ns0F3mEOFXXjzOQecVG
EMAIL: [email protected]
nope, thats what makes bitcoin secure.
Please advise me! I have a list of 15 million compressed public keys, as well as Bitcoin Address. Using "Vanitygen" is it possible to find at least one private key from any public key from the list from the large list of compressed public keys secp256k1?
Public keys: https://drive.google.com/drive/folders/1HByDJR9Ck5CdIwTl-v_IzcaVhsG8aKaA
Bitcoin Address: https://drive.google.com/file/d/1KFTPpH8fmw_44Ns0F3mEOFXXjzOQecVG
EMAIL: [email protected]
Public keys: https://drive.google.com/drive/folders/1HByDJR9Ck5CdIwTl-v_IzcaVhsG8aKaA
Bitcoin Address: https://drive.google.com/file/d/1KFTPpH8fmw_44Ns0F3mEOFXXjzOQecVG
EMAIL: [email protected]
hello, i'm interested why gpu can't quickly generate addresses with low difficult, command for example:
./oclvanitygen -C BTC -o results.txt -i -D 0:0 -k 1
./oclvanitygen -C BTC -o results.txt -i -D 0:0 -k 1
I put up a website listing all the bitcoin addresses with balances, sorted from the most to the least,
https://bitkeys.work
You can see, the top address has 122K BTC in it. You can try to vanitygen your addresses by targeting those address, and good luck in some years.
https://bitkeys.work
You can see, the top address has 122K BTC in it. You can try to vanitygen your addresses by targeting those address, and good luck in some years.
Nice
It could be interesting to have the public key (if exposed) instead of a random priv key.
Which is for instance the case for the first address with 122,804BTC:
Pubkey: 03c931af9f331b7a9eb2737667880dacb91428906fbffad0173819a873172d21c4
Addr (Segwit 1x1 p2wpkh-p2sh): 385cR5DM96n1HvBDMzLHPYcw89fZAXULJP
I put up a website listing all the bitcoin addresses with balances, sorted from the most to the least,
https://bitkeys.work
You can see, the top address has 122K BTC in it. You can try to vanitygen your addresses by targeting those address, and good luck in some years.
https://bitkeys.work
You can see, the top address has 122K BTC in it. You can try to vanitygen your addresses by targeting those address, and good luck in some years.
is there a video guide for noobs? i wish i could search for random privatekeys (i just want to waste my time)
I can't find any video guide (actually I didn't searched). But there's a comprehensive guide in the Beginners and Help board.Link: [Guide] How to create your customized Bitcoin-Address (vanitygen) – step by step.
It's fool-proof, even your cat can follow it.
Good luck on finding private keys and tell us if you find one, contact me after 9999999999999999999 years
Jump to: