Topic: Satoshi Client Feature Request (Read 2040 times)
Made a Windows GUI for my utility. Link here: https://dl.dropbox.com/u/4365757/minitowif.exe
So you want a "kill privacy" checkbox, in other words 
Yes. It would be an option. Also, the reference client already includes support for "accounts" which are different groups of keys.
I mean, if I only use one address for playing games, like SD, it would make sense to stick to one key. (avoids so called dust.) If that key were separate from all my other keys, then there wouldn't be a privacy issue. Everyone would just see one key betting and losing (or winning). From time to time, it will get "donations" from other keys, but then you can't prove anything.
A better solution for that is coin control.
I wrote a separate utility to convert minikeys to private keys. If anyone wants to try it, I'll post the code here.
Code:
/*
Compile with:
gcc minikey.c -lcrypto -lssl -lgmp -o minikey
*/
#include
#include
#include
#include
/*
returns 0 if not valid, 1 if valid
expects null termination
*/
int is_valid_minikey(char *minikey)
{
char *tmpbuf = (char *)malloc(sizeof(char) * (strlen(minikey) + 2));
unsigned char hash[EVP_MAX_MD_SIZE];
EVP_MD_CTX ctx;
int ret;
strcpy(tmpbuf, minikey);
strcat(tmpbuf, "?");
EVP_DigestInit(&ctx, EVP_sha256());
EVP_DigestUpdate(&ctx, tmpbuf, strlen(tmpbuf));
EVP_DigestFinal(&ctx, hash, &ret);
free(tmpbuf);
// If hash[0] is 0x00, return 1, else 0
if(!hash[0]) return(1);
else return(0);
}
/*
Assumes privkey has enough room
Does not check minikey for validity
Expects minikey to be NULL terminated
Returns length of private key (not NULL terminated)
*/
int minikey_to_private_key(char *minikey, unsigned char *privkey)
{
EVP_MD_CTX ctx;
int ret;
EVP_DigestInit(&ctx, EVP_sha256());
EVP_DigestUpdate(&ctx, minikey, strlen(minikey));
EVP_DigestFinal(&ctx, privkey, &ret);
return(ret);
}
unsigned char base58[] =
{
'1', '2', '3', '4', '5', '6', '7', '8', '9', 'A',
'B', 'C', 'D', 'E', 'F', 'G', 'H', 'J', 'K', 'L',
'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
'X', 'Y', 'Z', 'a', 'b', 'c', 'd', 'e', 'f', 'g',
'h', 'i', 'j', 'k', 'm', 'n', 'o', 'p', 'q', 'r',
's', 't', 'u', 'v', 'w', 'x', 'y', 'z'
};
int private_key_to_wif(unsigned char **wifkey, unsigned char *privkey, int keylen)
{
mpz_t key, tmp;
EVP_MD_CTX ctx;
int i, ret, zeroes;
unsigned char *extkey, hash[EVP_MAX_MD_SIZE];
// 1 for the 0x80, 4 for the csum, one for shit happens
extkey = (unsigned char *)malloc(sizeof(unsigned char) * (keylen + 6));
extkey[0] = 0x80;
memcpy(extkey + 1, privkey, keylen);
// keylen is now the length of ext key
keylen++;
EVP_DigestInit(&ctx, EVP_sha256());
EVP_DigestUpdate(&ctx, extkey, keylen);
EVP_DigestFinal(&ctx, hash, &ret);
EVP_DigestInit(&ctx, EVP_sha256());
EVP_DigestUpdate(&ctx, hash, ret);
EVP_DigestFinal(&ctx, hash, &ret);
// Sanity check
if(ret < 4)
{
free(extkey);
return(-1);
}
memcpy(extkey + keylen, hash, 4);
keylen += 4;
for(i = 0, zeroes = 0; i < keylen; i++)
{
if(!extkey[i]) zeroes++;
else break;
}
mpz_init(key);
mpz_init(tmp);
mpz_import(key, keylen, 1, 1, 0, 0, extkey);
for(i = 0; mpz_cmp_ui(key, 0); i++)
{
ret = mpz_mod_ui(tmp, key, 58);
mpz_tdiv_q_ui(tmp, key, 58);
mpz_set(key, tmp);
extkey[i] = base58[ret];
}
mpz_clear(tmp);
mpz_clear(key);
while(zeroes--)
extkey[i++] = base58[0];
// Note that the i++ adds an extra 1; it must be subtracted.
keylen = i - 1;
// Allocate space for final key
*wifkey = (unsigned char *)malloc(sizeof(unsigned char) * (keylen + 2));
// Copy string in reverse
for(i = 0, ret = keylen; i <= keylen && ret >= 0; i++, ret--)
(*wifkey)[i] = extkey[ret];
// NULL terminate
*wifkey[i] = 0x00;
return(i);
}
int main(int argc, char **argv)
{
unsigned char privkey[EVP_MAX_MD_SIZE], *wifkey;
int i, len;
if(argc < 2)
{
printf("Usage: %s\n", argv[0]);
return(0);
}
if(is_valid_minikey(argv[1]))
{
printf("Minikey is valid.\n");
len = minikey_to_private_key(argv[1], privkey);
len = private_key_to_wif(&wifkey, privkey, len);
printf("Corresponding private key in wallet import format:\n");
for(i = 0; i < len; i++)
printf("%c", wifkey[i]);
}
else
{
printf("Minikey is invalid.");
}
putchar('\n');
return(0);
}
Compile with:
gcc minikey.c -lcrypto -lssl -lgmp -o minikey
*/
#include
#include
#include
#include
/*
returns 0 if not valid, 1 if valid
expects null termination
*/
int is_valid_minikey(char *minikey)
{
char *tmpbuf = (char *)malloc(sizeof(char) * (strlen(minikey) + 2));
unsigned char hash[EVP_MAX_MD_SIZE];
EVP_MD_CTX ctx;
int ret;
strcpy(tmpbuf, minikey);
strcat(tmpbuf, "?");
EVP_DigestInit(&ctx, EVP_sha256());
EVP_DigestUpdate(&ctx, tmpbuf, strlen(tmpbuf));
EVP_DigestFinal(&ctx, hash, &ret);
free(tmpbuf);
// If hash[0] is 0x00, return 1, else 0
if(!hash[0]) return(1);
else return(0);
}
/*
Assumes privkey has enough room
Does not check minikey for validity
Expects minikey to be NULL terminated
Returns length of private key (not NULL terminated)
*/
int minikey_to_private_key(char *minikey, unsigned char *privkey)
{
EVP_MD_CTX ctx;
int ret;
EVP_DigestInit(&ctx, EVP_sha256());
EVP_DigestUpdate(&ctx, minikey, strlen(minikey));
EVP_DigestFinal(&ctx, privkey, &ret);
return(ret);
}
unsigned char base58[] =
{
'1', '2', '3', '4', '5', '6', '7', '8', '9', 'A',
'B', 'C', 'D', 'E', 'F', 'G', 'H', 'J', 'K', 'L',
'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
'X', 'Y', 'Z', 'a', 'b', 'c', 'd', 'e', 'f', 'g',
'h', 'i', 'j', 'k', 'm', 'n', 'o', 'p', 'q', 'r',
's', 't', 'u', 'v', 'w', 'x', 'y', 'z'
};
int private_key_to_wif(unsigned char **wifkey, unsigned char *privkey, int keylen)
{
mpz_t key, tmp;
EVP_MD_CTX ctx;
int i, ret, zeroes;
unsigned char *extkey, hash[EVP_MAX_MD_SIZE];
// 1 for the 0x80, 4 for the csum, one for shit happens
extkey = (unsigned char *)malloc(sizeof(unsigned char) * (keylen + 6));
extkey[0] = 0x80;
memcpy(extkey + 1, privkey, keylen);
// keylen is now the length of ext key
keylen++;
EVP_DigestInit(&ctx, EVP_sha256());
EVP_DigestUpdate(&ctx, extkey, keylen);
EVP_DigestFinal(&ctx, hash, &ret);
EVP_DigestInit(&ctx, EVP_sha256());
EVP_DigestUpdate(&ctx, hash, ret);
EVP_DigestFinal(&ctx, hash, &ret);
// Sanity check
if(ret < 4)
{
free(extkey);
return(-1);
}
memcpy(extkey + keylen, hash, 4);
keylen += 4;
for(i = 0, zeroes = 0; i < keylen; i++)
{
if(!extkey[i]) zeroes++;
else break;
}
mpz_init(key);
mpz_init(tmp);
mpz_import(key, keylen, 1, 1, 0, 0, extkey);
for(i = 0; mpz_cmp_ui(key, 0); i++)
{
ret = mpz_mod_ui(tmp, key, 58);
mpz_tdiv_q_ui(tmp, key, 58);
mpz_set(key, tmp);
extkey[i] = base58[ret];
}
mpz_clear(tmp);
mpz_clear(key);
while(zeroes--)
extkey[i++] = base58[0];
// Note that the i++ adds an extra 1; it must be subtracted.
keylen = i - 1;
// Allocate space for final key
*wifkey = (unsigned char *)malloc(sizeof(unsigned char) * (keylen + 2));
// Copy string in reverse
for(i = 0, ret = keylen; i <= keylen && ret >= 0; i++, ret--)
(*wifkey)[i] = extkey[ret];
// NULL terminate
*wifkey[i] = 0x00;
return(i);
}
int main(int argc, char **argv)
{
unsigned char privkey[EVP_MAX_MD_SIZE], *wifkey;
int i, len;
if(argc < 2)
{
printf("Usage: %s
return(0);
}
if(is_valid_minikey(argv[1]))
{
printf("Minikey is valid.\n");
len = minikey_to_private_key(argv[1], privkey);
len = private_key_to_wif(&wifkey, privkey, len);
printf("Corresponding private key in wallet import format:\n");
for(i = 0; i < len; i++)
printf("%c", wifkey[i]);
}
else
{
printf("Minikey is invalid.");
}
putchar('\n');
return(0);
}
How about a No Forced TX Fee in the Satoshi client!
Hurry before BitCoin dies!
Hurry before BitCoin dies!
So you want a "kill privacy" checkbox, in other words
Yes. It would be an option. Also, the reference client already includes support for "accounts" which are different groups of keys.
I mean, if I only use one address for playing games, like SD, it would make sense to stick to one key. (avoids so called dust.) If that key were separate from all my other keys, then there wouldn't be a privacy issue. Everyone would just see one key betting and losing (or winning). From time to time, it will get "donations" from other keys, but then you can't prove anything.
What exactly is the advantage (if any) of mini keys?
I think the original motivation was to have a key that could easily be printed under the hologram of a physical coin.
What exactly is the advantage (if any) of mini keys?
They are shorter.
What exactly is the advantage (if any) of mini keys?
I have a request, but it seems it's already implemented by coin control. However, I want it in the main Satoshi reference client. To limit key generation and specify usage to already existing keys. Or to make it send change back to the same key (like one key is used in Bitcoin Spinner.)
So I can play those block chain games without generating 500 new keys due to 600 transactions, when it works just as well with just 1 key.
So I can play those block chain games without generating 500 new keys due to 600 transactions, when it works just as well with just 1 key.
So you want a "kill privacy" checkbox, in other words
I have a request, but it seems it's already implemented by coin control. However, I want it in the main Satoshi reference client. To limit key generation and specify usage to already existing keys. Or to make it send change back to the same key (like one key is used in Bitcoin Spinner.)
So I can play those block chain games without generating 500 new keys due to 600 transactions, when it works just as well with just 1 key.
So I can play those block chain games without generating 500 new keys due to 600 transactions, when it works just as well with just 1 key.
This will probably never be included in the reference client. It has seriously bad privacy implications, and is considered to be unsafe for that reason.
I have a request, but it seems it's already implemented by coin control. However, I want it in the main Satoshi reference client. To limit key generation and specify usage to already existing keys. Or to make it send change back to the same key (like one key is used in Bitcoin Spinner.)
So I can play those block chain games without generating 500 new keys due to 600 transactions, when it works just as well with just 1 key.
So I can play those block chain games without generating 500 new keys due to 600 transactions, when it works just as well with just 1 key.
@Wolf0 You should create an official pull-request, there you will most likely get it reviewed and at least a build from our pull-tester .
See: https://github.com/bitcoin/bitcoin/pulls
Dia
.See: https://github.com/bitcoin/bitcoin/pulls
Dia
Did this ever get tested? I'm not a programmer but if you just want someone to install it on their machine and see how/if it works I can probably do that.
The minikey always uses uncompressed public keys.
I am open to being persuaded that it should be changed. I don't presently consider support for compressed public keys a necessity. But if it should be changed, then it should also be updated to use scrypt or something stronger than sha256, and potentially also changed to support some level of encryption like BIP38 (if feasible).
I am open to being persuaded that it should be changed. I don't presently consider support for compressed public keys a necessity. But if it should be changed, then it should also be updated to use scrypt or something stronger than sha256, and potentially also changed to support some level of encryption like BIP38 (if feasible).
Compressed keys provide a modest but real space savings in the block chain. I'm not aware of any reasons why anyone would ever want or need to create a new key without using the compressed form.
As for the hashing algorithm, I don't see any point in making generation slower. The real security is in the ~162 bits of entropy embedded in the string. As long as the transformation isn't leaking much entropy, it is still easier to just brute force search the 2160 bitcoin address space.
Show your work: Minikey is base58, 30 symbols long. The first symbol is fixed, so there are 5829 possible strings, which is about 2170. Only 1 in 28 are valid, leaving about 162 bits of entropy.
The minikey always uses uncompressed public keys.
I am open to being persuaded that it should be changed. I don't presently consider support for compressed public keys a necessity. But if it should be changed, then it should also be updated to use scrypt or something stronger than sha256, and potentially also changed to support some level of encryption like BIP38 (if feasible).
I am open to being persuaded that it should be changed. I don't presently consider support for compressed public keys a necessity. But if it should be changed, then it should also be updated to use scrypt or something stronger than sha256, and potentially also changed to support some level of encryption like BIP38 (if feasible).
The minikey spec doesn't seem to indicate the compression status of the imported key. Since there are multiple implementations already, I presume that they all are doing it either one way or the other. If so, the spec should be updated. Of course, if everyone is assuming that the key is uncompressed, then we need to rework the spec to fix that too.
Once that is taken care of, adding it to the client is easy enough.
Once that is taken care of, adding it to the client is easy enough.
I AM a developer who'd fix me up. :3
Looking for interest, as well. Why do it if I'd be the only one who uses it and it doesn't get accepted into the client?
Looking for interest, as well. Why do it if I'd be the only one who uses it and it doesn't get accepted into the client?
Well hell, I'd be interested. I'm sure I'm not the only one. Put up a thread and get some opinions. There seems to be a surplus of opinion here.
If you need a tester, let me know. I can't code well but I sure can break things.
I stand corrected. I suppose they just hate GUI coding? 
Offer a decent bounty and you might be able to attract a developer who'd fix you up. : )
Would it be hard to allow import of private keys in the minikey format, as well as full private keys?
EDIT: In fact, if you really want it but don't want to use Armory, you could load Armory in offline mode, then import the mini private key, and immediately export it. Armory doesn't save the minified key, only the full key. Then you can import it elsewhere.
Jump to: