Bitcoin Forum

NaN.

<spam>Armory has this feature</spam>

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.

Google "importprivkey".

Offer a decent bounty and you might be able to attract a developer who'd fix you up. : )

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.

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.

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).

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 2¹⁶⁰ bitcoin address space.

Show your work: Minikey is base58, 30 symbols long.  The first symbol is fixed, so there are 58²⁹ possible strings, which is about 2¹⁷⁰.  Only 1 in 2⁸ are valid, leaving about 162 bits of entropy.

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.

@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

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.

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.

So you want a "kill privacy" checkbox, in other words :)

What exactly is the advantage (if any) of mini keys?

They are shorter.

I think the original motivation was to have a key that could easily be printed under the hologram of a physical coin.

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.

How about a No Forced TX Fee in the Satoshi client!

Hurry before BitCoin dies!