Arbitrary address

[Monopoly]

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 :


1LuckyG4tMMZf64j6ea7JhCz7sDpk6vdcS ===> for green

1LuckyY9fRzcJre7aou7ZhWVXktxjjBb9S ====> for yellow

[1714018130]

1714018130

[lite]

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 :


1LuckyG4tMMZf64j6ea7JhCz7sDpk6vdcS ===> for green

1LuckyY9fRzcJre7aou7ZhWVXktxjjBb9S ====> 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]

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

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]

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

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]

Wow this some good stuff , i think i can try it with my new RX 290

[ranlo]

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

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.