Bitcoinj, the Java-based bitcoin client, has now implemented a fully functioning micropayment channel. This will allow a stream of small-scale payments to be sent until the service being paid for has been completed.

The announcement was made by the bitcoin project leader, Gavin Andresen, on Twitter.

Very exciting (and very geeky) news: Micropayment Channel Implementation http://t.co/NIoBwdpXY3

— Gavin Andresen (@gavinandresen) June 27, 2013

There have been several problems facing micropayments in bitcoin as described in the Bitcoinj project page:

1. If you send too many transactions too fast, they will get down-prioritised or not relayed by various anti flooding algorithms built into the Bitcoin network.

2. There is a fixed minimum amount of value a single transaction can send, determined by the number of bytes required to send and claim it along with the fees charged.

3. The recipient of the micropayments ends up with a wallet full of "dust" which can be expensive to spend, fee-wise.

Clearly, there are cases where a series of small payments has been incurred, but as far as one's wallet and the block chain is concerned, just one 'net' transaction would be all that was needed to be recorded.

The Bitcoinj project has solved this by re-using a feature in the Bitcoin protocol called nLockTime, and creating 'refund transactions' that allow the client (the sender) to get their money back, with or without a small deduction that constitutes the micropayment.

More can be read about the micropayment protocol, but the type of situation where it might be used can be seen in a coffee shop which provides a WiFi hotspot. The client (e.g. software running on your smartphone that is also accessing the hotspot) could pay a fixed rate per kilobyte of data. You could set a limit on your mobile wallet app each month, and the phone could then stop using data from that hotspot when it hit its limit.

This is achieved by having a 'contract' between client and server that is valid for a fixed period of time, e.g. a day. Each party (cryptographically) signs the contract, but the transaction is not sent to the block chain. The final payment will require private keys from both parties to be completed. A second transaction has two outputs, one to the client and one to the server. As the micropayments progress, the amount going to each output is adjusted accordingly. The original refund transaction is there to ensure you (the client) get your money back if the server does not respond before the time limit expires to complete the micropayment transaction.

If you want to see the original links and find out more about this, visit Bitcoinj's Sourceforge page.