Bitcoin Forum
February 05, 2023, 02:34:26 PM *
News: Latest Bitcoin Core release: 24.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Java deterministic public key generation  (Read 2305 times)
Ploo (OP)
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
December 19, 2012, 06:36:15 PM
 #1

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?
1675607666
Hero Member
*
Offline Offline

Posts: 1675607666

View Profile Personal Message (Offline)

Ignore
1675607666
Reply with quote  #2

1675607666
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1675607666
Hero Member
*
Offline Offline

Posts: 1675607666

View Profile Personal Message (Offline)

Ignore
1675607666
Reply with quote  #2

1675607666
Report to moderator
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1386
Merit: 1132


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
December 19, 2012, 06:42:00 PM
 #2

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

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper or hardware wallets instead.
Ploo (OP)
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
December 19, 2012, 06:49:55 PM
 #3

I used random key generation but did it offline, storing only the addresses on the server.
Ahh, that's not a bad idea and a lot easier. Cheers
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1011


bits of proof


View Profile WWW
December 19, 2012, 07:02:14 PM
 #4

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.
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile WWW
December 19, 2012, 07:07:00 PM
 #5

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

grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1011


bits of proof


View Profile WWW
December 19, 2012, 07:08:39 PM
 #6

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.
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
They set the rules for the private keys. Not the public.
mskwik
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
December 19, 2012, 07:17:30 PM
 #7

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)

grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1011


bits of proof


View Profile WWW
December 19, 2012, 07:48:23 PM
 #8

The link with some order id is really elegant mskwik!
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile WWW
December 19, 2012, 09:08:57 PM
 #9

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.
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
They set the rules for the private keys. Not the public.
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.

grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1011


bits of proof


View Profile WWW
December 19, 2012, 09:14:12 PM
 #10

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.
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
They set the rules for the private keys. Not the public.
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.

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.
Ploo (OP)
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
December 20, 2012, 12:20:11 PM
 #11

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)

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.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1072
Merit: 1148


View Profile WWW
December 20, 2012, 01:05:40 PM
 #12

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.

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

I do Bitcoin stuff.
grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1011


bits of proof


View Profile WWW
December 20, 2012, 02:41:33 PM
 #13

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.

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

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.
mskwik
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
December 20, 2012, 03:12:33 PM
 #14

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)

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.

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.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!