Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 53. (Read 1153383 times)
is there any ways to get it for cloud wallet like bitgo or blockchain?
So nobody has yet been able to get a rx-480 to work with vanitygen?
I'd be delighted to give one a go if you would like to send one my way...
(Worth a shot)...
So nobody has yet been able to get a rx-480 to work with vanitygen?
Is there somewhere comparision how much Mkey/s generate nvidia cards? For example 8xx series, 9xx series and newest 1xxx series?
I know there are for mining but for vanitygen?
I know there are for mining but for vanitygen?
NVIDIA GeForce 96xx, 98xx, GT 1xx, GT 2xx, GTX 2xx (G90/GT200):
Key/s = (CUDA Cores) x (Shader MHz) x 17
AMD Radeon 58xx, 59xx, 67xx, 68xx (VLIW5):
Key/s = (Stream Processors) x (Core MHz) x 20.1
AMD Radeon 69xx (VLIW4):
Key/s = (Stream Processors) x (Core MHz) x 13.6
From the OP
Is there somewhere comparision how much Mkey/s generate nvidia cards? For example 8xx series, 9xx series and newest 1xxx series?
I know there are for mining but for vanitygen?
I know there are for mining but for vanitygen?
There's bound to be something in the 140 pages of talk on the subject - use the search box on the top of this page (at top right) to search through this tread. Hope you find what you are looking for.
Is there somewhere comparision how much Mkey/s generate nvidia cards? For example 8xx series, 9xx series and newest 1xxx series?
I know there are for mining but for vanitygen?
I know there are for mining but for vanitygen?
Has anyone used vanitygen with a rx-480 yet? I'm curious what it can do.
it gives an error
Code:
C:\oclvanitygen>oclvanitygen64.exe -o done.txt -D 0:0 -D 0:1 1aarons6
Difficulty: 51529903411245
Compiling kernel, can take minutes...failure.
clBuildProgram: CL_BUILD_PROGRAM_FAILURE
Build log:
C:\Users\Aaron\AppData\Local\Temp\\OCL588T5.cl:180:19: error: variable in consta
nt address space must be initialized
__constant bignum bn_zero;
^
C:\Users\Aaron\AppData\Local\Temp\\OCL588T5.cl:180:19: error: constant address s
pace qualified variables are required to be initialized
2 errors generated.
error: Clang front-end compilation failed!
Frontend phase failed compilation.
Error: Compiling CL to IR
Device: Ellesmere
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: 2079.5 (VM)
Profile: FULL_PROFILE
Version: OpenCL 2.0 AMD-APP (2079.5)
Max compute units: 36
Max workgroup size: 256
Global memory: 0
Max allocation: -50331648
Could not open device '0:0', ignoring
Compiling kernel, can take minutes...failure.
clBuildProgram: CL_BUILD_PROGRAM_FAILURE
Build log:
C:\Users\Aaron\AppData\Local\Temp\\OCL588T11.cl:180:19: error: variable in const
ant address space must be initialized
__constant bignum bn_zero;
^
C:\Users\Aaron\AppData\Local\Temp\\OCL588T11.cl:180:19: error: constant address
space qualified variables are required to be initialized
2 errors generated.
error: Clang front-end compilation failed!
Frontend phase failed compilation.
Error: Compiling CL to IR
Device: Ellesmere
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: 2079.5 (VM)
Profile: FULL_PROFILE
Version: OpenCL 2.0 AMD-APP (2079.5)
Max compute units: 36
Max workgroup size: 256
Global memory: 0
Max allocation: -50331648
Could not open device '0:1', ignoring
Available OpenCL platforms:
0: [Advanced Micro Devices, Inc.] AMD Accelerated Parallel Processing
0: [Advanced Micro Devices, Inc.] Ellesmere
1: [Advanced Micro Devices, Inc.] Ellesmere
2: [AuthenticAMD] AMD FX(tm)-8350 Eight-Core Processor
C:\oclvanitygen>
Has anyone used vanitygen with a rx-480 yet? I'm curious what it can do.
Do you have any links to resources you used when you set this up?
or did you follow the main topic information?
Would like to set this up to test some of my own things for that added bit of security.
or did you follow the main topic information?
Would like to set this up to test some of my own things for that added bit of security.
Interesting stuff. Think ill pull some resources and give this a go.
You say you have been testing this for 3 years with no collision?
You say you have been testing this for 3 years with no collision?
Yes, 3 years, not a single thing.
To be honest, I may have hit one but I think I had it set to integer and the server returned a float so the application failed and yeah, lol.
Interesting stuff. Think ill pull some resources and give this a go.
Its a fantastic way to provide that extra bit of security testing your own wallets just to be sure.
You say you have been testing this for 3 years with no collision?
What sort of hardware are you running that on?
Its a fantastic way to provide that extra bit of security testing your own wallets just to be sure.
You say you have been testing this for 3 years with no collision?
What sort of hardware are you running that on?
Yeah, I've been searching for a collision for like 3 years now, not a single one.
I would think that Electrum would be far less efficient than a purpose-made application that simply has a set datastructure designed for fast contains() operations containing all addresses with non-dust amounts (by searching the chain) attached to an iterated key generator would increase your efficiency (still extremely futile and not likely at all to find any collisions). Remember that people actually use the Electrum servers for real transactions they need to send and receive.Out of curiosity what kind of hash rate have you been getting over that 3 years? and how many addresses have you scanned so far? Also you say youve been looking for non dust addresses, does this mean youve found some with very small amounts?
thanks
I average about 2 addresses a second due to having to check the balance against my Insight server, some times more depending on response time.
Scanned so far, billions, I haven't kept track.
I am looking for any address that has a totalReceived greater than 0.0, I haven't found a single one.
I probably won't ever find any this way due to the amount of possible addresses.
I have, however, found thousands of BTC addresses and keys by turning passwords into BTC addresses, brainwallets.
With the exception of brainwallets, generating a random address and checking the totalReceived or balance the odds are not favorable, at all.
So why do I do it? For fun, duh. And I am a persistent fuck, lol.
Time is money my friend.
You can easily learn yourself.
Script to generate random Bitcoin address + Insight server.
It'll take you about 3 days to get the Insight server up to date due to blockchain.
That's if you are familiar with Linux and what ever programming language you choose to generate random addresses.
I considered making a "mining pool" for this but then thought it would be kind of sketchy, haha.
Yeah, I've been searching for a collision for like 3 years now, not a single one.
I would think that Electrum would be far less efficient than a purpose-made application that simply has a set datastructure designed for fast contains() operations containing all addresses with non-dust amounts (by searching the chain) attached to an iterated key generator would increase your efficiency (still extremely futile and not likely at all to find any collisions). Remember that people actually use the Electrum servers for real transactions they need to send and receive.Out of curiosity what kind of hash rate have you been getting over that 3 years? and how many addresses have you scanned so far? Also you say youve been looking for non dust addresses, does this mean youve found some with very small amounts?
thanks
I average about 2 addresses a second due to having to check the balance against my Insight server, some times more depending on response time.
Scanned so far, billions, I haven't kept track.
I am looking for any address that has a totalReceived greater than 0.0, I haven't found a single one.
I probably won't ever find any this way due to the amount of possible addresses.
I have, however, found thousands of BTC addresses and keys by turning passwords into BTC addresses, brainwallets.
With the exception of brainwallets, generating a random address and checking the totalReceived or balance the odds are not favorable, at all.
So why do I do it? For fun, duh. And I am a persistent fuck, lol.
I average about 2 addresses a second due to having to check the balance against my Insight server, some times more depending on response time.
Scanned so far, billions, I haven't kept track.
At 2 per second and only 31.5 million seconds per year, it'll be about 200 million checks in 3 years. Not so much, and indeed, very unlikely to find a double. Extremely unlikely. Impossible, I dare say Scanned so far, billions, I haven't kept track.
I've read before that brain wallets are very insecure, when enough people use it, it becomes inevitable to have simple passwords, and brute-forcing you can find either one of them.
Finding thousands though is a LOT! How aren't these people all getting robbed?
Yeah, I've been searching for a collision for like 3 years now, not a single one.
I would think that Electrum would be far less efficient than a purpose-made application that simply has a set datastructure designed for fast contains() operations containing all addresses with non-dust amounts (by searching the chain) attached to an iterated key generator would increase your efficiency (still extremely futile and not likely at all to find any collisions). Remember that people actually use the Electrum servers for real transactions they need to send and receive.Out of curiosity what kind of hash rate have you been getting over that 3 years? and how many addresses have you scanned so far? Also you say youve been looking for non dust addresses, does this mean youve found some with very small amounts?
thanks
I average about 2 addresses a second due to having to check the balance against my Insight server, some times more depending on response time.
Scanned so far, billions, I haven't kept track.
I am looking for any address that has a totalReceived greater than 0.0, I haven't found a single one.
I probably won't ever find any this way due to the amount of possible addresses.
I have, however, found thousands of BTC addresses and keys by turning passwords into BTC addresses, brainwallets.
With the exception of brainwallets, generating a random address and checking the totalReceived or balance the odds are not favorable, at all.
So why do I do it? For fun, duh. And I am a persistent fuck, lol.
Yeah, I've been searching for a collision for like 3 years now, not a single one.
I would think that Electrum would be far less efficient than a purpose-made application that simply has a set datastructure designed for fast contains() operations containing all addresses with non-dust amounts (by searching the chain) attached to an iterated key generator would increase your efficiency (still extremely futile and not likely at all to find any collisions). Remember that people actually use the Electrum servers for real transactions they need to send and receive.Out of curiosity what kind of hash rate have you been getting over that 3 years? and how many addresses have you scanned so far? Also you say youve been looking for non dust addresses, does this mean youve found some with very small amounts?
thanks
The "pattern" from a previous "hack" targeted the random number generator, which was flawed. I don't think he looked for private keys, but rather he figured out the private key based on spent transactions and something or other ... he returned most of the coins to their owners.
Yeah, I've been searching for a collision for like 3 years now, not a single one.
yeah , i had already seen a runing script scanning the entire blockchain database to looking for non-dust amount .. and this script never got any collision too.. anyway that's always interesting, as a challenge, to try running these kind of scripts ,or better : to try coding them ( in an ethical way, indeed 
) and, as mentioned above, only your conscience could tell you what to do in case of an "hypotetic" collision .. Yeah, I've been searching for a collision for like 3 years now, not a single one.
I would think that Electrum would be far less efficient than a purpose-made application that simply has a set datastructure designed for fast contains() operations containing all addresses with non-dust amounts (by searching the chain) attached to an iterated key generator would increase your efficiency (still extremely futile and not likely at all to find any collisions). Remember that people actually use the Electrum servers for real transactions they need to send and receive.I am running a special made script through Electrum Python console that generates random Bitcoin addresses and then checks the balance on my local Insight server.
If an address has a totalReceived balance then it adds the address to the wallet using importprivkey(), will also send a pushbullet notification to my phone/laptop.
I still haven't implemented what I will do if I find a balance but I want to sign a message telling people where to contact me if this was their address.
If they sign back then I will refund the balance to an address of their choice as I don't intend on stealing from people.
It's well known that the odds of finding a collision are not favorable but I like challenges so I am destined to find one.
I should actually be counting how many addresses I have search so if I do happen to find one I will have a ratio to share.
I've been thinking about using machine learning to see if I can find a pattern in the key generation but I need to read more and I don't think there is enough storage to get even close to the amount of data I need to find a pattern.
Yeah, I've been searching for a collision for like 3 years now, not a single one.
I would think that Electrum would be far less efficient than a purpose-made application that simply has a set datastructure designed for fast contains() operations containing all addresses with non-dust amounts (by searching the chain) attached to an iterated key generator would increase your efficiency (still extremely futile and not likely at all to find any collisions). Remember that people actually use the Electrum servers for real transactions they need to send and receive. Jump to: