Topic: Java deterministic public key generation (Read 2330 times)

This is all EC math, so multiplying a public key by a number is somewhat more complicated than just simple math, but nothing that couldn't be implemented in any language of choice fairly quickly without depending on more than a bignum library.  For the private key it is just simple math (with bignums), the result is modulo n (the constant for the bitcoin EC curve) so it is always less than 256 bits.

Yes, you can come up with further public keys and you need to have only one private key and that does not need to be on the server.
I learned several ways to do so in this thread.

Not sure I understand you correctly, but type-2 deterministic key derivation (like BIP32, Electrum and Armory do) allows derivation of just the public key when you only have a root public key (without any private key at all).

What happens when the product of the multiplication exceeds the max value of 256 bits?

This is a great post though, thanks. I wasn't aware of what exactly about EC keys allowed public only key derivation.

My poorly formulated point was that for deterministic wallet you start with a key pair including the private one. Derivation of further keys both public and private is possible, but not just public without having at least one private in the first place.

I'm not really sure what you are trying to say.

With Armory it works like this:

Wallet on an offline computer and a master private key, master public key and a chain code.
Wallet on an online computer with the master public key and the chain code.  This computer can generate an essentially infinite chain of public keys that correspond to the chain of private keys on the offline computer.  The chained private key need not be created before the chained public key.

This does depend on the master private key being generated first.  Is that what you are referring to? The OP didn't say anything about wanting an algorithm for that.

The link with some order id is really elegant mskwik!

It's also fairly simple to generate one private key p which you keep safe offline and its associated public key P which is on the webserver.  You can then get unique payment addresses by generating some 256 bit x (Usually from a hash of the cart transaction id or such, doesn't need to be secret) and multiplying it by P.

Offline you can then get the private key by multiplying p by that same x (which your customer can give you the data to generate even if your web server gets nuked or such)

They set the rules for the private keys. Not the public.

False.  There are multiple deterministic wallet implementations and they do not break the EC algorithm, they use it. Armory and electrum both have deterministic wallets and the Satoshi client is working on one, too.

https://en.bitcoin.it/wiki/BIP_0032

A public key is valid (and useful) if private key exists (and known) to it.

If you'd find an algorithm creating a chain of public keys without first creating the private keys, that would mean you broke the EC algorithm and Bitcoin with it.

The bitsofproof supenode (pure Java) does not contain and will not contain wallet code or key generation. Even signing of transactions is extracted into the API code linked with the client while client connects to server via Java RMI over a two way authenticated and encrypted SSL socket.

It should be easy to extend the communication to fetch newly generated batches of public keys while the private keys remain on your laptop you control the server from.

Build on it.

Ahh, that's not a bad idea and a lot easier. Cheers

I used random key generation but did it offline, storing only the addresses on the server.

I'm not really sure what I'm asking for here so I'll just word my thoughts and then hopefully I can get some ideas back.

I'm looking to work on a site that will handle bitcoin that will obviously need to receive bitcoins from users. No bitcoins will be sent automatically so no private keys have to be known.

The first thought that came into my head is to use armory's specification of bitcoin wallets. I could generate a wallet on an offline machine and then derive the public-only seed. Then I'd use this seed on the website server to get public keys at a specific index of the key chain, for example based on the user's ID.

What I'm wondering is - what approach do other bitcoin services take to this issue? Do they also use some form of deterministic key creation. As far as I know generating an address on the spot completely from random implies that you're also having to store the private key on the same site. I don't need to do this so I don't see why take the risk.

I'll probably be using AppEngine with Java. Is there any java deterministic wallet APIs? How challenging would it be to write one based on armory's python code?

More importantly - what is the logic behind creating a chain of private keys from a seed but also being able to generate a chain of public keys from the public part of the seed?