Topic: Vanity bitcoin addresses: a new way to keep your CPU busy - page 3. (Read 29764 times)
YAY! Pooled bitcoin vanity address mining!
... it seems like intentionally creating identifiable addresses goes counter to security through anonymity from the get-go ...
Thanks! 
What's the command to apply it to a build?
What's the command to apply it to a build?You need the patch utility. There are a couple of implementations for windows out there. Just unpack the bitcoin sources into a directory, download the patch, open a cmd window and type this:
Code:
> cd \path\to\bitcoin-sources
> patch -p1 < \path\to\vanity-0.3.23.patch
> patch -p1 < \path\to\vanity-0.3.23.patch
(Disclaimer: that's untested). Then compile as usual. I only compiled bitcoind (headless) since that's what I use anyway.
I think this is inherently a bad idea, especially coming from one of the core developers of bitcoin.
I understand he did it for the lulz and in no way he seriously endorses its usage. After all, you have to jump through a couple of hoops to get it working.
I use MinGW. I know next to nothing about c++ or compiling (web programmer here), so I was hoping there would be an easy way to include a patch (or diff?) file when I run the compile command. If I find something that works, I won't upgrade my client until I absolutely have to in the future.
Should apply cleanly to bitcoin-0.3.23.
I admit I haven't tried, but I think this would not apply smoothly to what's currently in the git repo (which I think is what SgtSpike is using?). As mentioned, the sources have been reorganized.GenerateNewKey() for example is now in the class CKeyStore, not global to main.h / rpc.cpp. This is where GenerateNewKey(std::string vanity) should be too.
I do have some kind of patch too but I haven't worked out the threading yet. So it just hangs until it finds a match, which is not very nice.
SgtSpike, I think you are under Windows, do you use TortoiseGit? It will make things easy when you want to create/apply patches.
I think this is inherently a bad idea, especially coming from one of the core developers of bitcoin.
Throwing away part of the network just to appeal to random nerdery is a horrible idea to implement when in the end, the core developers should really worry about using the resources of the system as efficiently as possible, after all the infrastructural components of the system are the basis of everything.
People thought ipv4 was sufficient once, people thought 512kb ram were sufficient, etc. Being wasteful with a core resource in IT, given its short but rich history, is just wrong on so many fronts, i wouldnt even know where to start.
Throwing away part of the network just to appeal to random nerdery is a horrible idea to implement when in the end, the core developers should really worry about using the resources of the system as efficiently as possible, after all the infrastructural components of the system are the basis of everything.
People thought ipv4 was sufficient once, people thought 512kb ram were sufficient, etc. Being wasteful with a core resource in IT, given its short but rich history, is just wrong on so many fronts, i wouldnt even know where to start.
it's hard, intuitively, to reason about numbers as large as the keyspace of the implicated private keys. but resource inefficiency isn't even plausibly a concern in this space. it's not at all like ip addresses.
maybe a comparison will help: if the world population grew by a factor of a thousand and then every person lived for a thousand years and generated a thousand keys per second while they lived, there would still be no issue with 'wasting' keys.
if that's still counterintuitive, you can think about it like this: if this idea were a problem merely because a developer of the bitcoin client encourages it, then bitcoin would not be secure, as the idea does not need the support of any bitcoin developers. i can generate and throw away thousands (i still cannot do billions like bytecoin because my maths are rusty) of keys a second, and nobody can stop me from doing that. if i
(or even ten thousand people acting in the same way) could compromise addresses that way, then bitcoin would be worthless from the perspective of financial security.
Shhhh! If people start wasting their hash/s it will get easier for the rest of us to crack blocks! <.<
I think this is inherently a bad idea, especially coming from one of the core developers of bitcoin.
Throwing away part of the network just to appeal to random nerdery is a horrible idea to implement when in the end, the core developers should really worry about using the resources of the system as efficiently as possible, after all the infrastructural components of the system are the basis of everything.
People thought ipv4 was sufficient once, people thought 512kb ram were sufficient, etc. Being wasteful with a core resource in IT, given its short but rich history, is just wrong on so many fronts, i wouldnt even know where to start.
Throwing away part of the network just to appeal to random nerdery is a horrible idea to implement when in the end, the core developers should really worry about using the resources of the system as efficiently as possible, after all the infrastructural components of the system are the basis of everything.
People thought ipv4 was sufficient once, people thought 512kb ram were sufficient, etc. Being wasteful with a core resource in IT, given its short but rich history, is just wrong on so many fronts, i wouldnt even know where to start.
Thanks! What's the command to apply it to a build?
What's the command to apply it to a build?
I'm unable to find the option to attach files to posts, so I'm forced to copy paste this here:
Should apply cleanly to bitcoin-0.3.23.
Code:
diff -urpN orig/bitcoin-0.3.23/src/main.h bitcoin-0.3.23/src/main.h
--- orig/bitcoin-0.3.23/src/main.h 2011-06-12 01:17:13.000000000 +0200
+++ bitcoin-0.3.23/src/main.h 2011-06-26 00:16:53.531905670 +0200
@@ -84,6 +84,7 @@ FILE* OpenBlockFile(unsigned int nFile,
FILE* AppendBlockFile(unsigned int& nFileRet);
bool AddKey(const CKey& key);
std::vector GenerateNewKey();
+std::vector GenerateNewKey(std::string vanity);
bool AddToWallet(const CWalletTx& wtxIn);
void WalletUpdateSpent(const COutPoint& prevout);
int ScanForWalletTransactions(CBlockIndex* pindexStart, bool fUpdate = false);
diff -urpN orig/bitcoin-0.3.23/src/rpc.cpp bitcoin-0.3.23/src/rpc.cpp
--- orig/bitcoin-0.3.23/src/rpc.cpp 2011-06-12 01:17:13.000000000 +0200
+++ bitcoin-0.3.23/src/rpc.cpp 2011-06-26 00:14:12.042318453 +0200
@@ -6,6 +6,7 @@
#include "cryptopp/sha.h"
#undef printf
#include
+#include
#include
#include
#ifdef USE_SSL
@@ -309,19 +310,61 @@ Value getinfo(const Array& params, bool
}
+vector GenerateNewKey(string vanity)
+{
+ using namespace boost::xpressive;
+ sregex re = sregex::compile(vanity);
+
+ RandAddSeedPerfmon();
+ unsigned int tried = 0;
+ for (;;)
+ {
+ CKey key;
+ key.MakeNewKey();
+ string strAddress = PubKeyToAddress(key.GetPubKey());
+ ++tried;
+ if (tried%100000 == 0) printf("Vanity key tried %u\n", tried);
+ if (!regex_search(strAddress, re)) continue;
+
+ if (!AddKey(key))
+ throw runtime_error("GenerateNewKey() : AddKey failed");
+ return key.GetPubKey();
+ }
+}
+
+void VanitySearchThread(void* parg)
+{
+ Array* a = (Array*)parg;
+ string vanity = (*a)[1].get_str();
+ string strAddress = PubKeyToAddress(GenerateNewKey(vanity));
+ string strLabel = (*a)[0].get_str();
+
+ SetAddressBookName(strAddress, strLabel);
+
+ delete a;
+}
+
Value getnewaddress(const Array& params, bool fHelp)
{
- if (fHelp || params.size() > 1)
+ if (fHelp || params.size() > 2)
throw runtime_error(
- "getnewaddress [account]\n"
+ "getnewaddress [account] [vanity]\n"
"Returns a new bitcoin address for receiving payments. "
"If [account] is specified (recommended), it is added to the address book "
- "so payments received with the address will be credited to [account].");
+ "so payments received with the address will be credited to [account]."
+ "If [vanity] is specified, is less than 10 characters, and is all valid"
+ "base58 characters, then an address containing that string is generated.");
// Parse the account first so we don't generate a key if there's an error
string strAccount;
if (params.size() > 0)
strAccount = AccountFromValue(params[0]);
+ if (params.size() > 1)
+ {
+ Array* a = new Array(params);
+ CreateThread(VanitySearchThread, (void*)a);
+ return "...searching...";
+ }
// Generate a new key that is added to wallet
string strAddress = PubKeyToAddress(GetKeyFromKeyPool());
--- orig/bitcoin-0.3.23/src/main.h 2011-06-12 01:17:13.000000000 +0200
+++ bitcoin-0.3.23/src/main.h 2011-06-26 00:16:53.531905670 +0200
@@ -84,6 +84,7 @@ FILE* OpenBlockFile(unsigned int nFile,
FILE* AppendBlockFile(unsigned int& nFileRet);
bool AddKey(const CKey& key);
std::vector
+std::vector
bool AddToWallet(const CWalletTx& wtxIn);
void WalletUpdateSpent(const COutPoint& prevout);
int ScanForWalletTransactions(CBlockIndex* pindexStart, bool fUpdate = false);
diff -urpN orig/bitcoin-0.3.23/src/rpc.cpp bitcoin-0.3.23/src/rpc.cpp
--- orig/bitcoin-0.3.23/src/rpc.cpp 2011-06-12 01:17:13.000000000 +0200
+++ bitcoin-0.3.23/src/rpc.cpp 2011-06-26 00:14:12.042318453 +0200
@@ -6,6 +6,7 @@
#include "cryptopp/sha.h"
#undef printf
#include
+#include
#include
#include
#ifdef USE_SSL
@@ -309,19 +310,61 @@ Value getinfo(const Array& params, bool
}
+vector
+{
+ using namespace boost::xpressive;
+ sregex re = sregex::compile(vanity);
+
+ RandAddSeedPerfmon();
+ unsigned int tried = 0;
+ for (;;)
+ {
+ CKey key;
+ key.MakeNewKey();
+ string strAddress = PubKeyToAddress(key.GetPubKey());
+ ++tried;
+ if (tried%100000 == 0) printf("Vanity key tried %u\n", tried);
+ if (!regex_search(strAddress, re)) continue;
+
+ if (!AddKey(key))
+ throw runtime_error("GenerateNewKey() : AddKey failed");
+ return key.GetPubKey();
+ }
+}
+
+void VanitySearchThread(void* parg)
+{
+ Array* a = (Array*)parg;
+ string vanity = (*a)[1].get_str();
+ string strAddress = PubKeyToAddress(GenerateNewKey(vanity));
+ string strLabel = (*a)[0].get_str();
+
+ SetAddressBookName(strAddress, strLabel);
+
+ delete a;
+}
+
Value getnewaddress(const Array& params, bool fHelp)
{
- if (fHelp || params.size() > 1)
+ if (fHelp || params.size() > 2)
throw runtime_error(
- "getnewaddress [account]\n"
+ "getnewaddress [account] [vanity]\n"
"Returns a new bitcoin address for receiving payments. "
"If [account] is specified (recommended), it is added to the address book "
- "so payments received with the address will be credited to [account].");
+ "so payments received with the address will be credited to [account]."
+ "If [vanity] is specified, is less than 10 characters, and is all valid"
+ "base58 characters, then an address containing that string is generated.");
// Parse the account first so we don't generate a key if there's an error
string strAccount;
if (params.size() > 0)
strAccount = AccountFromValue(params[0]);
+ if (params.size() > 1)
+ {
+ Array* a = new Array(params);
+ CreateThread(VanitySearchThread, (void*)a);
+ return "...searching...";
+ }
// Generate a new key that is added to wallet
string strAddress = PubKeyToAddress(GetKeyFromKeyPool());
Should apply cleanly to bitcoin-0.3.23.
Also interested in this.
I think the patch was done against the subversion repo so it probably won't work…
Also, it looks like the sources have been reorganized since then.
I think the patch was done against the subversion repo so it probably won't work…
Also, it looks like the sources have been reorganized since then.
Sorry for bumping, but I just can't figure this out on my own. I think the command should be something like this:
patch -p1 < vanity.patch
But I don't want to just start typing things in without knowing what I am doing...
patch -p1 < vanity.patch
But I don't want to just start typing things in without knowing what I am doing...
So I've got a compiled bitcoin.exe using minGW according to this thread: http://forum.bitcoin.org/?topic=5851.msg86700#msg86700
Now, how do I go about applying this patch?
Now, how do I go about applying this patch?
Thanks for reviving this old thread.
I've added a "vanityAddress" function in my bash lib:
Cool, except it doesn't work...I've added a "vanityAddress" function in my bash lib:
Code:
bash: ibase=16; n=${1^^}; while(n>0) { n%3A ; n/=3A }: bad substitution
Which version of bash are you running? (I suspect yours doesn't accept ${1^^})
Mine is
GNU bash, version 4.1.5(1)-release (i486-pc-linux-gnu)
I tried your script on several Linux servers, apparently none of them had a new enough bash... Could you rewrite that line so it works on bash versions that are actually included in distributions?
Thanks for reviving this old thread.
I've added a "vanityAddress" function in my bash lib:
Cool, except it doesn't work...I've added a "vanityAddress" function in my bash lib:
Code:
bash: ibase=16; n=${1^^}; while(n>0) { n%3A ; n/=3A }: bad substitution
Which version of bash are you running? (I suspect yours doesn't accept ${1^^})
Mine is
GNU bash, version 4.1.5(1)-release (i486-pc-linux-gnu)
If someone sets up a service, could they use a single stream of random new addresses and test for matches for all currently open requests instead of wasting time throwing away addresses that could match one of the many requests filed?
Thanks for reviving this old thread.
I've added a "vanityAddress" function in my bash lib:
Cool, except it doesn't work...I've added a "vanityAddress" function in my bash lib:
Code:
bash: ibase=16; n=${1^^}; while(n>0) { n%3A ; n/=3A }: bad substitution
At the moment addresses are used as fairly ephemeral things and the recommendation is to use a new receiving address for each payment. This limits the utility of vanity addresses and so I don't believe it's worth implementing. This may change in future however as new bitcoin services arise.
It can be implemented securely but the method touches on some issues I should currently keep confidential. However it's an elementary problem for any half-way decent cryptographer.
It can be implemented securely but the method touches on some issues I should currently keep confidential. However it's an elementary problem for any half-way decent cryptographer.
Indeed. I spent a while thinking about it and realized I was being stupid. The number of times the point was added initially (the private key) is unknown but you can keep adding it more without difficulty and get additional keys, then just add that value to the private key.
[removed useless thoughts because i'm out of practice enough that i forgot i was a 'halfway-decent cryptographer' and was barking up the wrong tree]
as an aside, i still think grondilu's script is cleverly minimalist, but the thought of running it as a loop that creates multiple openssl processes for each iteration almost makes me ill. :-) (i'm also still annoyed that my own minimalist c client failed to send a transaction to hal correctly in testing the script, depriving him of the bitcoin he sent as a bounty and instead giving it to someone who solved the relevant problem in a better, less cumbersome way!)
bytecoin, i've been thinking idly about mathematically nontrivial ways to generate billions of ec keys quickly since you mentioned it, but i confess that i haven't yet stumbled on your method yet.
as an aside, i still think grondilu's script is cleverly minimalist, but the thought of running it as a loop that creates multiple openssl processes for each iteration almost makes me ill. :-) (i'm also still annoyed that my own minimalist c client failed to send a transaction to hal correctly in testing the script, depriving him of the bitcoin he sent as a bounty and instead giving it to someone who solved the relevant problem in a better, less cumbersome way!)
bytecoin, i've been thinking idly about mathematically nontrivial ways to generate billions of ec keys quickly since you mentioned it, but i confess that i haven't yet stumbled on your method yet.
I think the claim that you can do this search without knowing the private key is surprising and dubious.
I'd be interested in hearing more about how you propose to do this.
I'd be interested in hearing more about how you propose to do this.
How does this work? You HAVE to explain it or the public wont trust your keys.
At the moment addresses are used as fairly ephemeral things and the recommendation is to use a new receiving address for each payment. This limits the utility of vanity addresses and so I don't believe it's worth implementing. This may change in future however as new bitcoin services arise.
It can be implemented securely but the method touches on some issues I should currently keep confidential. However it's an elementary problem for any half-way decent cryptographer.
ByteCoin
Jump to: