Pages:
Author

Topic: VanitySearch (Yet another address prefix finder) - page 43. (Read 32072 times)

jr. member
Activity: 114
Merit: 5
Code:
-snipped  [P 100.00%][99.00% in 00:00:00][0]

This is an error right? lol
No just unlucky. keep trying!


edit just noticed the keypsec count somethings off

Yeah I set the grid to 4480x128 and it gave me crazy Mkey/s Cheesy
newbie
Activity: 2
Merit: 0
Results with GeForce RTX 2080 SUPER!

Code:
oclvanitygen:
[Compressed]
[272.99 Mkey/s][total 1119879168][Prob 0.0%][50% in 1.579412e+008y]
[Uncompressed]
[247.86 Mkey/s][total 1509949440][Prob 0.0%][50% in 1.739557e+008y]


Code:
vanitysearch:
[Compressed]
GPU: GPU #0 GeForce RTX 2080 SUPER (48x64 cores) Grid(384x256)
[2001.52 Mkey/s][GPU 2001.52 Mkey/s][Total 24.76 Bkeys][Prob 0.0%][50% in 12.0d][Found 0]
[Uncompressed]
GPU: GPU #0 GeForce RTX 2080 SUPER (48x64 cores) Grid(384x256)
[1244.88 Mkey/s][GPU 1244.88 Mkey/s][Total 10.27 Bkeys][Prob 0.0%][50% in 19.3d][Found 0]
[Compressed or Uncompressed]
GPU: GPU #0 GeForce RTX 2080 SUPER (48x64 cores) Grid(384x256)
[780.01 Mkey/s][GPU 780.01 Mkey/s][Total 15.10 Bkeys][Prob 0.0%][50% in 30.9d][Found 0]

is there any way to increase Uncompressed speed like Compressed search?
hero member
Activity: 1438
Merit: 513
Code:
-snipped  [P 100.00%][99.00% in 00:00:00][0]

This is an error right? lol
No just unlucky. keep trying!


edit just noticed the keypsec count somethings off
jr. member
Activity: 114
Merit: 5
Code:
C:\users\default\vanitygen>vanitysearch -gpu -o vs.txt -g 4480 -t 0 1FeexV6b
VanitySearch v1.15
Difficulty: 888446610539
Search: 1FeexV6b [Compressed]
Start Mon Sep 16 05:14:20 2019
Base Key: C85DB0A401AC6C5BA884366178067CBA2F3E43DDAA5AF0634FD004DA96B652D7
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1080 Ti (28x128 cores) Grid(4480x128)
5757943931943.335 MK/s (GPU 5757943931943.335 MK/s) (2^64.00) [P 100.00%][99.00% in 00:00:00][0]

This is an error right? lol
newbie
Activity: 26
Merit: 0
If we use -r flag for re-key and we set it to let's say 1M, does that mean program will use random base key every 1M keys? Would that work with higher speeds? When I try to use -r and I set it up to 1M then I get max speed of 35MK/s (uncompressed). Probably that is maximum that it can calculate when you use very low re-key number for base key.
hero member
Activity: 1438
Merit: 513
Im a little flusterd to see someone worked out the bug on solutions and hasnt shared it.
hero member
Activity: 1438
Merit: 513
Hi,

Here is the results with GeForce RTX 2060 SUPER!

why Uncompressed speed is lower then Compressed with vanitysearch?
oclvanitygen can make both compressions in same speed.
any tricks/help to improve Uncompressed speeds as compressed?
because i need Uncompressed only.

oclvanitygen:
[compressed]
[164.75 Mkey/s][total 1336934400][Prob 0.0%][50% in 2.5d]
[Uncompressed]
[151.58 Mkey/s][total 1880621056][Prob 0.0%][50% in 2.7d]

vanitysearch:
[Compressed]
GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[1361.71 Mkey/s][GPU 1361.71 Mkey/s][Total 24.39 Bkeys][Prob 2.7%][50% in 00:07:14][Found 0]
[Uncompressed]
GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[827.71 Mkey/s][GPU 827.71 Mkey/s][Total 20.96 Bkeys][Prob 2.3%][50% in 00:11:58][Found 0]
[Compressed or Uncompressed]
GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[519.94 Mkey/s][GPU 519.94 Mkey/s][Total 13.26 Bkeys][Prob 1.5%][50% in 00:19:18][Found 0]



You must be the one solving the work this week. Noticed the list is diminishing
newbie
Activity: 2
Merit: 0
Hi,

Here is the results with GeForce RTX 2060 SUPER!

why Uncompressed speed is lower then Compressed with vanitysearch?
oclvanitygen can make both compressions in same speed.
any tricks/help to improve Uncompressed speeds as compressed?
because i need Uncompressed only.

Code:
oclvanitygen:
[compressed]
[164.75 Mkey/s][total 1336934400][Prob 0.0%][50% in 2.5d]
[Uncompressed]
[151.58 Mkey/s][total 1880621056][Prob 0.0%][50% in 2.7d]

Code:
vanitysearch:
[Compressed]
GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[1361.71 Mkey/s][GPU 1361.71 Mkey/s][Total 24.39 Bkeys][Prob 2.7%][50% in 00:07:14][Found 0]

[Uncompressed]
GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[827.71 Mkey/s][GPU 827.71 Mkey/s][Total 20.96 Bkeys][Prob 2.3%][50% in 00:11:58][Found 0]

[Compressed or Uncompressed]
GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[519.94 Mkey/s][GPU 519.94 Mkey/s][Total 13.26 Bkeys][Prob 1.5%][50% in 00:19:18][Found 0]

full member
Activity: 431
Merit: 105
hi there angelo1710.

i really can't tell, don't really know a lot about it. wish i did. guess range is not same as seed -s seed: Specify a seed for the base key, default is random,?

>powershell Get-Date && VanitySearch-1.15_bitcrack -stop -t 0 -gpu -gpuId 0 -r 10000 ---keyspace 8000000000000000000000000000000000000000

Starting at PrivKey: 8000000000000000000000000000000000000000  - guess here it starts
care for the beer soon.
newbie
Activity: 26
Merit: 0
How do you change keyspace in vanitysearch? Let's say I want to run in 160bit+ space.

Tnx
hero member
Activity: 1438
Merit: 513
does it support only "add" algorithm for final private key reconstruction ?
Vanitypool supports only uncompressed addresses or both ?

see
gobittest.appspot.com/VanityAll
used add/mul with comp/uncomp = 4 total
(add + uncomp, add + comp, mul + comp, mul + uncomp)
"Solved work" confirms this in the "Solution type"
(most add + uncomp entries because this is vanitygen default)

mul we do not need. I guess this was a trick to get 2x keys for the price of 1M
(like symY/symXBatch/endomorph proposed by arulbero)

we need the splitKey and the addition candidateKey+splitKey not to change

your program gives the result and does not tell which of the 6algos now
when I tried to write the analyzer in python, I failed twice.
At first, I intuitively applied sym/endomorph to the result of the addition of the candidateKey and splitKey, but 5/6 addresses were not recognized.
Well, Of course, I thought, True choice if applied sym/endomorph to the candidateKey before adding with splitKey, but it all happened again.
There is a third option - you apply sym/endomorph to splitKey!
After which the analyzer determined all cases correctly.
I am surprised by this choice, because it makes your calculation incompatible with 5/6 with the pool.
I guess this is due to the late addition of the splitKey to your self-contained code with minimal edits.
In my opinion, you need to apply sym/endomorph to the candidate and not apply to splitKey or the result of addition
imho, after fix u program should also work fine.
(maybe it have some math depend; maybe, I am mistaken and do not take into account some subtlety or dependence)



your absolutely right , I got on 2x Tesla's for a few days, -sp (split key from vanitypool) doesn't work out or add up , I solved 1orgynych  all outputs ,com,uncom add multiply , nothing worked ....
 I went from 5 billion keys to 2.7 with -sp applied , and the solution not accepted . So I tried others from bittadd  , they didn't work either.     

My question is how did you get 1? (5/6) I got 0

@op you gone this far, but the number 1 use for profit on your application  is null please fix this so I can chew down vanitypool.appspot.com

Use vanitypool.appspot.com  and bitaddress.org for reference and testing .

If we get this worked out I'll tip you after I submit work/get paid.
I'll be coming at this from a v100 x4 deep learning rig after it's built
Just courious will this be based on -gpu or -t ? I honestly have no clue as this will be my first link build. 
 The DL rig should bench better
member
Activity: 73
Merit: 11
Amazing job. I am experimenting with cpu only because I have only AMD gpus but still amazing. I would like to ask you to reconsider the output (-o) format. For example, when I want multiple addresses and I run:
c:\Vanity>VanitySearch.exe -u -o results.txt 1btc
Code:
VanitySearch v1.15
Difficulty: 4553521
Search: 1btc [Uncompressed]
Start Tue Aug 20 21:18:13 2019
Base Key: 391AF8A6A5BC85D20E312522FC3D8E33CF6D0425DB958F41C6778E3DEB4F1639
Number of CPU thread: 4
^C946 MK/s (GPU 0.000 MK/s) (2^24.87) [P 99.88%][99.00% in 00:00:00][5]

the results in my .txt looks like this:
Code:
Pub Addr: 1btcQnW3mtovfvuzHhmhL7BBrTqGgW72y
Priv (WIF): p2pkh:5J6rmbeTg5nSNTnpi4DXNq7ZiduMgsKX4JmEzBSeLweWdtgqTeX
Priv (HEX): 0x25A11558D36F1D8D8A033E68E122F71AE114AD0F8375387727830F598BB

Pub Addr: 1btcWchj3aTBbhcMGwv4LxKtx9mayu9dk
Priv (WIF): p2pkh:5JKitnrGwGfVtSGPYXjtEcRvHLEA4okRC2gY7nBWEpbQjFt49nN
Priv (HEX): 0x42D6C7EEF9B4A910AA1551D5F54EAAE554C9954562EE4A1C62BB26A7C77

Pub Addr: 1btcbcB4keekZp3oz3D1CKmdRpiFWcMcy
Priv (WIF): p2pkh:5Kj8BxUojbKmKRT5Uw691iB2Ji7Nh2ZoPe1yhXQF4TPGhrkKhiz
Priv (HEX): 0xFBABE112C14A5470D05DE995D5AB15C33CF47BE403051628A90533E3225

Pub Addr: 1btc9t2Jqp7XqejUE73K2pJLTLr76AAo3
Priv (WIF): p2pkh:5K32VbXoxodbpgST9ta4jz81bLkJo4G7y4x61ewLkETRx6tjYcq
Priv (HEX): 0xA09F9F3E3DC38B0BDA1475E124104EB52B10D00876F172D81AEC0D4F100

Pub Addr: 1btca7bYTBxK4AmMsDYyZ8gdCArgHp9Dd
Priv (WIF): p2pkh:5JKeqD95y5Sa4URnQCXhisKmDQckRxx79eaYvo2REbcKdtPHpA8
Priv (HEX): 0x42AE12EE5C55FF6C93B27C476B9A24B848C1C1F6F507F3273A70AAB68FA

If every solution was in 1 line with a "," or "space" to separate , , (like the bulk addresses on bitaddress.org) it would be more convenient for every user to move it on an .xls or .ods and pick a column to input on electrum wallet  for example(addresses for watch only or WIF).

Thank you Smiley
M.
newbie
Activity: 26
Merit: 0
Can we use this tool the same way as we use Bitcrack?

Will command like this work to search through txt file with addresses and trying random private keys on them and then if the key is found save it to another txt file:

Code:
VanitySearch.exe -u -i myaddresslist.txt -o privatekey.txt

Also, does every new session starts at random keyspace?

Tnx
jr. member
Activity: 38
Merit: 18
Look to:

GPU/GPUEngine.h
Code:
// Number of thread per block
#define NB_TRHEAD_PER_GROUP 128

try increase it to 256 or 512..

Code:
>VanitySearch-1.1.5_th128gr -t 0 -gpu  12345689
GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(120x128)
549.958 MK/s (GPU 549.958 MK/s) (2^33.98) [P 1.88%][50.00% in 00:18:09][0]

>VanitySearch-1.1.5_th256gr -t 0 -gpu  12345689
GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(120x256)
664.534 MK/s (GPU 664.534 MK/s) (2^34.08) [P 2.02%][50.00% in 00:14:59][0]

>VanitySearch-1.1.5_th512gr -t 0 -gpu  12345689
GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(120x512)
710.364 MK/s (GPU 710.364 MK/s) (2^34.35) [P 2.43%][50.00% in 00:13:56][0]
hashrate diff:
664/549 = x1,20
710/549 = x1,29

how about -g argv?
120x512=61440
480x128=64440
but it not equal:
Code:
>VanitySearch-1.1.5_th128gr  -t 0 -gpu  -g 480  12345689
GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(480x128)
566.206 MK/s (GPU 566.206 MK/s) (2^32.40) [P 0.64%][50.00% in 00:17:57][0]
-g is useless for it, recompilation is necessary
https://github.com/JeanLucPons/VanitySearch/files/3568897/VanitySearch-1.1.5_th128gr.orig.zip
https://github.com/JeanLucPons/VanitySearch/files/3568900/VanitySearch-1.1.5_th256gr.zip
https://github.com/JeanLucPons/VanitySearch/files/3568904/VanitySearch-1.1.5_th512gr.zip
recompiled, non-official build from me (while Jean_Luc thinks what to do)
sr. member
Activity: 462
Merit: 701
Yes, I figured it out, it’s impossible to fix it by saving 6 algo, so..

Yes, by using AddDirect you can effectively reduce the problem to case 1 but you loose all benefits, it is like generating random number, add it to the starting key and check the address.
IMHO, the best way is as you have done, keep only case 1 and can keep the group optimization.

(by the way, why does release sm30 load sm60 cores, is there no error here?)

Release SM30 is especially here for debugging purpose.

COMPARE
if runtime right:
196s / 125s = ~1,56
if hashrate right:
195MK/s / 105Mk/s = ~1,85

VanitySearch win!   Cool
(issue created "need symmetry when calculating batch inversion" github.com/brichard19/BitCrack/issues/188, await..)

Thanks for the comparison Wink
jr. member
Activity: 38
Merit: 18
.. reduce it to only one is not obvious.
This is exactly what was required to be done!

I just commented out all the symY/endo; also excluded the use of the algo for compressed keys with negative zero.
You can to add a separate release how did you do it for cuda8 and sm30.
(by the way, why does release sm30 load sm60 cores, is there no error here?)

You need? You do!  Grin (sry my obsession)

[VanitySearch v1.15 origin]

Code:
>VanitySearch-1.15 -nosse -stop -t 4 12345678
5.275 MK/s (GPU 0.000 MK/s) (2^25.92) [P 0.01%][50.00% in 1.4d][0]

>VanitySearch-1.15 -stop -t 4 12345678
11.221 MK/s (GPU 0.000 MK/s) (2^28.44) [P 0.04%][50.00% in 15:14:11][0]

>VanitySearch-1.15 -gpu -stop -t 0 12345678
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
375.384 MK/s (GPU 375.384 MK/s) (2^32.96) [P 0.94%][50.00% in 00:26:58][0]


[VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)]
Code:
C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 4 -nosse -o __keyinfo.txt -sp 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd  12345
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 4553521
Search: 12345 [Compressed, with public key]
Start Thu Aug  8 12:11:09 2019
Base Key: 6B10396F80C062F2474865C76739A1D1C815F9B9EECFA46B328F90118FD0149E
Number of CPU thread: 4
4.464 MK/s (GPU 0.000 MK/s) (2^28.80) [P 100.00%][99.00% in 00:00:00][101]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 4 -o __keyinfo.txt -sp 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd  12345
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 4553521
Search: 12345 [Compressed, with public key]
Start Thu Aug  8 12:13:13 2019
Base Key: D56EE34383C48B0D4194E834A7955021879BF3AB5444019168768D58BE4E3895
Number of CPU thread: 4
8.212 MK/s (GPU 0.000 MK/s) (2^28.63) [P 100.00%][99.00% in 00:00:00][105]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 4 -o __keyinfo.txt -sp 04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235  12345
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 4553521
Search: 12345 [Uncompressed, with public key]
Start Thu Aug  8 12:14:52 2019
Base Key: 3B08999D16D9E5AF4EE27B7F5D8748B63D62446FB54B2BD1B7A28E46FCF30570
Number of CPU thread: 4
5.963 MK/s (GPU 0.000 MK/s) (2^28.82) [P 100.00%][99.00% in 00:00:00][107]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 0 -gpu -o __keyinfo.txt -sp 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd  123456
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 264104224
Search: 123456 [Compressed, with public key]
Start Thu Aug  8 12:16:56 2019
Base Key: ED70397FC554858B8F3D3A84C5B4A1B50E5B289315F4833BDFEA93806740B572
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
197.134 MK/s (GPU 197.134 MK/s) (2^34.37) [P 100.00%][99.00% in 00:00:00][100]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 0 -gpu -o __keyinfo.txt -sp 04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235 123456
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 264104224
Search: 123456 [Uncompressed, with public key]
Start Thu Aug  8 12:19:26 2019
Base Key: 74317CCE4CC9525C7A6F276A82E13C7E325DA6B6DD04F673759D8497B524D6D0
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
158.337 MK/s (GPU 158.337 MK/s) (2^34.64) [P 100.00%][99.00% in 00:00:00][100]


..with regard to..
Code:
[quote author=stivensons link=topic=5112311.msg50017516#msg50017516 date=1551710888]
Will there be settings like Bitcrack in the future?
 -i, --in FILE
Read addresses from FILE, one address per line. If FILE is "-" then stdin is read

Yes, I'm thinking to add this. It will need an important refurbishment of the code however it goes in the same way as optimizing data transfer. So probably yes.

Code:
--keyspace KEYSPACE
    Specify the range of keys to search, where KEYSPACE is in the format,

START:END start at key START, end at key END
START:+COUNT start at key START and end at key START + COUNT
    :END start at key 1 and end at key END
:+COUNT start at key 1 and end at key 1 + COUNT

No (if I understand well the purpose of this option).
VanitySearch is a prefix finder in order to generate usable addresses, you can specifie a seed to generate a base key ,it is even recommended. That's all. The seed is then passed into a pbkdf2_hmac_sha512 in order to protect against seed search attack. If you don't specifie the seed, the basekey is generated using timestamps (in us) plus the date and also passed into the pbkdf2_hmac_sha512.
The result of the pbkdf2_hmac_sha512 is then passed into a SHA256 wich is use as the base key.


[VanitySearch ver1.15.2, add BitCrack mode, startPrivKey from seed arg]

RANGE: 0xF00000000 - 0xA00000000 = 0x500000000 (21,474,836,480)

Code:
>powershell Get-Date && VanitySearch-1.15_bitcrack -stop -t 0 -gpu -r 10000 -s 0000000000000000000000000000000000000000000000000000000A00000000 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg && powershell Get-Date

8 Aug 2019 y. 22:54:43

VanitySearch v1.15.2, add BitCrack mode, startPrivKey from seed arg
Difficulty: 1461501637330902918203684832716283019655932542976
Search: 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg [Compressed]
Start Thu Aug  8 22:54:44 2019
Starting at PrivKey: 0x0000000000000000000000000000000000000000000000000000000A00000000
Save progress every 10000 Mkeys
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)

[save] 0x0000000000000000000000000000000000000000000000000000000A00000000
197.135 MK/s (GPU 197.135 MK/s) (2^33.26) [P 0.00%][50.00% in 1.6295e+32y][0]
[save] 0x0000000000000000000000000000000000000000000000000000000C540BE400
197.135 MK/s (GPU 197.135 MK/s) (2^34.26) [P 0.00%][50.00% in 1.6295e+32y][0]
[save] 0x0000000000000000000000000000000000000000000000000000000EA817C800
196.087 MK/s (GPU 196.087 MK/s) (2^34.48) [P 0.00%][50.00% in 1.63821e+32y][0]

Pub Addr: 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9MxjBfWawjmiQu7
Priv (HEX): 0x0000000000000000000000000000000000000000000000000000000F00000000

8 Aug 2019 y. 22:56:48
RUNTIME: 22:56:48 - 22:54:43 = 00:02:05 (125sec)



[BitCrack v0.30]
Code:
>powershell Get-Date && cuBitCrack-0.30 -c -d 0 -b 32 -t 512 -p 64 --keyspace 0000000000000000000000000000000000000000000000000000000A00000000 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg  && powershell Get-Date

8 Aug 2019 y. 23:06:32

[2019-08-08.23:06:33] [Info] Compression: compressed
[2019-08-08.23:06:33] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000A00000000
[2019-08-08.23:06:33] [Info] Ending at:   FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
[2019-08-08.23:06:33] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2019-08-08.23:06:33] [Info] Initializing GeForce GTX 980
[2019-08-08.23:06:33] [Info] Generating 1,048,576 starting points (40.0MB)
[2019-08-08.23:06:33] [Info] 10.0%
[2019-08-08.23:06:33] [Info] 20.0%
[2019-08-08.23:06:33] [Info] 30.0%
[2019-08-08.23:06:33] [Info] 40.0%
[2019-08-08.23:06:33] [Info] 50.0%
[2019-08-08.23:06:34] [Info] 60.0%
[2019-08-08.23:06:34] [Info] 70.0%
[2019-08-08.23:06:34] [Info] 80.0%
[2019-08-08.23:06:34] [Info] 90.0%
[2019-08-08.23:06:34] [Info] 100.0%
[2019-08-08.23:06:34] [Info] Done
GeForce GTX 980  490 / 8192MB | 1 target 107.17 MKey/s (21,418,213,376 total) [00:03:11][2019-08-08.23:09:48] [Info] Address:     1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg
                             Private key: 0000000000000000000000000000000000000000000000000000000F00000000
                             Compressed:  yes
                             Public key:
                             0382113A9377D0B8638231D9669811A7022B31F5805B0AE2C4E0C0A6B7C3C934B3

[2019-08-08.23:09:48] [Info] No targets remaining

8 Aug 2019 y. 23:09:48
RUNTIME: 23:09:48 - 23:06:32 = 00:03:16 (196sec)


COMPARE
if runtime right:
196s / 125s = ~1,56
if hashrate right:
195MK/s / 105Mk/s = ~1,85

VanitySearch win!   Cool
(issue created "need symmetry when calculating batch inversion" github.com/brichard19/BitCrack/issues/188, await..)

source and binary attached
i warn, only 1 gpu is supported!
i warn, on modern gpu (gtx1070) will get equal or decrease in speed (engine need some fix without 5algo)!
just to make sure that the numbers are real - the symmetrical inversion of the pack is really faster.
https://github.com/brichard19/BitCrack/files/3514377/VanitySearch-1.15.2_bitcrack_prototype.zip

##########################
updated

Need retest gtx980 for cuBitCrack (bad arg -p 64, -p 1024 more optimal, iam sry)

Code:
>VanitySearch-1.15 -t 0 -gpu ...
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
381.087 MK/s (GPU 381.087 MK/s) (2^32.31) [P 0.01%][50.00% in 1.1d][0]

>VanitySearch-1.15.2_bitcrack -t 0 -gpu ...
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
199.652 MK/s (GPU 199.652 MK/s) (2^30.89) [P 0.00%][50.00% in 1.60896e+32y][0]

>cuBitCrack-0.30 -c -d 0 -b 16 -t 512 -p 1024 ...
GeForce GTX 980  1240 / 8192MB | 1 target 157.66 MKey/s (1,996,488,704 total)

and now
gtx980 hashrate VSBC/BC = 199/157 = x1.25
sr. member
Activity: 462
Merit: 701
Hello,

I really don't have much free time at the moment to work on this program.
But by using AddDirect you loose all benefits of goup/sym/endo because AddDirect requires a modular inversion which costs hundreds of modular multiplications.  goup/sym/endo optimization is done to avoid slow modular inversions.
jr. member
Activity: 38
Merit: 18
Quote from: Telariust
In my opinion, you need to apply sym/endomorph to the candidate and not apply to splitKey or the result of addition
As you don't know the privKey when mining , it is not possible to calculate an offset to add in order to reduce to case 1.
May be I also missed something...

Well of course it’s possible! Are you sure you're a jedidev?) Use Force, Luc!)
Oh, ok, explain, all simple.

I compared ver 1.12 vs 1.13 to understand how you added splitkey support.
You generate starting points from the seed, and add a splitkey to them. That is the whole problem.
With this implementation, it is necessary to apply symY/endomorph to the splitkey.
(what yourself do at the stage of indirect verification of the pair)
And you did not need to make changes to the code of cuda.
It’s convenient, a minimum of edits, everything works, yes. But not with appspot pool.

To make it compatible with the pool, you need to add a splitkey after applying symY/endomorph right before hash160.
It’s not very difficult there, but the performance will suffer, because the operations of adding points are added.

I have fixed a few functions for cpu -nosse only, a rough prototype demonstrating that this is possible.
Code is sloow, and problem not in sse. I think secp->AddDirect() is really tardy. I hope you find a quick solution.


Code:
C:\Users\User\source\repos\VanitySearch-1.15\x64\Release>VanitySearch -stop -t 4 -s "A Strong Password" -kp
Priv : L2JtWKgFrwzjyw4UQjaCMHu8Cq3e6yuq4Thdjd6H462XnTJz9ftE
Pub  : 0280C3E351A2F47F1A09A20F130B922C2BE2009F4CB4892901559AE09ABB357389

C:\Users\User\source\repos\VanitySearch-1.15\x64\Release>VanitySearch -stop -t 4 -sp 0280C3E351A2F47F1A09A20F130B922C2BE2009F4CB4892901559AE09ABB357389 -nosse -o __keyinfo.txt 12345
VanitySearch v1.15
Difficulty: 4553521
Search: 12345 [Compressed, with public key]
Start Sat Aug  3 03:39:07 2019
Base Key: A6CDE51DC26E832F9C7AB673FF6B5F8F9D0C7F121E9A115CAC45B7884671F757
Number of CPU thread: 4
0.995 MK/s (GPU 0.000 MK/s) (2^20.92) [P 35.41%][50.00% in 00:00:01][0]

C:\Users\User\source\repos\VanitySearch-1.15\x64\Release>type __keyinfo.txt
Pub Addr: 12345zpQiMCPgjrCHcGwZ6kUsPpiid79MK
PartialPriv: KzN1kLMYrhZfRiWM8RR4dgReCHJeZmeMuPnqKS3KNj7HSe4SUTXA

C:\Users\User\source\repos\VanitySearch-1.15\x64\Release>VanitySearch -rp L2JtWKgFrwzjyw4UQjaCMHu8Cq3e6yuq4Thdjd6H462XnTJz9ftE __keyinfo.txt

Pub Addr: 12345zpQiMCPgjrCHcGwZ6kUsPpiid79MK
Priv (WIF): p2pkh:L5TC4zufJyHogQsVkTTx5hDRYVdnpBr98JknRunUaZfiBieQTxv8
Priv (HEX): 0xF5A25AAD2AA36613D8B58511DBE851C9EBE893141C00AC90823008B942A8E6ED

Code:
void VanitySearch::getCPUStartingKey(int thId,Int& key,Point& startP) {

  if (rekey > 0) {
    key.Rand(256);
  } else {
    key.Set(&startKey);
    Int off((int64_t)thId);
    off.ShiftL(64);
    key.Add(&off);
  }
  Int km(&key);
  km.Add((uint64_t)CPU_GRP_SIZE / 2);
  startP = secp->ComputePublicKey(&km);
  //if(startPubKeySpecified)
  // startP = secp->AddDirect(startP,startPubKey);

}




void VanitySearch::checkAddresses(bool compressed, Int key, int i, Point p1) {

  unsigned char h0[20];
  Point pte1[1];
  Point pte2[1];
  
  Point ptmp;

  // classic


  if (startPubKeySpecified) {
 ptmp = secp->AddDirect(p1, startPubKey);
  }
  else {
 ptmp = p1;
  }

  secp->GetHash160(searchType,compressed, ptmp, h0);
  prefix_t pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, i, 0, compressed);

  // Endomorphism #1
  pte1[0].x.ModMulK1(&p1.x, &beta);
  pte1[0].y.Set(&p1.y);

  if (startPubKeySpecified) {
 ptmp = secp->AddDirect(pte1[0], startPubKey);
  }
  else {
 ptmp = pte1[0];
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);

  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, i, 1, compressed);

  // Endomorphism #2
  pte2[0].x.ModMulK1(&p1.x, &beta2);
  pte2[0].y.Set(&p1.y);

  if (startPubKeySpecified) {
 ptmp = secp->AddDirect(pte2[0], startPubKey);
  }
  else {
 ptmp = pte2[0];
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);

  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, i, 2, compressed);


  // Curve symetrie
  // if (x,y) = k*G, then (x, -y) is -k*G

  p1.y.ModNeg();

  if (startPubKeySpecified) {
 ptmp = secp->AddDirect(p1, startPubKey);
  }
  else {
 ptmp = p1;
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);
  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, -i, 0, compressed);

  // Endomorphism #1
  pte1[0].y.ModNeg();

  if (startPubKeySpecified) {
 ptmp = secp->AddDirect(pte1[0], startPubKey);
  }
  else {
 ptmp = pte1[0];
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);

  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, -i, 1, compressed);

  // Endomorphism #2
  pte2[0].y.ModNeg();

  if (startPubKeySpecified) {
 ptmp = secp->AddDirect(pte2[0], startPubKey);
  }
  else {
 ptmp = pte2[0];
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);

  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, -i, 2, compressed);

}




bool VanitySearch::checkPrivKey(string addr, Int &key, int32_t incr, int endomorphism, bool mode) {


  Int k(&key);
  Point sp = startPubKey;

  if (incr < 0) {
    k.Add((uint64_t)(-incr));
    k.Neg();
    k.Add(&secp->order);
    //if (startPubKeySpecified) sp.y.ModNeg();
  } else {
    k.Add((uint64_t)incr);
  }

  // Endomorphisms
  switch (endomorphism) {
  case 1:
    k.ModMulK1order(&lambda);
    //if(startPubKeySpecified) sp.x.ModMulK1(&beta);
    break;
  case 2:
    k.ModMulK1order(&lambda2);
    //if (startPubKeySpecified) sp.x.ModMulK1(&beta2);
    break;
  }

  // Check addresses
  Point p = secp->ComputePublicKey(&k);
  if (startPubKeySpecified) p = secp->AddDirect(p, sp);

  string chkAddr = secp->GetAddress(searchType, mode, p);
  if (chkAddr != addr) {

    //Key may be the opposite one (negative zero or compressed key)
    k.Neg();
    k.Add(&secp->order);
    p = secp->ComputePublicKey(&k);
    if (startPubKeySpecified) {
      //sp.y.ModNeg();
      p = secp->AddDirect(p, sp);
    }
    string chkAddr = secp->GetAddress(searchType, mode, p);
    if (chkAddr != addr) {
      printf("\nWarning, wrong private key generated !\n");
      printf("  Addr :%s\n", addr.c_str());
      printf("  Check:%s\n", chkAddr.c_str());
      printf("  Endo:%d incr:%d comp:%d\n", endomorphism, incr, mode);
      return false;
    }

  }

  output(addr, secp->GetPrivAddress(mode ,k), k.GetBase16());

  return true;

}



void reconstructAdd(Secp256K1 *secp, string fileName, string outputFile, string privAddr) {

  bool compressed;
  int addrType;
  Int lambda;
  Int lambda2;
  lambda.SetBase16("5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72");
  lambda2.SetBase16("ac9c52b33fa3cf1f5ad9e3fd77ed9ba4a880b9fc8ec739c2e0cfc810b51283ce");

  Int privKey = secp->DecodePrivateKey((char *)privAddr.c_str(),&compressed);
  if(privKey.IsNegative())
    exit(-1);

  vector lines;
  parseFile(fileName,lines);

  for (int i = 0; i < (int)lines.size(); i+=2) {

    string addr;
    string partialPrivAddr;

    if (lines[i].substr(0, 10) == "Pub Addr: ") {

      addr = lines[i].substr(10);

      switch (addr.data()[0]) {
      case '1':
        addrType = P2PKH; break;
      case '3':
        addrType = P2SH; break;
      case 'b':
      case 'B':
        addrType = BECH32; break;
      default:
        printf("Invalid partialkey info file at line %d\n", i);
        printf("%s Address format not supported\n", addr.c_str());
        continue;
      }

    } else {
      printf("Invalid partialkey info file at line %d (\"Pub Addr: \" expected)\n",i);
      exit(-1);
    }

    if (lines[i+1].substr(0, 13) == "PartialPriv: ") {
      partialPrivAddr = lines[i+1].substr(13);
    } else {
      printf("Invalid partialkey info file at line %d (\"PartialPriv: \" expected)\n", i);
      exit(-1);
    }

    bool partialMode;
    Int partialPrivKey = secp->DecodePrivateKey((char *)partialPrivAddr.c_str(), &partialMode);
    if (privKey.IsNegative()) {
      printf("Invalid partialkey info file at line %d\n", i);
      exit(-1);
    }

    if (partialMode != compressed) {

      printf("Warning, Invalid partialkey at line %d (Wrong compression mode, ignoring key)\n", i);
      continue;

    } else {

      // Reconstruct the address
      Int fullPriv;
      Point p;
      Int e;
      string cAddr;
      bool found = false;

 Int save_partialPrivKey = partialPrivKey;

      // No sym, no endo
      e.Set(&privKey);
      CHECK_ADDR();

      // No sym, endo 1
      e.Set(&privKey);
      //e.ModMulK1order(&lambda);
 partialPrivKey.Set(&save_partialPrivKey);
 partialPrivKey.ModMulK1order(&lambda);
      CHECK_ADDR();

      // No sym, endo 2
      e.Set(&privKey);
      //e.ModMulK1order(&lambda2);
 partialPrivKey.Set(&save_partialPrivKey);
 partialPrivKey.ModMulK1order(&lambda2);
      CHECK_ADDR();

      // sym, no endo
      e.Set(&privKey);
      //e.Neg();
      //e.Add(&secp->order);
 partialPrivKey.Set(&save_partialPrivKey);
 partialPrivKey.Neg();
 partialPrivKey.Add(&secp->order);
      CHECK_ADDR();

      // sym, endo 1
      e.Set(&privKey);
      //e.ModMulK1order(&lambda);
      //e.Neg();
      //e.Add(&secp->order);
 partialPrivKey.Set(&save_partialPrivKey);
 partialPrivKey.ModMulK1order(&lambda);
 partialPrivKey.Neg();
 partialPrivKey.Add(&secp->order);
      CHECK_ADDR();

      // sym, endo 2
      e.Set(&privKey);
      //e.ModMulK1order(&lambda2);
      //e.Neg();
      //e.Add(&secp->order);
 partialPrivKey.Set(&save_partialPrivKey);
 partialPrivKey.ModMulK1order(&lambda2);
 partialPrivKey.Neg();
 partialPrivKey.Add(&secp->order);
      CHECK_ADDR();

      if (!found) {
        printf("Unable to reconstruct final key from partialkey line %d\n Addr: %s\n PartKey: %s\n",
          i, addr.c_str(),partialPrivAddr.c_str());
      }

    }

  }

}
legendary
Activity: 3500
Merit: 6320
Crypto Swap Exchange
If you don't measure it yourself, you won't know if it doesn't pull more power from the PCIe slot. Reference GTX 750 Ti peaks at 140W as shown in the graph above, even thought nVidia claims it should pull no more than 60 watts: https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-750-ti/specifications That said if it's not one of the cheapest boards it shouldn't be an issue.

Since I don't have a way of checking how much power is going through the PCIe port I will have to hack some numbers together from the pull though the UPS it's plugged into.
And the draw though the 12V rail of a power supply.
Don't know how accurate it will be, but it will show a big overage like the one you pointed out (60 vs 145) no way it will show 75 vs 81.

However, for now lets either table this or move it to a new / different thread because I do not want to derail this thread from what Jean_Luc is doing.

-Dave


legendary
Activity: 3472
Merit: 1724
It's at the 75W mark.
NVidia's own specs don't have the power connector:

From https://www.nvidia.com/en-us/geforce/graphics-cards/gtx-1650/

If you don't measure it yourself, you won't know if it doesn't pull more power from the PCIe slot. Reference GTX 750 Ti peaks at 140W as shown in the graph above, even thought nVidia claims it should pull no more than 60 watts: https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-750-ti/specifications That said if it's not one of the cheapest boards it shouldn't be an issue.
Pages:
Jump to: