Bitcoin Forum
August 08, 2020, 06:50:42 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 [184] 185 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 1144960 times)
BurtW
Legendary
*
Offline Offline

Activity: 2604
Merit: 1078

All paid signature campaigns should be banned.


View Profile WWW
April 24, 2019, 02:45:34 AM
 #3661

Have anybody try to run vanitygen on Google's TPU cloud machine or any HPC service? What's the best keysearch rates has it archive so far? Huh
Why would you run it online? It is risky to do that because your data could be intercepted.
You should run vanitygen offline on a secure computer. Using OpenCL is fast enough for me.
I think his point is Google's TPU or HPU can generate vanity address at faster rate. While it's true that the information could be intercepted, using encrypted connection could solve the problem.
Using split key is a much better solution, so that Google itself can't know your private key either. They can still know you generated the address through.
I totally forget about split key. But google knowing user generate vanity address doesn't matter unless you could know bitcoin address just from partial private key, brute force to get private from an address with partial private key or have serious privacy concern.

Here is an old thread from 2012 where we all discussed how outsourcing vanity address generation could be done.  The math is discussed there if you want to read up on it.

Later, most of us in the thread gave up on the idea since anyone who cares about fungibility wants to get rid of address reuse all together.  Ideally all addresses would get used exactly two times:  once to fund it and once to spend it.

This flies in the face of the entire concept of vanity address generation.

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1596869442
Hero Member
*
Offline Offline

Posts: 1596869442

View Profile Personal Message (Offline)

Ignore
1596869442
Reply with quote  #2

1596869442
Report to moderator
Timelord2067
Legendary
*
Offline Offline

Activity: 2296
Merit: 1470


Witty! £ $ ₹ € ¥ ¢ ≠ ÷ ™


View Profile
May 11, 2019, 03:46:44 PM
 #3662

So anyways, I've solved 1BruJoLoKo while searching for a lot of other prefixes:

1BruJoLoKozkJmSktkYUhxZiwj8R7ShaED

PM me if interested, I have the private key (just not part private key)



According to the search page BTC 0.0144 is valued at

.freebitcoin.       ▄▄▄█▀▀██▄▄▄
   ▄▄██████▄▄█  █▀▀█▄▄
  ███  █▀▀███████▄▄██▀
   ▀▀▀██▄▄█  ████▀▀  ▄██
▄███▄▄  ▀▀▀▀▀▀▀  ▄▄██████
██▀▀█████▄     ▄██▀█ ▀▀██
██▄▄███▀▀██   ███▀ ▄▄  ▀█
███████▄▄███ ███▄▄ ▀▀▄  █
██▀▀████████ █████  █▀▄██
 █▄▄████████ █████   ███
  ▀████  ███ ████▄▄███▀
     ▀▀████   ████▀▀
BITCOIN
DICE
EVENT
BETTING
WIN A LAMBO !

.
            ▄▄▄▄▄▄▄▄▄▄███████████▄▄▄▄▄
▄▄▄▄▄██████████████████████████████████▄▄▄▄
▀██████████████████████████████████████████████▄▄▄
▄▄████▄█████▄████████████████████████████▄█████▄████▄▄
▀████████▀▀▀████████████████████████████████▀▀▀██████████▄
  ▀▀▀████▄▄▄███████████████████████████████▄▄▄██████████
       ▀█████▀  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  ▀█████▀▀▀▀▀▀▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.PLAY NOW.
RHavar
Legendary
*
Offline Offline

Activity: 2086
Merit: 1636



View Profile
May 11, 2019, 07:39:11 PM
 #3663

Later, most of us in the thread gave up on the idea since anyone who cares about fungibility wants to get rid of address reuse all together.  Ideally all addresses would get used exactly two times:  once to fund it and once to spend it.

This flies in the face of the entire concept of vanity address generation.

Not exactly a true vanity address, but I have played with using "private vanity addresses" which are kinda like a vanity address if you know how to "unlock" it.  (e.g. sha256(address || privateSeed)  starts with 0x000000  or something.

And you have the privacy aspects of a normal address, but you (and anyone you give the privateSeed to) have a very quick way of knowing if an address is yours (with a small amount of false positives). It's pretty sweet for scanning the blockchain for instance (just discard everything that doesn't match your private vanity address).


SkyDr4k3
Newbie
*
Offline Offline

Activity: 146
Merit: 0


View Profile
May 13, 2019, 11:12:18 PM
 #3664

is there a video guide for noobs? i wish i could search for random privatekeys (i just want to waste my time)
OgNasty
Donator
Legendary
*
Offline Offline

Activity: 3360
Merit: 1941


I 💚 Bitcoin


View Profile
May 14, 2019, 05:18:39 AM
 #3665

is there a video guide for noobs? i wish i could search for random privatekeys (i just want to waste my time)

It would literally be a waste of your time on levels I don’t think you’re fully comprehending. You’re much better off spending the money you would have wasted on electricity on lotto tickets if gambling is your thing.

nc50lc
Legendary
*
Offline Offline

Activity: 1036
Merit: 1365


Self-proclaimed Genius ㊙️


View Profile WWW
May 14, 2019, 05:30:16 AM
 #3666

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 Smiley

quantummachine
Newbie
*
Offline Offline

Activity: 11
Merit: 9


View Profile
May 16, 2019, 02:28:29 AM
Merited by Jean_Luc (1)
 #3667

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.
Jean_Luc
Sr. Member
****
Offline Offline

Activity: 406
Merit: 368


View Profile
May 16, 2019, 07:50:10 AM
 #3668

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.

Nice Wink
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
z3r013
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
May 28, 2019, 08:39:51 AM
 #3669

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
Btceon
Newbie
*
Offline Offline

Activity: 11
Merit: 3


View Profile
May 30, 2019, 09:09:38 AM
 #3670

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:              rozwrcd@gmail.com

aarons6
Legendary
*
Offline Offline

Activity: 1736
Merit: 1006


View Profile
May 30, 2019, 09:15:09 AM
 #3671

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:             rozwrcd@gmail.com



nope, thats what makes bitcoin secure.
riskyfire
Sr. Member
****
Offline Offline

Activity: 274
Merit: 250


View Profile WWW
July 17, 2019, 04:21:25 PM
 #3672

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

feryjhie
Hero Member
*****
Offline Offline

Activity: 868
Merit: 590



View Profile
July 17, 2019, 06:24:10 PM
Merited by LoyceV (4), ETFbitcoin (1)
 #3673

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://bitcointalk.org/index.php?topic=1476782.0

...loteo...
DIGITAL ERA LOTTERY


r

▄▄███████████▄▄
▄███████████████████▄
▄███████████████████████▄
▄██████████████████████████▄
▄██  ███████▌ ▐██████████████▄
▐██▌ ▐█▀  ▀█    ▐█▀   ▀██▀  ▀██▌
▐██  █▌ █▌ ██  ██▌ ██▌ █▌ █▌ ██▌
▐█▌ ▐█ ▐█ ▐█▌ ▐██  ▄▄▄██ ▐█ ▐██▌
▐█  ██▄  ▄██    █▄    ██▄  ▄███▌
▀████████████████████████████▀
▀██████████████████████████▀
▀███████████████████████▀
▀███████████████████▀
▀▀███████████▀▀
r

RPLAY NOWR
BE A MOON VISITOR!
[/center]
LoyceV
Legendary
*
Offline Offline

Activity: 1932
Merit: 6748


Thick-Skinned Gang Leader


View Profile WWW
July 17, 2019, 06:57:38 PM
 #3674

Good spotting feryjhie, it's a confirmed scam.
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.

@riskyfire: please follow up, promoting a scam is not appreciated on Bitcointalk.

analyzing
Full Member
***
Offline Offline

Activity: 212
Merit: 102


View Profile
July 22, 2019, 04:19:54 AM
 #3675

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.   

QORA    ⊙Decentralized hosting.
             ⊙ Decentralized social network
             ⊙Voting system.
aarons6
Legendary
*
Offline Offline

Activity: 1736
Merit: 1006


View Profile
July 24, 2019, 01:34:54 AM
 #3676

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.  

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.
analyzing
Full Member
***
Offline Offline

Activity: 212
Merit: 102


View Profile
July 24, 2019, 03:49:55 AM
 #3677

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.




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.

QORA    ⊙Decentralized hosting.
             ⊙ Decentralized social network
             ⊙Voting system.
aarons6
Legendary
*
Offline Offline

Activity: 1736
Merit: 1006


View Profile
July 24, 2019, 04:23:38 AM
 #3678

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.




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.

Telariust
Jr. Member
*
Offline Offline

Activity: 38
Merit: 18


View Profile
August 09, 2019, 12:04:35 PM
Last edit: August 15, 2019, 09:00:37 PM by Telariust
 #3679

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?

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?

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.
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.
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]

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://bitcointalk.org/index.php?topic=25804.msg1105033#msg1105033
https://bitcointalk.org/index.php?topic=25804.msg1354949#msg1354949
https://bitcointalk.org/index.php?topic=25804.msg2270470#msg2270470
https://bitcointalk.org/index.php?topic=25804.msg2822415#msg2822415
https://bitcointalk.org/index.php?topic=25804.msg12460635#msg12460635
https://bitcointalk.org/index.php?topic=25804.msg17731262#msg17731262
https://bitcointalk.org/index.php?topic=25804.msg18029056#msg18029056
https://bitcointalk.org/index.php?topic=25804.msg18102435#msg18102435
https://bitcointalk.org/index.php?topic=25804.msg21201238#msg21201238
https://bitcointalk.org/index.php?topic=25804.msg33028351#msg33028351
https://bitcointalk.org/index.php?topic=25804.msg36751974#msg36751974

Final edit at Aug 15 2019
Telariust
Jr. Member
*
Offline Offline

Activity: 38
Merit: 18


View Profile
August 11, 2019, 12:31:07 AM
Last edit: September 02, 2019, 10:25:15 AM by Telariust
 #3680

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:
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)

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)

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://bitcointalk.org/index.php?topic=5112311
Now the only advantage VanityGen is OpenCL and the expanded support for altcoins in exploitagency/vanitygen-plus.

################

Final edit at Aug 15 2019
Pages: « 1 ... 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 [184] 185 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!