Bitcoin and Micropayments

[dogisland]

I've got something up and running thanks to a mixture of BitcoinJ, Heroku hosting, JQuery and some PHP and I thought people might be interested in taking a look.

It's a demonstration of accepting micro payments with Bitcoin that I've written up on the StrongCoin blog. https://strongcoin.com/blog/bitcoin_micropayments_with_strongcoin

The demo is at http://strongdemo.herokuapp.com/

Currently payments flow to me, but if anyone has a suggestion for a charity Bitcoin address, I can get the payments to forward to that instead.

If anyone decides to use the script for whatever reason please post your results here and please leave any feedback here good or bad.

The script is very easy to host and I'm hoping the micro payments angle will bring in some new users to Bitcoin.

[1714112510]

1714112510

[1714112510]

1714112510

[1714112510]

1714112510

[1714112510]

1714112510

[1714112510]

1714112510

[btc_artist]

The popup, instead of saying "Waiting for Payment" with a bitcoin address, it should say "Send payment to:" with the address, then below the address, say "Waiting for payment".   (IMO, of course).

[PrintCoins]

Does it rely on an another server to connect to? Does bitcoind need to be running on the web server? What is the source of the public addresses?

[dogisland]

Does it rely on an another server to connect to? Does bitcoind need to be running on the web server? What is the source of the public addresses?

The script is connecting to the StrongCoin payments server which is generating the public address and sending out notifications.

 

[dogisland]

The popup, instead of saying "Waiting for Payment" with a bitcoin address, it should say "Send payment to:" with the address, then below the address, say "Waiting for payment".   (IMO, of course).

Sounds like a good idea.

[btc_artist]

The popup could also have an "X" close button to cancel.

[Mike Hearn]

Looks great! How did you use BitCoinJ? That's how you wait for the unconfirmed transactions?

I can see two ways to improve this.

1) Fix the bitcoin client to really finish off the URL integration, then make the address clickable. Right now you have to copy/paste the address, value and set your own label. It could be one click.

2) Speed up verification by allowing direct submission of the TX to the server, rather than waiting for tx broadcast, as that took a long time for me. I'm not sure why. Tx propagation time should be on the order of seconds. I could have just got unlucky - or are you polling behind the scenes?

Both of these require changes to the bitcoin client codes, but neither change is very complex.

It'd be great to have docs on how to setup the whole thing locally, so you don't depend on your servers.

[terrytibbs]

You should forward the payments to Gavin's Faucet.

Looks great, by the way. I'll see if I can't port it over to work with the regular daemon.

[dogisland]

Looks great! How did you use BitCoinJ? That's how you wait for the unconfirmed transactions?

I can see two ways to improve this.

1) Fix the bitcoin client to really finish off the URL integration, then make the address clickable. Right now you have to copy/paste the address, value and set your own label. It could be one click.

2) Speed up verification by allowing direct submission of the TX to the server, rather than waiting for tx broadcast, as that took a long time for me. I'm not sure why. Tx propagation time should be on the order of seconds. I could have just got unlucky - or are you polling behind the scenes?

Both of these require changes to the bitcoin client codes, but neither change is very complex.

It'd be great to have docs on how to setup the whole thing locally, so you don't depend on your servers.

1. I'm going to add QR codes so if your using an android phone you'll be able to pay that way. URL integration would be great too.

2. You got unlucky, most of the time I'm getting TX's straight away, I will configure BitcoinJ for more connections and see if that helps. Otherwise, when the block comes in I trigger the payment notification then as a backup. So you probably got triggered by the incoming block.

I patched BitcoinJ in the same way that multibit patches it. I add a pending transaction listener to Peer.java. A couple of other patches and the rest was easy. I include BitcoinJ as a maven dependency and fronted it with a Servlet. As it's a maven project I can push it directly to Heroku with a git push.

I've also got a patch that will allow BitcoinJ to download the entire blockchain to a database using JPA (Java Persistence API). It's very slow though.

I would say to anyone that's considering doing server side Bitcoin coding, BitcoinJ is the way to go, it's much easier to work with than the C++ code base.

[dogisland]

You should forward the payments to Gavin's Faucet.

Looks great, by the way. I'll see if I can't port it over to work with the regular daemon.

I've forwarded the payments to the Faucet.

[westkybitcoins]

Well, it took longer than I expected, but that actually seemed to work decently.

I will say, I tried downloading the white noise mp3, and got "earth.jpg". Maybe all the buttons provide the same file, but if not, well, something small did go wrong there.

This looks nice. Good work.

[pointbiz]

Great work! This is a good first step. I can see this being used for certain digital goods and donations in it's current form. Maybe for music artists as well.

To satisfy all merchants you may need some type of content delivery security. For example if porn is being sold the merchant would not want his content easily circumvented by someone typing in the url or sharing the url.

There are some possible solutions:
1) You host the content and provide security over it. This is not nice since you eat the bandwidth therefore would have to charge high transaction fees. If you host the content you can deliver it through a PHP (or other language) page that has access control so only the purchaser has access. That brings up the question of how do you identify the purchaser, you could add a cookie during the purchase process, ask for an email, etc. What type of access rules do you allow... 24 hour access, one time download access, etc.

2) The content security is handled on the merchants web server. They'll want PHP, ASP, ASP.NET C#/VB Samples and solutions for the security, dynamic pages controlling access, or files available at a temporary URL, etc.

[sebastian]

pointbiz: The best thing here, is to provide a simple API on top of the standard API:


My suggestion on a simple API, consist of this:

First you take a link, a so called "callback url", payment amount, put your own bitcoin adress before it with a @ between, and encrypt it with RSA, using a public key owned by Strongcoin. This encrypted link, when ASCII-armoured, is base64. Remove the headers so only the base64 content remain. Convert it to urlsafe_base64 (eg replace / and + with - and _), then send it to the API.

Like this:
15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC@0.01@http://www.mysite.com/downloads/file/music.mp3

Then encrypt this with strongcoins public key, and then urlsafe_base64 on this.

Then you send it to strongcoin by providing a "a href" saying Buy now, which links to say:

http://www.strongcoin.com/api/?request=WoreigtnpEopqgituqLirutLiuoqiurtDqgntoEoqiptonpaongupAaigtaopipNtaponaogbapYtnpnpqOeoiuapoinUangpatWnppaooitghtOgagoppUoughjbnnzzLmcgotviotpioDatuoapcmqpBslmxksEdoeltjbduekeSlfigugUtjwklsldkfugyghRieowldjkdhfyPyeuiwowlwRdmvnbueoIepwls

Strongcoin displays payment adress and instructions on how to do payment on the linked page, and then constantly refreshes using META REFRESH until payment is received (or use AJAX but avoid AJAX for backwards compatibility reasons).
When payment is received, Strongcoin simply redirects to the adress that was provided encrypted in the "request" parameter.

Then its up to the original site if they want to save a cookie, allow 24 hour access or whatever upon first visit on the "callback url".
This can even be used with a static HTML pages if someone want to host a static page without any dynamic scripts.

And then the standard API is simply kept asis. Then those that want to code own security, can do it with the "standard API", and those that want a simple payment system can do it. And the "simple API" can also be used with temporarly urls, security controls and such.

[Matthew N. Wright]

I like this. It's extremly light, clean, and overall pretty simple.

I think we'll use this on one of our new sites.

Great job dogisland!

[dogisland]

I will say, I tried downloading the white noise mp3, and got "earth.jpg". Maybe all the buttons provide the same file, but if not, well, something small did go wrong there.

I was indexing the wrong item. It's fixed now.

[dogisland]

Great work! This is a good first step. I can see this being used for certain digital goods and donations in it's current form. Maybe for music artists as well.

To satisfy all merchants you may need some type of content delivery security. For example if porn is being sold the merchant would not want his content easily circumvented by someone typing in the url or sharing the url.

There are some possible solutions:
1) You host the content and provide security over it. This is not nice since you eat the bandwidth therefore would have to charge high transaction fees. If you host the content you can deliver it through a PHP (or other language) page that has access control so only the purchaser has access. That brings up the question of how do you identify the purchaser, you could add a cookie during the purchase process, ask for an email, etc. What type of access rules do you allow... 24 hour access, one time download access, etc.

2) The content security is handled on the merchants web server. They'll want PHP, ASP, ASP.NET C#/VB Samples and solutions for the security, dynamic pages controlling access, or files available at a temporary URL, etc.

It's not going to be a hosted service, the merchant hosts the script and the files.

The link that is generated to the file download contains the payment address. I store this as a file in the system tmp folder, and the file has to be there for the download to succeed. It would be straight forward to setup a cronjob to clear files over an hour old then the links would stop working.

[Ean]

I like the idea, but after four confirmations I'm still waiting ...

[Mike Hearn]

Good to hear you find BitCoinJ easy to work with. I'm the maintainer, let me know if you would find any particular docs or changes helpful. I'm already planning on either merging or redoing the unconfirmed transaction patches, so that should simplify things a lot as then you'd be able to depend on the unpatched library.

For the UI, rather than include a qrcode directly, I think the way to go is to have bitcoin:..... URLs and then have the Bitcoin clients render the QRcodes (or a browser extension). That way we can smoothly migrate to a qrcode-free user experience based on sending the URLs directly to mobile phones via the internet in future - see how the Chrome2Phone extension works for what I had in mind. It's a bit of extra work but better than directly integrating into lots of apps.

[dogisland]

I like the idea, but after four confirmations I'm still waiting ...

could you give me the address so I can take a look.

[Ean]

I like the idea, but after four confirmations I'm still waiting ...

could you give me the address so I can take a look.

1FaX7wn5Xn7jN5rKkFHGDNoD85PuVFZPRE

(It took more than eight confirmations.)