Topic: PHP script to create private key & public address - page 2. (Read 5375 times)

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?

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.

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.

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.

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?

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.

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?

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

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.

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?