PHP script to create private key & public address

[PrintCoins]

Does anyone have an PHP code that can do what is done on this website:

https://www.bitaddress.org

Namely create private keys and associated public addresses?

[Red Emerald]

bitaddress is done all in javascript so that the private keys are never ever seen by the server.  If you moved this logic into PHP, that security is lost.  What are you trying to build?  Your users shouldn't have to trust that you won't steal their private keys, they should know for certain that you can't.

[PrintCoins]

bitaddress is done all in javascript so that the private keys are never ever seen by the server.  If you moved this logic into PHP, that security is lost.  What are you trying to build?  Your users shouldn't have to trust that you won't steal their private keys, they should know for certain that you can't.

I appreciate the red flag waving. It is important to alert developers to issues like that.

I currently have a pdf generator written in php to create bitcoin bills. I use a textarea to paste in addresses from bitaddress to generate the pdf (this is all done on localhost). I would like to just cut out that step and have php generate the addresses and then the pdf. This is so I can package the whole thing up nicely and release it open source.

I also want to create a simple ecommerce library that would create the private and public key on the server and keep the private keys encrypted (to be later downloaded by a site owner and decrypted).

[bitfreak!]

Wouldn't this be useful for merchants who might need to generate a new address for each customer instead of using a large static list of addresses that are generated beforehand? As I understand it, it's possible to import a private key into the bitcoin client or use a service like StrongCoin to make use of a private key.

The merchant could generate a private key and public address server side, tell the customer to send the payment to the public address and store the private key. Another simple AJAX/PHP script would be used to monitor the status of a payment by using the Block Explorer. After reaching a specified amount of confirmations the payment would be accepted.

Then the merchant could import those private keys in one of the ways I specified earlier. What I'm wondering is, will payments sent to these addresses receive confirmations before or after they are imported? I'm fairly sure it should work but I'm not exactly an expert. Anyone know if this would work as I'm proposing?

What I really want is a completely automated system. This would be like a way to carry out automated payment notification and allow customers instant access to products such as digital downloads. If I'm correct this idea could potentially achieve this goal without the need to for a middle man (except of course the Block Explorer).

I think BitcoinNotify (not 100% sure) implemented a similar idea of monitoring the block chain to check for payments to a specified address. The clear advantage of this is that they never gain control over your account, they simply monitor the activity of an account and use the data to power their notification system.

I don't really see why they are needed as a 3rd party when it should be possible to implement a few simple scripts that achieve the same thing. I have the ability to create all these scripts (and I want to), but what I don't really know how to do is use PHP to generate the keys. I looked all over and can't find a PHP script for doing it.

I guess I might try to convert the JavaScript code into PHP unless anyone can offer some help?

[BurtW]

Wouldn't this be useful for merchants who might need to generate a new address for each customer instead of using a large static list of addresses that are generated beforehand? As I understand it, it's possible to import a private key into the bitcoin client or use a service like StrongCoin to make use of a private key.

The merchant could generate a private key and public address server side, then tell the customer to send the payment to the public address and store the private key. Then another simple AJAX/PHP script would be used to monitor the status of a payment by using the Block Explorer. After a specified amount of confirmations have been reached the payment would be confirmed.

I do not understand the difference/advantage of the proposed system.  In one case you pre-generate a list of key pairs and then hand them out to the customers as needed.  When they pay they pay.  You monitor the blockchain to see when they pay.

In the second case you generate the keypairs on the fly and hand them out.  They still pay when they pay and you still monitor the blockchain for payment.  Then you have added the additional step of importing the private key.

BTW importing a private key does not generate a blockchain event.  You could just import the private key before they pay - but then you are just back to case one.

Please clarify your idea.

[bitfreak!]

I do not understand the difference/advantage of the proposed system.  In one case you pre-generate a list of key pairs and then hand them out to the customers as needed.  When they pay they pay.  You monitor the blockchain to see when they pay.

Well I guess you're right about that. You only really need as many addresses as you think will be needed at any one time. I just like to have systems that scale well. It would also seem to me that having a new address for each customer would make it easier to monitor the addresses on the Block Explorer and make it easier to document transactions.

Then you have added the additional step of importing the private key.

Hmm I see what you mean. If one were to use a static list of addresses the addresses could be generated in the normal way. Well I guess you're right then. There's no need to generate a new address for each customer. If I can cut out that part of the equation it will make the problem much simpler.

BTW importing a private key does not generate a blockchain event.

That's what I assumed, but wasn't sure. As I understand it, the network doesn't know about the address until it sends or receives money. I assume that's what makes 'off the grid' accounts possible?

[BurtW]

I think it is a great idea to generate a different address for each customer and that is, in fact, what many merchants do - so you are correct in general.  I think you may just be confused about some of the specifics as to how that is done is all.

The easiest example of off the grid is the physical Bitcoin.   I pay you with physical coins, you pay someone else, they pay someone else, etc.

As long as the physical Bitcoin is not claimed (the private key imported) it can be used over and over for off the grid transactions.

https://www.casascius.com if you are not familiar with physical Bitcoins.

[bitfreak!]

I think it is a great idea to generate a different address for each customer
...
I think you may just be confused about some of the specifics as to how that is done is all.

And the specifics being that it's more efficient to simply use a list of addresses and recycle them to be used with other customers? Or am I totally confusing myself here?

[BurtW]

OK, now we have confused each other!  

Yes, you want to create a key pair for each customer who comes to your web site
Yes, you want to import the private key into your wallet (where ever you keep your wallet)
Yes, you want to monitor the block chain for payment
Yes, once payment is made you can ship your product
Yes, you can either import the private key before or after the payment is made (it does not make any difference)
Yes, your original post basically describes how to do this

Yes, I was confused by your original question and I hope we are on the same page now

[bitfreak!]

Yes, your original post basically describs one "correct" way to do it - generate a keypair for each customer

Ok, so then this would be useful? Is this way more "correct" then using a static list of addresses?

[BurtW]

See my edit, sorry for the confusion.

[bitfreak!]

lol don't worry I'm still confused. It's almost 4 in the morning here.

I'm mainly just wondering if it would be better to use a list or to generate a new keypair for each customer.

I found this page on the wiki, and it's basically what I was talking about:

Solution for receiving bitcoins

1.    Input a list of bitcoin receiving addresses to your database
2.    Give a bitcoin address to a potential customer
3.    Have the customer tell you when they have sent the coins and have at least 1 confirmation (you can choose a number higher than 1 if you are worried about double-spending)
4.    Check blockexplorer to see if they sent the right amount (i.e. http://blockexplorer.com/q/getreceivedbyaddress/19hMEAaRMbEhfSkeU4GT8mgSuyR4t4M6TH/1) - the /1 is the number of confirmations you require
5.    Give them what they paid for
6.    After a reasonable amount of time has passed, you can re-use the address for another customer

You could avoid having a list of addresses and reusing them if one of the wallet services someday lets you get a new address via API call, but this will work for now.

It seems having a new address for each customer is desirable, but wouldn't it be better to simply get new addresses via this method we're talking about rather than a 3rd party as the wiki suggests?

Also, it seems to me like the getreceivedbyaddress function returns the total amount sent to a specified address, so if you were re-using addresses wouldn't that mean you'd need to keep track of how much each address has received?

[BurtW]

It seems having a new address for each customer is desirable, but wouldn't it be better to simply get new addresses via this method we're talking about rather than a 3rd party as the wiki suggests?

Yes, generating your own seems the best way to go.  Generate a key pair, give the public key address to the customer and import the private key into your wallet.

Also, it seems to me like the getreceivedbyaddress function returns the total amount sent to a specified address, so if you were re-using addresses wouldn't that mean you'd need to keep track of how much each address has received?

I think they were expecting you to move the BTC off the address each time so you can start back at zero for each re-use of the address.  This would also work.

[PrintCoins]

I created a fork of pywallet which will import a text file of private keys into your wallet.
https://github.com/RobKohr/pywallet

The webserver could generate the pubs/privs and when you log in as an admin, you could download that private key list and import into your wallet. I would recommend that you delete the private keys on the webserver after you import them into your wallet.

[bitfreak!]

I think they were expecting you to move the BTC off the address each time so you can start back at zero for each re-use of the address. This would also work.

Wouldn't that involve a transaction fee for every single address that you need to empty?

[BurtW]

Good point in favor of the "give every customer a new address" method.

[PrintCoins]

Good point in favor of the "give every customer a new address" method.

I think reusing addresses is a bad idea and should be discouraged. Creating new addresses is free, and it makes it so their is no confusion as to who paid and who didn't. I basically use addresses as "order numbers" so that it is easy to relate an order to a payment.

[Red Emerald]

It might be easier to hook into bitcoind's rpc for creating new addresses rather than rewriting client code in PHP. This means your webserver would need access to a bitcoind, but not necessarily one that is even connected to the network.  It could just be for address generation.  You could export the keys generated and set them up to be swept by a different bitcoind that can't be compromised by your webserver.

[PrintCoins]

It might be easier to hook into bitcoind's rpc for creating new addresses rather than rewriting client code in PHP. This means your webserver would need access to a bitcoind, but not necessarily one that is even connected to the network.  It could just be for address generation.  You could export the keys generated and set them up to be swept by a different bitcoind that can't be compromised by your webserver.

That would be another service to run on a webserver which is a bit heavy duty. Also, getting all the private keys out of it would require using pywallet to export them, and then reimport them into your desktop wallet.

I created a php library that uses "bitcoin-off-the-grid" (BOTG) (source: https://bitcointalk.org/index.php?topic=23081.20) which is a bash script.

Here is the library:
https://github.com/RobKohr/PHP-Bitcoin-Address-Creator

I trimmed out a bunch of stuff from BOTG to make it more script friendly, and wrapped a php exec call to it. It seems to work pretty well.

[Red Emerald]

It might be easier to hook into bitcoind's rpc for creating new addresses rather than rewriting client code in PHP. This means your webserver would need access to a bitcoind, but not necessarily one that is even connected to the network.  It could just be for address generation.  You could export the keys generated and set them up to be swept by a different bitcoind that can't be compromised by your webserver.

That would be another service to run on a webserver which is a bit heavy duty. Also, getting all the private keys out of it would require using pywallet to export them, and then reimport them into your desktop wallet.

I created a php library that uses "bitcoin-off-the-grid" (BOTG) (source: https://bitcointalk.org/index.php?topic=23081.20) which is a bash script.

Here is the library:
https://github.com/RobKohr/PHP-Bitcoin-Address-Creator

I trimmed out a bunch of stuff from BOTG to make it more script friendly, and wrapped a php exec call to it. It seems to work pretty well.

Bitcoin 0.6 has the import/export built in so that won't be a problem much longer.  Using botg is a good idea, too.