|
Ploo (OP)
|
 |
December 19, 2012, 06:36:15 PM |
|
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?
|
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
 Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
December 19, 2012, 06:42:00 PM |
|
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)
|
|
December 19, 2012, 06:49:55 PM |
|
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
|
|
December 19, 2012, 07:02:14 PM |
|
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
|
|
December 19, 2012, 07:07:00 PM |
|
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
|
|
December 19, 2012, 07:08:39 PM |
|
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_0032They set the rules for the private keys. Not the public. |
|
|
|
|
|
mskwik
|
|
December 19, 2012, 07:17:30 PM |
|
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
|
|
December 19, 2012, 07:48:23 PM |
|
The link with some order id is really elegant mskwik!
|
|
|
|
|
|
Red Emerald
|
|
December 19, 2012, 09:08:57 PM |
|
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_0032They 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
|
|
December 19, 2012, 09:14:12 PM |
|
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_0032They 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)
|
|
December 20, 2012, 12:20:11 PM |
|
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
|
|
December 20, 2012, 01:05:40 PM |
|
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
|
|
December 20, 2012, 02:41:33 PM |
|
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
|
|
December 20, 2012, 03:12:33 PM |
|
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. |
|
|
|
|
