Bitcoin Forum
December 11, 2016, 04:32:01 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 ... 155 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 810003 times)
dserrano5
Legendary
*
Offline Offline

Activity: 1638



View Profile
July 15, 2011, 02:55:44 PM
 #141

Oh my goodness, and I thought my 45 vanity addresses were far too many...

1481430721
Hero Member
*
Offline Offline

Posts: 1481430721

View Profile Personal Message (Offline)

Ignore
1481430721
Reply with quote  #2

1481430721
Report to moderator
1481430721
Hero Member
*
Offline Offline

Posts: 1481430721

View Profile Personal Message (Offline)

Ignore
1481430721
Reply with quote  #2

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

Posts: 1481430721

View Profile Personal Message (Offline)

Ignore
1481430721
Reply with quote  #2

1481430721
Report to moderator
Yeti
Member
**
Offline Offline

Activity: 112

Firstbits: 1yetiax


View Profile
July 15, 2011, 04:43:33 PM
 #142

This goes way back to the beginning of the month when there was no vanitygen. http://blockexplorer.com/address/1HnNPy6wtM8pG9TpF1dapvuLTPpdHwiYek

Somebody had figured this out earlier, activated them in Firstbits with tx of 1 Satoshi each, not released the code and now keeps all the addresses to sell them later (although that remains to be seen if people would buy private keys from somebody).

That's why I can't be 1yeti and that's why we can't have nice things!

1YetiaXeuRzX9QJoQNUW84oX2EiXnHgp3 or http://payb.tc/yeti

Since Bitcoin Randomizer is dead, join the Bitcoin Pyramid (referrer id #203)! Be quick, be on top! Instant payout as soon as one of your referrals deposits!
BTCurious
Hero Member
*****
Offline Offline

Activity: 714


^SEM img of Si wafer edge, scanned 2012-3-12.


View Profile
July 16, 2011, 10:25:08 AM
 #143

I haven't got every thing about ECC clear yet, but what I have understood you can do

Public_key = some_int*base_EC_point
Priv_key = some_int

Then

New_pub_key = Public_key + another_int*base_EC_point
New_priv_key = priv_key + another_int

Now if you set another_int=1 you only have to do one add each iteration, and if there is a match another add to get the private key. This should speed up the calc a lot if my maths is correct.
You're sort of correct, but samr7 has been doing this since his earliest released version. It's one of the reasons his tool is rather fast Smiley

I've corrected some stuff in green. The base_ec_point is a parameter that is known to all parties; it's defined in the protocol/cryptology parameters. It's parameter G.

dinox
Full Member
***
Offline Offline

Activity: 126


View Profile
July 16, 2011, 11:29:25 PM
 #144

I haven't got every thing about ECC clear yet, but what I have understood you can do

Public_key = some_int*base_EC_point
Priv_key = some_int

Then

New_pub_key = Public_key + another_int*base_EC_point
New_priv_key = priv_key + another_int

Now if you set another_int=1 you only have to do one add each iteration, and if there is a match another add to get the private key. This should speed up the calc a lot if my maths is correct.
You're sort of correct, but samr7 has been doing this since his earliest released version. It's one of the reasons his tool is rather fast Smiley

I've corrected some stuff in green. The base_ec_point is a parameter that is known to all parties; it's defined in the protocol/cryptology parameters. It's parameter G.
Thanks!

I've implemented this in python with hashlib as only dependency and yes, it's indeed working. I want to translate this to a opencl kernel but I figured out we have a core problem to solve first.

The problem is that address generating is pipelined, i.e. you cant multi-thread the problem since next worker need the work of last worker to start computing. Let's say you have some workers and a base public key. Then worker 1 does public key += base_ec_point and worker 2 has to wait for this until it can do public key += base_ec_point and so on... How do you solve this?

blockchain.info/fb/1dinox - 1Dinox3mFw8yykpAZXFGEKeH4VX1Mzbcxe
Active trader on #bitcoin-otc - See here - Proof that my nick is dinox here
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
July 17, 2011, 12:02:53 AM
 #145

I've implemented this in python with hashlib as only dependency and yes, it's indeed working. I want to translate this to a opencl kernel but I figured out we have a core problem to solve first.

The problem is that address generating is pipelined, i.e. you cant multi-thread the problem since next worker need the work of last worker to start computing. Let's say you have some workers and a base public key. Then worker 1 does public key += base_ec_point and worker 2 has to wait for this until it can do public key += base_ec_point and so on... How do you solve this?

The trick is to remember that: pub_key + (N+M)*base_ec_point == pub_key + N*base_ec_point + M*base_ec_point

Parallelism is possible by computing:
  • A row of sequential EC points (pub_key + k*base_ec_point) for k=0,1,2,...N
  • A column of EC points i*N*base_ec_point for i=0,1,2,...
..and then add each possible combination of row and column member in parallel.

The trickiest part of implementing this in OpenCL is the bigint arithmetic.  I'm actually testing a kernel right now.  It's monstrous, easily dwarfing the various miner kernels in compiled size, and only moderately fast -- on my GTX 285, it can produce ~1.1Mkey/sec.
cbuchner1
Hero Member
*****
Offline Offline

Activity: 742


View Profile
July 17, 2011, 10:53:53 AM
 #146

Hmm, these nVidia GPUs might not be particularly fast at those jobs. Last time I imlemented a 1024 bit (non modular) bignum multiplication on nVidia GTX 260 using CUDA, it turned out to be only as fast as two CPU cores combined.

One possible avenue to expore, would be using Intel AVX instructions ("Sandy bridge"). In principle these would allow to perform eight modular multiplications or additions in parallel. However you really need some up to date Intel silicon and an OpenSSL library with support for AVX.

samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
July 17, 2011, 11:42:07 PM
 #147

Version 0.13 is up.  The only major change is to display hints when impossible address prefixes are entered, suggested by a user via email.  It's not worth downloading if you already have 0.12.

Under the hood, the source tree has been reorganized a bit, and a new OpenCL version, oclvanitygen, is now present.

Regarding the current state of oclvanitygen:
  • It isn't built by default, you need to run: make oclvanitygen.  Build it on Windows at your own peril.
  • It isn't optimized at all.  Specifically, it can't outperform the CPU with AMD hardware, and while it is faster with nVidia hardware, the profiler claims 25% occupancy.
TiagoTiago
Hero Member
*****
Offline Offline

Activity: 616


Firstbits.com/1fg4i                :Ƀ


View Profile
July 18, 2011, 12:04:17 AM
 #148

How risky do you guys consider it to be for me to download the executable form the first post and run it on my machine?

(I dont always get new reply notifications, pls send a pm when you think it has happened)

Wanna gimme some BTC for any or no reason? 1FmvtS66LFh6ycrXDwKRQTexGJw4UWiqDX Smiley

The more you believe in Bitcoin, and the more you show you do to other people, the faster the real value will soar!

Do you like mmmBananas?!
TeraPool
Jr. Member
*
Offline Offline

Activity: 42


View Profile
July 18, 2011, 01:57:24 AM
 #149

How risky do you guys consider it to be for me to download the executable form the first post and run it on my machine?

I hope it's not too risky Wink

I have been running it on my windows machine for a few days with no complaints.

SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 18, 2011, 03:11:30 AM
 #150

How risky do you guys consider it to be for me to download the executable form the first post and run it on my machine?
Considering the work that samr7 has put into optimizing the code (and seeing those optimizations actually help), I would say zero risk.
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
July 18, 2011, 03:19:40 AM
 #151

How risky do you guys consider it to be for me to download the executable form the first post and run it on my machine?
It is trivial for someone to make a slightly-modified executable that appeared in all respects to work correctly but such that given the account name, they could deduce the private key. That said, I think it's highly unlikely that anyone has bothered.

You can actually check for such a thing. Unless someone specifically thought that someone would test for this, the most obvious way to do that would leave a tell. Create a specific vanity key, say "1Dag". Then create that same vanity key again. And then do it one more time. If any of your keys are the same, you have a sabotaged binary. If not, then you either don't have a sabotaged binary or the sabotage is very subtle. (The obvious way to sabotage it would be to use a defined pattern of keys rather than a random one.)

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 18, 2011, 03:24:39 AM
 #152

How risky do you guys consider it to be for me to download the executable form the first post and run it on my machine?
It is trivial for someone to make a slightly-modified executable that appeared in all respects to work correctly but such that given the account name, they could deduce the private key. That said, I think it's highly unlikely that anyone has bothered.

You can actually check for such a thing. Unless someone specifically thought that someone would test for this, the most obvious way to do that would leave a tell. Create a specific vanity key, say "1Dag". Then create that same vanity key again. And then do it one more time. If any of your keys are the same, you have a sabotaged binary. If not, then you either don't have a sabotaged binary or the sabotage is very subtle. (The obvious way to sabotage it would be to use a defined pattern of keys rather than a random one.)
Oh, I don't doubt there's ways to subtly hide all sorts of malicious activities.  I'm just talking from the standpoint of samr7's reputation here.  I trust him, based on the work that he has released, the manner in which he released it, and the respect with which he conducts himself on this forum.  Perhaps I am too trusting of people, but I get no indication of a bad apple.  And since he's the one releasing the source code and builds, I also trust those builds.
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
July 19, 2011, 04:41:34 AM
 #153

To report on the current state of oclvanitygen, I've made some progress optimizing it for various GPUs.  So far it has been depending on the CPU to compare addresses with prefix targets.  The performance with higher-end GPUs has progressed to the point that the CPU has become the bottleneck, and the prefix checking will certainly need to be offloaded next.  And don't even think about using regular expressions!

Obligatory performance numbers, searching for a single case-sensitive prefix:

  • nVidia GTX 285 + C2D 6600: 3.5 Mkey/s, 100% CPU / 90% GPU
  • AMD 5830 + Sempron 140: 5.5 Mkey/s, 100% CPU / 60% GPU

I found a really cool address with this thing.  As it would turn out though, somebody already claimed it on 1stbits two days ago. Tongue  Regardless, 7- and 8-character prefixes are no longer out of reach for a single gaming system.
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 19, 2011, 04:58:56 AM
 #154

Nice!  Good to hear of the progress on using video cards for the search...  definitely a vast improvement over using the CPU.  Maybe I'll finally find 1SgtSpike!
opticbit
Hero Member
*****
Offline Offline

Activity: 677


PGP: 6EBEBCE1E0507C38


View Profile WWW
July 19, 2011, 06:02:42 AM
 #155

got this without useing vanity gen

1YCqF14gcummp4Gj4GGdqXFLn7qAssvju

any fighter pilots making a movie?

Set up the same thing..
http://bit.ly/btcrefs
Get more bitcoins.
cbuchner1
Hero Member
*****
Offline Offline

Activity: 742


View Profile
July 19, 2011, 10:27:52 AM
 #156

  • nVidia GTX 285 + C2D 6600: 3.5 Mkey/s, 100% CPU / 90% GPU
  • AMD 5830 + Sempron 140: 5.5 Mkey/s, 100% CPU / 60% GPU


Thank you for your dedicated hard work. Benchmarked this on Ubuntu 9.04 with latest release-version nVidia driver for 32bit Linux.

  • nVidia GTS 250 + Core i5 750 @2.67 GHz: 1.54 Mkey/s, 110% CPU / how to measure GPU?

The GTS 250 beats my core i5 by a factor of 3.
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
July 19, 2011, 12:37:42 PM
 #157

  • nVidia GTS 250 + Core i5 750 @2.67 GHz: 1.54 Mkey/s, 110% CPU / how to measure GPU?

The GTS 250 beats my core i5 by a factor of 3.

That's awesome!!

The GPU idle statistic is a mess right now, but to get it, use "-v".
dinox
Full Member
***
Offline Offline

Activity: 126


View Profile
July 19, 2011, 04:20:50 PM
 #158

  • nVidia GTS 250 + Core i5 750 @2.67 GHz: 1.54 Mkey/s, 110% CPU / how to measure GPU?

The GTS 250 beats my core i5 by a factor of 3.

That's awesome!!

The GPU idle statistic is a mess right now, but to get it, use "-v".
I tried to get it working on OSX, I was able to compile it after some changes but I get "segmentation fault" when compiling the kernel... It does work when I choose my SB CPU as device though

blockchain.info/fb/1dinox - 1Dinox3mFw8yykpAZXFGEKeH4VX1Mzbcxe
Active trader on #bitcoin-otc - See here - Proof that my nick is dinox here
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
July 19, 2011, 04:50:34 PM
 #159

I tried to get it working on OSX, I was able to compile it after some changes but I get "segmentation fault" when compiling the kernel... It does work when I choose my SB CPU as device though

Oh my, this could be an OpenCL implementation bug.  Which type of card is this?  Doesn't Apple have their own implementation, or how does that work on OS X?

You could grab the openclcc standalone compiler from http://code.google.com/p/openclcc/ and use it to test-compile the kernel.  At the very least, this program might not segfault, which would confirm that oclvanitygen is doing something wrong.  You could also run oclvanitygen under gdb and collect a stack trace, which could be helpful either way.

There will definitely need to be a Makefile.OSX in the near future, or maybe cmake.
dinox
Full Member
***
Offline Offline

Activity: 126


View Profile
July 19, 2011, 09:34:59 PM
 #160

I tried to get it working on OSX, I was able to compile it after some changes but I get "segmentation fault" when compiling the kernel... It does work when I choose my SB CPU as device though

Oh my, this could be an OpenCL implementation bug.  Which type of card is this?  Doesn't Apple have their own implementation, or how does that work on OS X?

You could grab the openclcc standalone compiler from http://code.google.com/p/openclcc/ and use it to test-compile the kernel.  At the very least, this program might not segfault, which would confirm that oclvanitygen is doing something wrong.  You could also run oclvanitygen under gdb and collect a stack trace, which could be helpful either way.

There will definitely need to be a Makefile.OSX in the near future, or maybe cmake.
Ok, openclcc was supernasty to build on OSX, with no support or instructions avaliable. At last I got it to build, and ran into this failure when trying to compile calc_addrs.cl
Code:
File: calc_addrs.cl
- Checking... Error
---------------
OpenCLcc output
---------------
OpenCL Error: -43
The card I am using is an ATI radeon 6490M.

Btw, I have a Makefile.osx together with some #ifdef in oclvanitygen.c, I will push it as soon everything is working.

blockchain.info/fb/1dinox - 1Dinox3mFw8yykpAZXFGEKeH4VX1Mzbcxe
Active trader on #bitcoin-otc - See here - Proof that my nick is dinox here
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 ... 155 »
  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!