Title: Arbitrary address Post by: Monopoly on 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 : 1LuckyG4tMMZf64j6ea7JhCz7sDpk6vdcS ===> for green 1LuckyY9fRzcJre7aou7ZhWVXktxjjBb9S ====> for yellow Title: Re: Arbitrary address Post by: lite on August 23, 2015, 01:28:20 PM Hello , You can generate addresses like that with vanitygen. It will take a lot of time to generate a long custom name or number addresses.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 https://en.bitcoin.it/wiki/Vanitygen Title: Re: Arbitrary address Post by: Muhammed Zakir on August 23, 2015, 04:04:14 PM Speed comparison:
Just to get back to the performance bit of non-ocl vanitygen ( Ran each test for 5 minutes. Relative efficiency is based only on the number of 'found' keys in that timespan.
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:
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):
P.S. If someone else is looking to generate a vanitygen address, see https://bitcointalk.org/index.php?topic=25804.msg12220012#msg12220012. Title: Re: Arbitrary address Post by: notlist3d on August 23, 2015, 05:31:55 PM Speed comparison: Just to get back to the performance bit of non-ocl vanitygen ( Ran each test for 5 minutes. Relative efficiency is based only on the number of 'found' keys in that timespan.
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:
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):
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. Title: Re: Arbitrary address Post by: torry28 on August 23, 2015, 07:11:48 PM Wow this some good stuff , i think i can try it with my new RX 290 :D
Title: Re: Arbitrary address Post by: ranlo on August 23, 2015, 07:20:06 PM Speed comparison: Just to get back to the performance bit of non-ocl vanitygen ( Ran each test for 5 minutes. Relative efficiency is based only on the number of 'found' keys in that timespan.
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:
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):
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. |