Off-chain Bitcoin Micropayments Implemented in Bitcoinj

7 Flares Twitter 0 Facebook 0 Google+ 7 LinkedIn 0 Email -- 7 Flares ×

The latest improvement to bitcoinj will enable users to make off-block chain micro transactions and has the potential to dramatically reduce the size of blocks going forward. There has been considerable concern about the minimum size of transactions that should be included in blocks. While many voice the opinion that no one should be allowed to police what transactions can be included, it is equally as clear that it is not reasonable for everyone in the world to host every bitcoin transaction on their hard drive. Gavin was particularly excited about the implementation:

gavin_tweet

Tweeted at 10:26 AM – 27 Jun 13

The block chain recently passed 8GB, a sizable number considering it has to be downloaded over peer to peer communications. The size of bitcoin blocks – the storage unit for bitcoin transactions – depend on many factors, most notably the number of transactions included in it. All other things being equal, a transaction moving 1,000 bitcoins uses the same amount of space as a transaction moving 0.0001 bitcoins. The most significant difference however, is the security required to trust the transaction. A large-value transaction should be verified in several blocks to reduce the risk of a double spend. The cost of performing a double spend most likely will outweigh the value of a microtransaction, significantly reducing the concern.

total_transactions_chart

Transaction Volume over the Last Year

block chain size

Total Block Chain Size

The solution implemented in bitcoinj will allow two parties to open a live channel using a TCP socket for resolving a series of small transactions. The trick is re-imagining a depreciated feature called nLockTime transactions. These transactions are published to the block chain like normal transactions, however do not become valid until a pre-determined time in the future (it is locked until nTime has passed). The micro-payment channel passes these signed transactions over the TCP socket as insurance, since either party can publish it to the block chain if communication ceases, until the final amount is reached. The sum of these transactions is then published as a single transaction. More details on the technical implementation can be found on the bitcoin wiki.

In addition to the block chain concerns, the bitcoinj repository posted an informative article describing some of the major advantages of this new feature titled Working With Micropayments. In it they described three advantages of the new system:

  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.

The use case example for this described on the wiki relates to a series of transactions in an internet cafe:

For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You’d like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone’s mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.

However, one of the biggest advantages that comes to mind would be a service like Satoshi Dice, a betting game that uses the random value created by transaction information to determine whether the user is a winner or loser, reconciling high-volume but low-value transactions periodically instead of including all of them on the blockchain. This could still be performed using nLockTime transactions since they still have to be signed and hashed while transmitting it over the TCP socket. The bitcoin community owes thanks to the developers, Mike Hearn and Matt Corallo, who donated a significant amount of time to implementing this feature.

7 Flares Twitter 0 Facebook 0 Google+ 7 LinkedIn 0 Email -- 7 Flares ×