Bitcoin Forum
September 18, 2019, 10:45:33 PM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20]  All
  Print  
Author Topic: VanitySearch (Yet another address prefix finder)  (Read 6074 times)
Jean_Luc
Full Member
***
Offline Offline

Activity: 154
Merit: 193


View Profile
August 07, 2019, 04:50:08 PM
 #381

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.
1568846733
Hero Member
*
Offline Offline

Posts: 1568846733

View Profile Personal Message (Offline)

Ignore
1568846733
Reply with quote  #2

1568846733
Report to moderator
1568846733
Hero Member
*
Offline Offline

Posts: 1568846733

View Profile Personal Message (Offline)

Ignore
1568846733
Reply with quote  #2

1568846733
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1568846733
Hero Member
*
Offline Offline

Posts: 1568846733

View Profile Personal Message (Offline)

Ignore
1568846733
Reply with quote  #2

1568846733
Report to moderator
1568846733
Hero Member
*
Offline Offline

Posts: 1568846733

View Profile Personal Message (Offline)

Ignore
1568846733
Reply with quote  #2

1568846733
Report to moderator
Telariust
Jr. Member
*
Online Online

Activity: 35
Merit: 15


View Profile
August 09, 2019, 01:17:56 AM
Last edit: September 03, 2019, 10:11:44 AM by Telariust
 #382

Quote
..new 5 ecc algorithms uncompatible with split-key project vanitypool.appspot.com
Quote from: Telariust
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.
Quote from: Jean_Luc
..AddDirect requires a modular inversion which costs hundreds of modular multiplications.  goup/sym/endo optimization is done to avoid slow modular inversions..
Yes, I figured it out, it’s impossible to fix it by saving 6 algo, so..

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

Activity: 154
Merit: 193


View Profile
August 09, 2019, 06:53:51 AM
 #383

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
Telariust
Jr. Member
*
Online Online

Activity: 35
Merit: 15


View Profile
August 17, 2019, 08:43:26 PM
Last edit: September 03, 2019, 09:59:04 AM by Telariust
 #384

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)
Angelo1710
Newbie
*
Offline Offline

Activity: 17
Merit: 0


View Profile
August 20, 2019, 12:11:52 PM
 #385

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
Smutsen
Member
**
Offline Offline

Activity: 73
Merit: 11


View Profile
August 20, 2019, 06:28:20 PM
Merited by OgNasty (1)
 #386

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 <pub. address> , <WIF> , <HEX> (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.
WhyFhy
Full Member
***
Offline Offline

Activity: 434
Merit: 101


View Profile
August 21, 2019, 02:32:33 PM
 #387

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

Activity: 17
Merit: 0


View Profile
August 26, 2019, 06:00:41 PM
 #388

How do you change keyspace in vanitysearch? Let's say I want to run in 160bit+ space.

Tnx
dextronomous
Full Member
***
Offline Offline

Activity: 245
Merit: 100


View Profile
September 09, 2019, 01:26:54 AM
Last edit: September 14, 2019, 01:53:09 AM by dextronomous
 #389

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 -r 10000 -s 0000000000000000000000000000000000000000000000000000000A00000000 -

Starting at PrivKey: 0x0000000000000000000000000000000000000000000000000000000A00000000  - guess here it starts
care for the beer soon.

TIDEX ▬▬ .CRYPTO COINS AND ASSET TRADING. ▬▬ TIDEX
▬▬▰▰▬▬▰▰▰▬▬▰▰▰▬▬▰▰▰▬▬▰▰▬▬
NEW EXCHANGE
airppc
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
September 11, 2019, 05:35:06 PM
Last edit: Today at 12:43:50 PM by airppc
 #390

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]

WhyFhy
Full Member
***
Offline Offline

Activity: 434
Merit: 101


View Profile
September 11, 2019, 05:47:39 PM
 #391

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

Activity: 434
Merit: 101


View Profile
September 11, 2019, 05:49:17 PM
 #392

Im a little flusterd to see someone worked out the bug on solutions and hasnt shared it.
Angelo1710
Newbie
*
Offline Offline

Activity: 17
Merit: 0


View Profile
September 12, 2019, 09:16:31 AM
 #393

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.
MeBender
Newbie
*
Offline Offline

Activity: 24
Merit: 0


View Profile
September 16, 2019, 04:16:34 AM
 #394

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

Activity: 434
Merit: 101


View Profile
September 16, 2019, 12:54:42 PM
Last edit: Today at 12:49:15 PM by WhyFhy
 #395

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

Activity: 2
Merit: 0


View Profile
Today at 12:41:38 PM
 #396

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?
MeBender
Newbie
*
Offline Offline

Activity: 24
Merit: 0


View Profile
Today at 01:13:49 PM
 #397

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
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20]  All
  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!