Monopoly (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2015, 01:09:47 PM |
|
Hello , how can i make a Arbitrary address ? I saw this site today http://luckyb.it/ . they have some BTC addresses that all of them begin with 1Lucky and for each color , first letter after 1lucky is same as the name that color .. . See these : 1Lucky G4tMMZf64j6ea7JhCz7sDpk6vdcS ===> for green 1Lucky Y9fRzcJre7aou7ZhWVXktxjjBb9S ====> for yellow
|
|
|
|
lite
Legendary
Offline
Activity: 1400
Merit: 1009
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2015, 01:28:20 PM |
|
Hello , how can i make a Arbitrary address ? I saw this site today http://luckyb.it/ . they have some BTC addresses that all of them begin with 1Lucky and for each color , first letter after 1lucky is same as the name that color .. . See these : 1Lucky G4tMMZf64j6ea7JhCz7sDpk6vdcS ===> for green 1Lucky Y9fRzcJre7aou7ZhWVXktxjjBb9S ====> for yellow You can generate addresses like that with vanitygen. It will take a lot of time to generate a long custom name or number addresses. https://en.bitcoin.it/wiki/Vanitygen
|
|
|
|
Muhammed Zakir
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2015, 04:04:14 PM Last edit: December 11, 2017, 12:38:58 PM by Mitchell |
|
Speed comparison: Just to get back to the performance bit of non-ocl vanitygen ( standard v0.22 lifeboat version), some figures (applicable to the i7-4702MQ 2.2GHz config). Ran each test for 5 minutes. Relative efficiency is based only on the number of 'found' keys in that timespan. type | command | generated keys | 'found' keys | % matched | relative efficiency | regex | vanitygen.exe -o file.lst -k -q -F compressed -r .* | 21,262,638 | 82,797 | 0.38940% | 98.72% | standard | vanitygen.exe -o file.lst -k -q -F compressed 1 | 21,534,544 | 83,874 | 0.38949% | 100.00% | input list (1A,1B,..,1a,1b,..,11,12,..) | vanitygen.exe -o file.lst -k -q -F compressed -f input.lst | 21,688,744 | 84,499 | 0.38960% | 100.75% | case insensitive | vanitygen.exe -o file.lst -k -q -F compressed -i 1 | 21,917,217 | 85,410 | 0.38969% | 101.83% | non-compressed | vanitygen.exe -o file.lst -k -q 1 | 22,324,562 | 87,019 | 0.38979% | 103.75% | 64-bit version | vanitygen64.exe -o file.lst -k -q -F compressed 1 | 27,455,567 | 106,980 | 0.38965% | 127.55% | 64-bit, non-compressed | vanitygen64.exe -o file.lst -k -q 1 | 29,042,542 | 113,150 | 0.38960% | 134.90% | 64-bit, non-compressed, four processes | vanitygen64.exe -o file.lst -k -q 1 | 104,220,011 | 406,105 | 0.38966% | 484.18% |
Using compressed keys adds a few percent overhead, so dropping that might be a reasonable idea (remember though that 'compressed keys' are preferred). The 64bit version is quite a bit faster than the 32bit version as well. Combining the two there's a pretty reasonable speed gain. There's maybe a bit more to gain with the case-insensitive option, but I'd have to run much longer tests to see if that's a real gain or just a wee bit of luck in that run. Running four concurrent processes was much faster still - apparently there's a good bit of overhead of code that doesn't/can't be run multithreaded when using such short prefixes. The other thing that stands out is that even though there's a significant number of keys generated, vanitygen only selects a very, very small portion of them as matches - even though every single one of them should be valid. This is primarily why a program that's specifically written for the task would be much better. In fact, given how few vanitygen actually returns here, I wouldn't be surprised if one of the existing python libraries or even javascript (bitaddress.org's bulk generator is slower, but there might be some performance to gain in their implementation as well) would perform much better. It also reminds me of that weird bounty/'rendezvous points' hunt, which - at least for CPU - might be an easier starting point for modification (if not starting from scratch):- A comparison against longer patterns: type | command | generated keys | 'found' keys | % matched | relative efficiency | '1' | vanitygen.exe -o file.lst -k -q -F compressed 1 | 21,534,544 | 83,874 | 0.38949% | 100.00% | '1A' | vanitygen.exe -o file.lst -k -q -F compressed 1A | 16,982,045 | 66,152 | 0.38954% | 78.87% | '1AA' | vanitygen.exe -o file.lst -k -q -F compressed 1AA | 72,843,612 | 49,592 | 0.06808% | 59.13% | '1AAA' | vanitygen.exe -o file.lst -k -q -F compressed 1AAA | 256,016,211 | 3,419 | 0.00134% | 4.08% |
One thing that stands out here is that the percentage that 'matched' is the same for patterns '1' and '1A', which I think shouldn't be the case. The other thing is the total number of keys generated. '1A' having generated fewer than '1', while '1AA' and '1AAA' generated more and far more respectively. tl;dr: vanitygen is weird when used for purposes other than what it was designed for ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
Edit: As the above tables were made using the Lifeboat version of vanitygen, the tables again with vanilla v0.22 (note that there's no 'compressed key' support unless patched in): type | command | generated keys | 'found' keys | % matched | relative efficiency | input list (1A,1B,..,1a,1b,..,11,12,..) | vanitygen.exe -o file.lst -k -f input.txt -q 1 | 21,858,878 | 85,213 | 0.38983% | 98.62% | regex | vanitygen.exe -o file.lst -k -r -q .* | 22,057,282 | 85,920 | 0.38953% | 99.44% | standard | vanitygen.exe -o file.lst -k -q 1 | 22,179,614 | 86,408 | 0.38958% | 100.00% | case insensitive | vanitygen.exe -o file.lst -k -i -q 1 | 22,208,398 | 86,570 | 0.38981% | 100.19% | 64-bit version | vanitygen64.exe -o file.lst -k -q 1 | 29,060,532 | 113,316 | 0.38993% | 131.14% | 64-bit version, four processes | vanitygen64.exe -o file.lst -k -q 1 | 94,486,821 | 368,135 | 0.38962% | 426.04% |
type | command | generated keys | 'found' keys | % matched | relative efficiency | 1 | vanitygen64.exe -o file.lst -k -q 1 | 29,060,532 | 113,316 | 0.38993% | 100.00% | 1A | vanitygen64.exe -o file.lst -k -q 1A | 23,848,310 | 93,430 | 0.39177% | 82.45% | 1AA | vanitygen64.exe -o file.lst -k -q 1AA | 92,005,255 | 63,455 | 0.06897% | 56.00% | 1AAA | vanitygen64.exe -o file.lst -k -q 1AAA | 316,811,630 | 4,000 | 0.00126% | 3.53% |
P.S. If someone else is looking to generate a vanitygen address, see https://bitcointalk.org/index.php?topic=25804.msg12220012#msg12220012.
|
|
|
|
notlist3d
Legendary
Offline
Activity: 1456
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2015, 05:31:55 PM Last edit: December 11, 2017, 12:39:43 PM by Mitchell |
|
Speed comparison: Just to get back to the performance bit of non-ocl vanitygen ( standard v0.22 lifeboat version), some figures (applicable to the i7-4702MQ 2.2GHz config). Ran each test for 5 minutes. Relative efficiency is based only on the number of 'found' keys in that timespan. type | command | generated keys | 'found' keys | % matched | relative efficiency | regex | vanitygen.exe -o file.lst -k -q -F compressed -r .* | 21,262,638 | 82,797 | 0.38940% | 98.72% | standard | vanitygen.exe -o file.lst -k -q -F compressed 1 | 21,534,544 | 83,874 | 0.38949% | 100.00% | input list (1A,1B,..,1a,1b,..,11,12,..) | vanitygen.exe -o file.lst -k -q -F compressed -f input.lst | 21,688,744 | 84,499 | 0.38960% | 100.75% | case insensitive | vanitygen.exe -o file.lst -k -q -F compressed -i 1 | 21,917,217 | 85,410 | 0.38969% | 101.83% | non-compressed | vanitygen.exe -o file.lst -k -q 1 | 22,324,562 | 87,019 | 0.38979% | 103.75% | 64-bit version | vanitygen64.exe -o file.lst -k -q -F compressed 1 | 27,455,567 | 106,980 | 0.38965% | 127.55% | 64-bit, non-compressed | vanitygen64.exe -o file.lst -k -q 1 | 29,042,542 | 113,150 | 0.38960% | 134.90% | 64-bit, non-compressed, four processes | vanitygen64.exe -o file.lst -k -q 1 | 104,220,011 | 406,105 | 0.38966% | 484.18% |
Using compressed keys adds a few percent overhead, so dropping that might be a reasonable idea (remember though that 'compressed keys' are preferred). The 64bit version is quite a bit faster than the 32bit version as well. Combining the two there's a pretty reasonable speed gain. There's maybe a bit more to gain with the case-insensitive option, but I'd have to run much longer tests to see if that's a real gain or just a wee bit of luck in that run. Running four concurrent processes was much faster still - apparently there's a good bit of overhead of code that doesn't/can't be run multithreaded when using such short prefixes. The other thing that stands out is that even though there's a significant number of keys generated, vanitygen only selects a very, very small portion of them as matches - even though every single one of them should be valid. This is primarily why a program that's specifically written for the task would be much better. In fact, given how few vanitygen actually returns here, I wouldn't be surprised if one of the existing python libraries or even javascript (bitaddress.org's bulk generator is slower, but there might be some performance to gain in their implementation as well) would perform much better. It also reminds me of that weird bounty/'rendezvous points' hunt, which - at least for CPU - might be an easier starting point for modification (if not starting from scratch):- A comparison against longer patterns: type | command | generated keys | 'found' keys | % matched | relative efficiency | '1' | vanitygen.exe -o file.lst -k -q -F compressed 1 | 21,534,544 | 83,874 | 0.38949% | 100.00% | '1A' | vanitygen.exe -o file.lst -k -q -F compressed 1A | 16,982,045 | 66,152 | 0.38954% | 78.87% | '1AA' | vanitygen.exe -o file.lst -k -q -F compressed 1AA | 72,843,612 | 49,592 | 0.06808% | 59.13% | '1AAA' | vanitygen.exe -o file.lst -k -q -F compressed 1AAA | 256,016,211 | 3,419 | 0.00134% | 4.08% |
One thing that stands out here is that the percentage that 'matched' is the same for patterns '1' and '1A', which I think shouldn't be the case. The other thing is the total number of keys generated. '1A' having generated fewer than '1', while '1AA' and '1AAA' generated more and far more respectively. tl;dr: vanitygen is weird when used for purposes other than what it was designed for ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
Edit: As the above tables were made using the Lifeboat version of vanitygen, the tables again with vanilla v0.22 (note that there's no 'compressed key' support unless patched in): type | command | generated keys | 'found' keys | % matched | relative efficiency | input list (1A,1B,..,1a,1b,..,11,12,..) | vanitygen.exe -o file.lst -k -f input.txt -q 1 | 21,858,878 | 85,213 | 0.38983% | 98.62% | regex | vanitygen.exe -o file.lst -k -r -q .* | 22,057,282 | 85,920 | 0.38953% | 99.44% | standard | vanitygen.exe -o file.lst -k -q 1 | 22,179,614 | 86,408 | 0.38958% | 100.00% | case insensitive | vanitygen.exe -o file.lst -k -i -q 1 | 22,208,398 | 86,570 | 0.38981% | 100.19% | 64-bit version | vanitygen64.exe -o file.lst -k -q 1 | 29,060,532 | 113,316 | 0.38993% | 131.14% | 64-bit version, four processes | vanitygen64.exe -o file.lst -k -q 1 | 94,486,821 | 368,135 | 0.38962% | 426.04% |
type | command | generated keys | 'found' keys | % matched | relative efficiency | 1 | vanitygen64.exe -o file.lst -k -q 1 | 29,060,532 | 113,316 | 0.38993% | 100.00% | 1A | vanitygen64.exe -o file.lst -k -q 1A | 23,848,310 | 93,430 | 0.39177% | 82.45% | 1AA | vanitygen64.exe -o file.lst -k -q 1AA | 92,005,255 | 63,455 | 0.06897% | 56.00% | 1AAA | vanitygen64.exe -o file.lst -k -q 1AAA | 316,811,630 | 4,000 | 0.00126% | 3.53% |
P.S. If someone else is looking to generate a vanitygen address, see https://bitcointalk.org/index.php?topic=25804.msg12220012#msg12220012. I kept two video cards for this long ago. And two for gaming. Needless to say the gaming got used. But I never used vanity as much as I thought I would. At first it sounded great and I thought was really cool. And it is, but i personally now worry about security more then my address looks. But yes when done right it is a cool thing to have.
|
|
|
|
torry28
Legendary
Offline
Activity: 1680
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2015, 07:11:48 PM |
|
Wow this some good stuff , i think i can try it with my new RX 290 ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
|
ranlo
Legendary
Offline
Activity: 1988
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 23, 2015, 07:20:06 PM Last edit: December 11, 2017, 12:39:39 PM by Mitchell |
|
Speed comparison: Just to get back to the performance bit of non-ocl vanitygen ( standard v0.22 lifeboat version), some figures (applicable to the i7-4702MQ 2.2GHz config). Ran each test for 5 minutes. Relative efficiency is based only on the number of 'found' keys in that timespan. type | command | generated keys | 'found' keys | % matched | relative efficiency | regex | vanitygen.exe -o file.lst -k -q -F compressed -r .* | 21,262,638 | 82,797 | 0.38940% | 98.72% | standard | vanitygen.exe -o file.lst -k -q -F compressed 1 | 21,534,544 | 83,874 | 0.38949% | 100.00% | input list (1A,1B,..,1a,1b,..,11,12,..) | vanitygen.exe -o file.lst -k -q -F compressed -f input.lst | 21,688,744 | 84,499 | 0.38960% | 100.75% | case insensitive | vanitygen.exe -o file.lst -k -q -F compressed -i 1 | 21,917,217 | 85,410 | 0.38969% | 101.83% | non-compressed | vanitygen.exe -o file.lst -k -q 1 | 22,324,562 | 87,019 | 0.38979% | 103.75% | 64-bit version | vanitygen64.exe -o file.lst -k -q -F compressed 1 | 27,455,567 | 106,980 | 0.38965% | 127.55% | 64-bit, non-compressed | vanitygen64.exe -o file.lst -k -q 1 | 29,042,542 | 113,150 | 0.38960% | 134.90% | 64-bit, non-compressed, four processes | vanitygen64.exe -o file.lst -k -q 1 | 104,220,011 | 406,105 | 0.38966% | 484.18% |
Using compressed keys adds a few percent overhead, so dropping that might be a reasonable idea (remember though that 'compressed keys' are preferred). The 64bit version is quite a bit faster than the 32bit version as well. Combining the two there's a pretty reasonable speed gain. There's maybe a bit more to gain with the case-insensitive option, but I'd have to run much longer tests to see if that's a real gain or just a wee bit of luck in that run. Running four concurrent processes was much faster still - apparently there's a good bit of overhead of code that doesn't/can't be run multithreaded when using such short prefixes. The other thing that stands out is that even though there's a significant number of keys generated, vanitygen only selects a very, very small portion of them as matches - even though every single one of them should be valid. This is primarily why a program that's specifically written for the task would be much better. In fact, given how few vanitygen actually returns here, I wouldn't be surprised if one of the existing python libraries or even javascript (bitaddress.org's bulk generator is slower, but there might be some performance to gain in their implementation as well) would perform much better. It also reminds me of that weird bounty/'rendezvous points' hunt, which - at least for CPU - might be an easier starting point for modification (if not starting from scratch):- A comparison against longer patterns: type | command | generated keys | 'found' keys | % matched | relative efficiency | '1' | vanitygen.exe -o file.lst -k -q -F compressed 1 | 21,534,544 | 83,874 | 0.38949% | 100.00% | '1A' | vanitygen.exe -o file.lst -k -q -F compressed 1A | 16,982,045 | 66,152 | 0.38954% | 78.87% | '1AA' | vanitygen.exe -o file.lst -k -q -F compressed 1AA | 72,843,612 | 49,592 | 0.06808% | 59.13% | '1AAA' | vanitygen.exe -o file.lst -k -q -F compressed 1AAA | 256,016,211 | 3,419 | 0.00134% | 4.08% |
One thing that stands out here is that the percentage that 'matched' is the same for patterns '1' and '1A', which I think shouldn't be the case. The other thing is the total number of keys generated. '1A' having generated fewer than '1', while '1AA' and '1AAA' generated more and far more respectively. tl;dr: vanitygen is weird when used for purposes other than what it was designed for ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
Edit: As the above tables were made using the Lifeboat version of vanitygen, the tables again with vanilla v0.22 (note that there's no 'compressed key' support unless patched in): type | command | generated keys | 'found' keys | % matched | relative efficiency | input list (1A,1B,..,1a,1b,..,11,12,..) | vanitygen.exe -o file.lst -k -f input.txt -q 1 | 21,858,878 | 85,213 | 0.38983% | 98.62% | regex | vanitygen.exe -o file.lst -k -r -q .* | 22,057,282 | 85,920 | 0.38953% | 99.44% | standard | vanitygen.exe -o file.lst -k -q 1 | 22,179,614 | 86,408 | 0.38958% | 100.00% | case insensitive | vanitygen.exe -o file.lst -k -i -q 1 | 22,208,398 | 86,570 | 0.38981% | 100.19% | 64-bit version | vanitygen64.exe -o file.lst -k -q 1 | 29,060,532 | 113,316 | 0.38993% | 131.14% | 64-bit version, four processes | vanitygen64.exe -o file.lst -k -q 1 | 94,486,821 | 368,135 | 0.38962% | 426.04% |
type | command | generated keys | 'found' keys | % matched | relative efficiency | 1 | vanitygen64.exe -o file.lst -k -q 1 | 29,060,532 | 113,316 | 0.38993% | 100.00% | 1A | vanitygen64.exe -o file.lst -k -q 1A | 23,848,310 | 93,430 | 0.39177% | 82.45% | 1AA | vanitygen64.exe -o file.lst -k -q 1AA | 92,005,255 | 63,455 | 0.06897% | 56.00% | 1AAA | vanitygen64.exe -o file.lst -k -q 1AAA | 316,811,630 | 4,000 | 0.00126% | 3.53% |
P.S. If someone else is looking to generate a vanitygen address, see https://bitcointalk.org/index.php?topic=25804.msg12220012#msg12220012. I kept two video cards for this long ago. And two for gaming. Needless to say the gaming got used. But I never used vanity as much as I thought I would. At first it sounded great and I thought was really cool. And it is, but i personally now worry about security more then my address looks. But yes when done right it is a cool thing to have. In most cases, I think people should be avoiding the vanity addresses for security. It leads to using Bitcoin in a way that is highly recommended against, since it means reusing addresses. For some sites I think it's fine (for example, if your business revolves around it and you need transparency). For individuals, it really detracts from the anonymity.
|
|
|
|
|