Topic: Developing Bitcoin on Sites (Read 985 times)
I'm just storing all the bitcoin addresses 'offline' in simple format and process the transactions after the fact when enough transactions have accumulated to make it worth the tx fee.
as well as a QT wallet that I installed the other day and is STILL doing the original sync. 
0.8 will largely solve this. It should sync within a few hours.
Right now the biggest problem with easily integrating bitcoind into an ecommerce website is the lack of transactional info and callbacks.
AFAIK the best practice currently is:
1) Use -blocknotify=
2) Use RPC getblock on the block hash you got from blocknotify.
3) Iterate through the tx array returned with the RPC call gettransaction and store the txid of transactions to your addresses along with the amount on your database. If you require X confirmations you will need to poll the txids until they reach that point. Make sure that you aren't processing the same txid's amount twice.
4) You will probably need to find a way to replay blocks that you have missed (app server downtime?)
Alternatively you can poll the server with getreceivedbyaddress for every address you're watching, which isn't very scalable. Although it can work with a simple limitation: require the user to perform an action whenever they are about to send you a payment. This way you can poll that address with minconf=0 every 10 seconds to get the unconfirmed transaction, then switch to polling minconf=X every 10 minutes until you get X confirmations at which point you stop polling for that address.
In PHP you'll probably need to have a pool of worker processes (php-fpm) to perform that kind of task. Don't daemonize PHP unless you know what you're doing.
There must be a better way to do this? I was dabbling with the idea of getting a payment forwarded to an offline vault as soon as it is received. Then getting some sort of 6 confirmation notification to update the relevant fields in my database? I'm still unsure about the exact process I would go about this though.
as well as a QT wallet that I installed the other day and is STILL doing the original sync.
0.8 will largely solve this. It should sync within a few hours.
Right now the biggest problem with easily integrating bitcoind into an ecommerce website is the lack of transactional info and callbacks.
AFAIK the best practice currently is:
1) Use -blocknotify=
2) Use RPC getblock on the block hash you got from blocknotify.
3) Iterate through the tx array returned with the RPC call gettransaction and store the txid of transactions to your addresses along with the amount on your database. If you require X confirmations you will need to poll the txids until they reach that point. Make sure that you aren't processing the same txid's amount twice.
4) You will probably need to find a way to replay blocks that you have missed (app server downtime?)
Alternatively you can poll the server with getreceivedbyaddress for every address you're watching, which isn't very scalable. Although it can work with a simple limitation: require the user to perform an action whenever they are about to send you a payment. This way you can poll that address with minconf=0 every 10 seconds to get the unconfirmed transaction, then switch to polling minconf=X every 10 minutes until you get X confirmations at which point you stop polling for that address.
In PHP you'll probably need to have a pool of worker processes (php-fpm) to perform that kind of task. Don't daemonize PHP unless you know what you're doing.
I am new to bitcoin, and my balance is up in my wallet, now close to .09 BTC! woo hoo! Many thanks to everyone on this forum that has passed me a few cBTC to help get me going, I really appreciate it!
Now, I am researching programing for Bitcoin, mainly accepting bitcoins on websites, and letting merchants also send bitcoins (in case of refunds, etc)
Right off the bat, I see on the wiki the php dev intro: https://en.bitcoin.it/wiki/PHP_developer_intro
Something that jumps out at me on this is the need for a bitcoin client on the server. This will not be possible in the vast majority of sites (think of a wordpress site on a shared host). In addition, even if you can run it, then you have to go through the process of downloading the whole transaction history, which is starting to get big (several GB). This is not a suitable solution for most sites. I don't think it is even really usable for most people, honestly.
So, looking at options, I see blockchain.info has an API that let's you interact with their wallet. I like this approach, no need for the big download, no need to host the wallet on your server, so you are letting them help with security.
Blockchain.info seems to be a popular wallet, I have a wallet there, as well as a QT wallet that I installed the other day and is STILL doing the original sync.
But, now, I am seeing several blockchain.info APIs. Does anyone have experience working with these in a e-commerce site? I think it could work pretty well with just the simple wallet API, but for better security, probably their JSON RPC API would be better. Have the merchant get a blockchain.info wallet (and recommend customers to do the same for ease), then be able to send and receive payments using the API. Simple. In theory.
You would probably want to create a new address for each transaction, and store customer addresses, in case you need to do a refund, don't know if that is possible. But generally, looks like it could work pretty well.
Does anyone have experience doing this, maybe some sample php I could look at?
Now, I am researching programing for Bitcoin, mainly accepting bitcoins on websites, and letting merchants also send bitcoins (in case of refunds, etc)
Right off the bat, I see on the wiki the php dev intro: https://en.bitcoin.it/wiki/PHP_developer_intro
Something that jumps out at me on this is the need for a bitcoin client on the server. This will not be possible in the vast majority of sites (think of a wordpress site on a shared host). In addition, even if you can run it, then you have to go through the process of downloading the whole transaction history, which is starting to get big (several GB). This is not a suitable solution for most sites. I don't think it is even really usable for most people, honestly.
So, looking at options, I see blockchain.info has an API that let's you interact with their wallet. I like this approach, no need for the big download, no need to host the wallet on your server, so you are letting them help with security.
Blockchain.info seems to be a popular wallet, I have a wallet there, as well as a QT wallet that I installed the other day and is STILL doing the original sync.
But, now, I am seeing several blockchain.info APIs. Does anyone have experience working with these in a e-commerce site? I think it could work pretty well with just the simple wallet API, but for better security, probably their JSON RPC API would be better. Have the merchant get a blockchain.info wallet (and recommend customers to do the same for ease), then be able to send and receive payments using the API. Simple. In theory.
You would probably want to create a new address for each transaction, and store customer addresses, in case you need to do a refund, don't know if that is possible. But generally, looks like it could work pretty well.
Does anyone have experience doing this, maybe some sample php I could look at?
Jump to: