Bitcoin Forum
December 08, 2016, 04:11:58 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   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 59 60 61 ... 155 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 809318 times)
jackjack
Hero Member
*****
Offline Offline

Activity: 882


May Bitcoin be touched by his Noodly Appendage


View Profile
August 02, 2011, 01:46:40 AM
 #201

I just saw the -o flag, I will make pywallet read the output files

On my laptop oclvanitygen crashes (actually it worked once and crashes since then):
Code:
Difficulty: 4553521
clBuildProgram: CL_BUILD_PROGRAM_FAILURE
Build log:
Internal error: Link failed.
Make sure the system setup is correct.
Device: ATI RV730
Vendor: Advanced Micro Devices, Inc.
Driver: CAL 1.4.1385
Profile: FULL_PROFILE
Version: OpenCL 1.0 ATI-Stream-v2.1 (145)
Max compute units: 8
Max workgroup size: 128
Global memory: 268435456
Max allocation: 268435456

I made a commit adding the addrtype flag and sent it
I used it to make the address of both Namecoin Faucet and Testnet Namecoin Faucet: FaucetFbyx6bCZX84Va8YxAxUNMxJfJhRD

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
1481213518
Hero Member
*
Offline Offline

Posts: 1481213518

View Profile Personal Message (Offline)

Ignore
1481213518
Reply with quote  #2

1481213518
Report to moderator
1481213518
Hero Member
*
Offline Offline

Posts: 1481213518

View Profile Personal Message (Offline)

Ignore
1481213518
Reply with quote  #2

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

Posts: 1481213518

View Profile Personal Message (Offline)

Ignore
1481213518
Reply with quote  #2

1481213518
Report to moderator
1481213518
Hero Member
*
Offline Offline

Posts: 1481213518

View Profile Personal Message (Offline)

Ignore
1481213518
Reply with quote  #2

1481213518
Report to moderator
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
August 02, 2011, 06:28:59 AM
 #202

Version 0.16 has been posted.  Changes include:
  • New -X flag to specify numeric key version number, added by jackjack
  • oclvanitygen performance tweaks for Radeon cards
  • New safe mode flag (-S) for oclvanitygen to disable loop unrolling
  • Fix for cached kernel binaries not being loaded correctly on Windows, as reported by jackjack
  • Edit: Mac OS X platform support and makefile, added by dinox

Code:
clBuildProgram: CL_BUILD_PROGRAM_FAILURE
Build log:
Internal error: Link failed.
Make sure the system setup is correct.

This should be fixed, please let me know if it's not.  And thanks for the patches!
jackjack
Hero Member
*****
Offline Offline

Activity: 882


May Bitcoin be touched by his Noodly Appendage


View Profile
August 02, 2011, 11:12:11 AM
 #203

Just to let you know, the error was on Ubuntu, not Windows

I don't have access to my laptop right now, i'll test asap

Also I made a mini script to compile when make doesn't find cl.h
I didn't make a pull request because it's rather dirty but it might be useful for some
It's useful for me because I can compile without modifying oclvanitygen.c: the script modifies oclvanitygen.c, runs make, then modifies oclvanitygen.c back

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile
August 03, 2011, 12:10:29 PM
 #204

  • Edit: Mac OS X platform support and makefile, added by dinox

Seems to work fine - thanks! I built in on my MBP (had to install pcre first) and tried both vanitygen (~100kk/s - 1 thread, ~170kk/s with 2) and oclvanitygen (~140kk/s) although I haven't imported any keys into a wallet and used them for transactions.

I did fail building it towards a newer version of OpenSSL (1.0.0d, installed via macports) though, even though I added both a hardcoded lib path and the correct include paths to the Makefile. I guess it's been too many years since I developed anything in C. (Or did I succeed and it's just the version check prompt that gets its knowledge from elsewhere?)


edit: This.

Code:
$ otool -L vanitygen
vanitygen:
/usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
$ otool -L oclvanitygen
oclvanitygen:
/usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL (compatibility version 1.0.0, current version 1.0.0)

vs

Code:
$ ./vanitygen
WARNING: Built with OpenSSL 0.9.8l 5 Nov 2009
WARNING: Use OpenSSL 1.0.0d+ for best performance
Vanitygen 0.16 (OpenSSL 0.9.8l 5 Nov 2009)
Usage: ./vanitygen [-vqrikNT] [-t <threads>] [-f <filename>|-] [<pattern>...]

I've also tried
Code:
export DYLD_LIBRARY_PATH=/opt/local/lib/
in the event it was a runtime loading problem but it didn't change anything.
RaTTuS
Hero Member
*****
Offline Offline

Activity: 792


Bite me


View Profile
August 03, 2011, 01:30:44 PM
 #205

+1
new Address in my sig  Grin

In the Beginning there was CPU , then GPU , then FPGA then ASIC, what next I hear to ask ....

1RaTTuSEN7jJUDiW1EGogHwtek7g9BiEn
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
August 03, 2011, 02:14:40 PM
 #206

I did fail building it towards a newer version of OpenSSL (1.0.0d, installed via macports) though, even though I added both a hardcoded lib path and the correct include paths to the Makefile. I guess it's been too many years since I developed anything in C. (Or did I succeed and it's just the version check prompt that gets its knowledge from elsewhere?)

First, congrats on getting oclvanitygen to run!  What GPU are you using?  The key rate is probably a lot slower than it could be, but at least the OpenCL compiler isn't crashing.

Regarding the OpenSSL warning, that check is a compile-time one, so switching out the shared library won't stop the warning.  This brings up a potential issue: I thought that between OpenSSL 0.9.8 and 1.0.0, a bunch of changes were made that broke binary compatibility.  To the effect that attempting to build against the header files for 0.9.8 and link with a 1.0.0 library would cause problems.  While it doesn't seem to be crashing for you, it should run at about twice the speed you report.  Anyway, when building from source, you want to use the header files for 1.0.0.

What we really need is a set of pre-built binaries for OS X, with the 3rd party dependencies static-linked.
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile
August 03, 2011, 02:29:56 PM
 #207

First, congrats on getting oclvanitygen to run!  What GPU are you using?  The key rate is probably a lot slower than it could be, but at least the OpenCL compiler isn't crashing.

Regarding the OpenSSL warning, that check is a compile-time one, so switching out the shared library won't stop the warning.  This brings up a potential issue: I thought that between OpenSSL 0.9.8 and 1.0.0, a bunch of changes were made that broke binary compatibility.  To the effect that attempting to build against the header files for 0.9.8 and link with a 1.0.0 library would cause problems.  While it doesn't seem to be crashing for you, it should run at about twice the speed you report.  Anyway, when building from source, you want to use the header files for 1.0.0.

What we really need is a set of pre-built binaries for OS X, with the 3rd party dependencies static-linked.

Yeah I just managed to fix it, posting as a reply to you now instead of yet another edit to my original post Wink It was indeed me just being rusty at writing makefiles. For those who install a newer version of OpenSSL using Macports the Makefile needs to look like this:

Code:
LIBS=-L/opt/local/lib -lpcre -lcrypto -lm -lpthread
INCL=-I/opt/local/include
CFLAGS=-ggdb -O3 -Wall $(INCL)
OBJS=vanitygen.o oclvanitygen.o pattern.o
PROGS=vanitygen
TESTS=

all: $(PROGS)

vanitygen: vanitygen.o pattern.o
        $(CC) $^ -o $@ $(CFLAGS) $(LIBS)

oclvanitygen: oclvanitygen.o pattern.o
        $(CC) $^ -o $@ $(CFLAGS) $(LIBS) -framework OpenCL

clean:
        rm -f $(OBJS) $(PROGS) $(TESTS)

It makes no difference in speed compared to using the right lib and the wrong header files (I think there was a 20% speedup or so between the 0.9.8 and 1.0.0 libs though) - but since I'm on a laptop I have no opinion on what's good or bad.

My MBP is a 2.53GHz C2D with an NVidia GeForce 9400M. This is the output I can get from oclvanitygen by playing around with the parameters and crashing it Wink

Code:
Device: GeForce 9400M
Vendor: NVIDIA
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0
Max compute units: 2
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728


Agree about pre-built binaries from a trusted source for those who don't want to spend a few hours going from no build environment to a working one Wink I like doing it since I was a developer many years ago and want to prove to myself that I haven't forgotten everything. In this case it took way too long to figure out I had put the include path flag at the wrong place ...


RaTTuS
Hero Member
*****
Offline Offline

Activity: 792


Bite me


View Profile
August 03, 2011, 02:35:19 PM
 #208

Oh yeah that was using
oclvanitygen
on a Nvidia280 Card running at about 3.7Mh/s [it took about 3 days]

In the Beginning there was CPU , then GPU , then FPGA then ASIC, what next I hear to ask ....

1RaTTuSEN7jJUDiW1EGogHwtek7g9BiEn
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
August 03, 2011, 03:33:11 PM
 #209

It makes no difference in speed compared to using the right lib and the wrong header files (I think there was a 20% speedup or so between the 0.9.8 and 1.0.0 libs though) - but since I'm on a laptop I have no opinion on what's good or bad.

Interesting, so it is binary compatible on OS X?  Regardless, something still seems off.  You have a smokin' fast CPU.  My older C2D 2.0GHz laptop gets 155 Kkey/s with a single thread.  Maybe OpenSSL isn't being built with the assembly code enabled?

Quote
My MBP is a 2.53GHz C2D with an NVidia GeForce 9400M. This is the output I can get from oclvanitygen by playing around with the parameters and crashing it Wink

Code:
Device: GeForce 9400M
Vendor: NVIDIA
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0
Max compute units: 2
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728


Tell me about the crash!

With a 9400M, the number you got might not be too bad.  It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with.  I'll guess that it has long, uncomfortable display lag?  The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024.  It needs a built-in benchmark, among other things.
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
August 03, 2011, 03:54:12 PM
 #210

+1
new Address in my sig  Grin

Nice!

If the capitalization was intentional (and it looks like it was), that's one of the most complex prefixes that anyone has found to date.
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile
August 03, 2011, 04:05:00 PM
 #211

My older C2D 2.0GHz laptop gets 155 Kkey/s with a single thread.  Maybe OpenSSL isn't being built with the assembly code enabled?

Interesting. I would be surprised if the Apple default Snow Leopard OpenSSL installation (0.9.8) wasn't optimized though - the Macports version (1.0.0d) was after all slightly faster. I didn't verify the compile flags used though.

Maybe we should just wait for other Mac users to report in :) My system could possibly have other issues.

Quote
Tell me about the crash!

Sure. Not really understanding the different options I tried starting it with a really low value for worksize:

Code:
$ ./oclvanitygen -w2 -d0 1pattern
Difficulty: 15318045009
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Kernel execute caused an error that invalidated the queue (0x1004103b0). This may be  due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid command queue

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueNDRangeKernel failed: queue (0x1004103b0) has been invalidated.
clEnqueueNDRange(2): CL_INVALID_COMMAND_QUEUE

(followed by the GPU information I posted above)

Quote
With a 9400M, the number you got might not be too bad.  It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with.  I'll guess that it has long, uncomfortable display lag?  The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024.  It needs a built-in benchmark, among other things.

Really bad lag, yes. Just for reference, for anyone who wants to start fine tuning, I ran (very briefly) all your examples above:

  • -w256 - no obvious difference in speed or responsiveness
  • -g512x256 - ~15% slower, more responsive
  • -b1024 - no obvious difference in speed or responsiveness

RaTTuS
Hero Member
*****
Offline Offline

Activity: 792


Bite me


View Profile
August 03, 2011, 04:25:45 PM
 #212

Nice!

If the capitalization was intentional (and it looks like it was), that's one of the most complex prefixes that anyone has found to date.
it was, though I'm looking for another one that stands out a bit more ... but I'm fairly happy with that one  Cool

In the Beginning there was CPU , then GPU , then FPGA then ASIC, what next I hear to ask ....

1RaTTuSEN7jJUDiW1EGogHwtek7g9BiEn
jackjack
Hero Member
*****
Offline Offline

Activity: 882


May Bitcoin be touched by his Noodly Appendage


View Profile
August 03, 2011, 04:45:45 PM
 #213

Nice!

If the capitalization was intentional (and it looks like it was), that's one of the most complex prefixes that anyone has found to date.
it was, though I'm looking for another one that stands out a bit more ... but I'm fairly happy with that one  Cool
I found Jackjack7eYNdGkbgUUrtKBraSWBUV5DJP too Grin
With such speeds I think an address with 8 fixed characters can be found
Maybe more with vanitygen pools Wink


That might interest some people here: I just finished a web interface for pywallet
Download the last version, run ./pywallet --web and go to localhost:8989

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
dinox
Full Member
***
Offline Offline

Activity: 126


View Profile
August 03, 2011, 11:27:49 PM
 #214

Tell me about the crash!

With a 9400M, the number you got might not be too bad.  It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with.  I'll guess that it has long, uncomfortable display lag?  The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024.  It needs a built-in benchmark, among other things.
Intresting it works on OS X for others, it's probably my MBP which is the problem. I'm throwing 10.7 Lion at it now so let's see if that fixes the problem...

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

Activity: 1078


firstbits.com/1ce5j


View Profile WWW
August 04, 2011, 12:40:26 AM
 #215

Sorry if this was already answered. Is there a way to easily verify that a private/public key pair is valid without having to import it?

Specifically, I want to use vanitygen to generating a few savings account address offline and possibly just write those keys down or print them out. I would prefer to not have to connect my computer to the internet to be safe. But I'm worried about a possible bug in the vanitygen code that may cause it to generate invalid keys. So I don't want to generate an address, put in 1000 bitcoins, then 5 years later find out that the corresponding private key doesn't work!

jackjack
Hero Member
*****
Offline Offline

Activity: 882


May Bitcoin be touched by his Noodly Appendage


View Profile
August 04, 2011, 01:22:44 AM
 #216

Sorry if this was already answered. Is there a way to easily verify that a private/public key pair is valid without having to import it?

Specifically, I want to use vanitygen to generating a few savings account address offline and possibly just write those keys down or print them out. I would prefer to not have to connect my computer to the internet to be safe. But I'm worried about a possible bug in the vanitygen code that may cause it to generate invalid keys. So I don't want to generate an address, put in 1000 bitcoins, then 5 years later find out that the corresponding private key doesn't work!
As vanitygen and pywallet "privkey to pubkey" functions weren't programmed by the same person you can use pywallet (getinfo function) to reassure you

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
coblee
Donator
Legendary
*
Offline Offline

Activity: 1078


firstbits.com/1ce5j


View Profile WWW
August 04, 2011, 02:52:35 AM
 #217

Sorry if this was already answered. Is there a way to easily verify that a private/public key pair is valid without having to import it?

Specifically, I want to use vanitygen to generating a few savings account address offline and possibly just write those keys down or print them out. I would prefer to not have to connect my computer to the internet to be safe. But I'm worried about a possible bug in the vanitygen code that may cause it to generate invalid keys. So I don't want to generate an address, put in 1000 bitcoins, then 5 years later find out that the corresponding private key doesn't work!
As vanitygen and pywallet "privkey to pubkey" functions weren't programmed by the same person you can use pywallet (getinfo function) to reassure you

I only see am importprivkey command. I assume that takes in a private key. That doesn't really confirm that the private key matches the public key. And I won't be able to be sure unless I send some money to the public key.

Would it be easy for you to add a command to let me validate priv/pub key pair without importing anything? I don't care for importing it into a wallet.dat file.

jackjack
Hero Member
*****
Offline Offline

Activity: 882


May Bitcoin be touched by his Noodly Appendage


View Profile
August 04, 2011, 03:00:26 AM
 #218

The --info flag does that, and doesn't import the key, even if the command is importkey:
Code:
./pywallet.py --info --importprivkey yourkey

Or you can use the web interface if you prefer

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
coblee
Donator
Legendary
*
Offline Offline

Activity: 1078


firstbits.com/1ce5j


View Profile WWW
August 04, 2011, 08:05:50 AM
 #219

Thanks, that works.

samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
August 04, 2011, 03:28:15 PM
 #220

Interesting. I would be surprised if the Apple default Snow Leopard OpenSSL installation (0.9.Cool wasn't optimized though - the Macports version (1.0.0d) was after all slightly faster. I didn't verify the compile flags used though.

Maybe we should just wait for other Mac users to report in Smiley My system could possibly have other issues.

There were some posts by another guy who built vanitygen on a Mac Pro, and had the same problem with OpenSSL.  Somehow he built OpenSSL from source by hand, and got the expected performance.  Here's one of his posts documenting what he got from openssl speed with 0.9.8.  Four posts up, he lists the 0.9.8 key rate, and two posts down, he got the key rate to nearly double.

Quote
Code:
$ ./oclvanitygen -w2 -d0 1pattern
Difficulty: 15318045009
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Kernel execute caused an error that invalidated the queue (0x1004103b0). This may be  due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid command queue

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueNDRangeKernel failed: queue (0x1004103b0) has been invalidated.
clEnqueueNDRange(2): CL_INVALID_COMMAND_QUEUE

(followed by the GPU information I posted above)

Clearly you have a talent for finding bugs.  I never even thought to try -w1.  Anyway, to fix this, perhaps all it needs is a set of checks to enforce the NDRange maximum sizes.

Quote
Really bad lag, yes. Just for reference, for anyone who wants to start fine tuning, I ran (very briefly) all your examples above:

  • -w256 - no obvious difference in speed or responsiveness
  • -g512x256 - ~15% slower, more responsive
  • -b1024 - no obvious difference in speed or responsiveness

I guess that's expected.  If you combine -g512x256 and -w256 it might have similar performance with less lag.  To get this right with every GPU would require some sort of auto-tuning after initial configuration.  That will be trickier.
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 59 60 61 ... 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!