The blockchain's increasing size continues to raise concerns about its ability to accommodate transaction growth.

But, could a decentralised system where transactions are sent over a network of off-blockchain micropayment channels solve the ledger's scalability problems?

Joseph Poon and Thaddeus Dryja, the developers behind the Bitcoin Lightning Network, think so.

Although still in its nascent stage, the Lightning Network – based on a recent white paper – aims to solve the scalability issue by implementing hashed timelock contracts between users.

The Bitcoin Lightning Network came to life in 2013, when Poon, "like many before him", he says, had the idea for hub and spoke payment channels. Dryja came on board soon after, making scripting and transactions more compact.

Poon told CoinDesk:

"I think that it is important to look at the way financial systems work because bitcoin development is replaying the history of money. The Lightning Network has significant similarities with how existing financial systems solve this problem."

"We hope to help solve bitcoin scalability and instant transactions, enabling bitcoin to encompass all transactions – even many thousands of micropayments per person," he concluded.

Initial challenges included the realisation that the solution required the implementation of a soft-fork; a change to the bitcoin protocol that serves to invalidate pervious blocks and transactions, although the old nodes still recognise the new blocks as valid.

Full bitcoin nodes are required to store a record of every single transaction that takes place, and as this record grows, that in turn is decreasing the amount of people willing to pay for the escalating costs of running nodes.

For this reason, the developers believe that bitcoin's open ledger does not suffice as a lone payment platform.

To put this into perspective, according to the white paper, the Visa payment network is believed to complete 45,000 transactions per second during a standard holiday period. This increases to hundreds of millions on an average business day.

Bitcoin currently supports approximately seven transactions per second, and is limited to one megabyte of block space. To achieve more than 45,000 transactions per second, Poon and Dryja say that bitcoin transactions must be conducted off the blockchain itself.

The white paper notes:

"If only two parties care about a transaction, it's not necessary for all other nodes in the bitcoin network to know about that transaction. It is instead preferable to only have the bare minimum of information on the blockchain."

It continues: "It is desirable for two individuals to net out their relationship at a later date, rather than detailing every transaction on the blockchain. This can be achieved by using timelocks as a component to global consensus."

While this may sound complicated, essentially it works like this – If all bitcoin transactions are being discussed in an open forum, its public ledger, the lightning network allows parties to enter into a closed room for a period of time, conduct transactions during that period, and at the end of the agreed time, broadcast these transactions to the network.

The white paper states:

Supporters of the proposal suggest this is an improvement over the current transaction systems employed by bitcoin services companies like Coinbase, where transactions are conducted off-blockchain, or away from the network.

They argue that in such scenarios, bitcoins on the network are controlled by Coinbase to avoid the complications of settling small transactions in real-time on the network. Lightning, they argue, presents an alternative where users are in control of funds.

The Lightning Network is not the only project seeking for a sustainable solution to micropayments, however.

BlockCypher recently proposed a solution by which it plans to "calculate miners' fees opportunistically" to ensure microtransactions are added to the blockchain. The system is already in use by Zapchain, the bitcoin-focused social network that recently launched a dedicated micropayments channel.

A hash-time locked contract is first opened by creating a transaction output which only the final recipient can redeem.

The recipient will generate random data 'R', and then hash 'R' using hash(R) to produce 'H'. This information is passed on directly from the receiver to the sender of the funds, along with the recipient's bitcoin address.

The sender then routes the payment to the receiver. Once the receiver has received an updated transaction in a micropayment channel, the recipient may elect to redeem the transaction by disclosing 'R', pulling the funds form the sender.

The purpose of the hash locked contract is to require message 'R' to be disclosed in order for the transaction to be broadcast on the blockchain before a certain date.

However, if Dave does not produce 'R' for Carol within the established time limit, then Carol will be able to close the hash locked time contract.

The receiver will never disclose 'R' unless they are certain that they will receive payment from one of the channel's counterparties. If a party disconnects the channel, the counterparty will be responsible for broadcasting the current commitment transaction state on the blockchain.

However, Poon's and Dryja's proposal does not come without an element of associated risk.

Time is of essence. Participants have to give each other enough time to complete the transaction. If not, invalid transactions may pass off as valid, enabling coins to be stolen.

Additionally, the developers explain that it is unlikely that all participants are honest. If a malicious party creates various channels and makes them all expire at once, this would overwhelm data capacity and would mean that the transaction would have to broadcast on to the chain.

This "mass spamming" of the bitcoin network could potentially delay transactions to the point where other timelocked transactions are also validated.

Then there's the issue of connectivity. In this system, all parties must be online to use private keys. If someone's computer is compromised, counterparty theft may also take place.

The counterparty may also be able to steal funds if one of the participants losses data. This can be mitigated by installing a third-party data storage service where encrypted data gets sent to this third party service. Additionally, the white paper notes:

The Bitcoin Lightning network is certainly a bold attempt at solving the blockchain's scalability issues. But, is it a viable one?

Peter Todd, a bitcoin core developer, believes it is, although he says that it needs to be contextualised further.

Speaking to CoinDesk, Todd, said:

The prominent core developer said that while he was sure that Lightning could be a good system. He was noted that it will require more work to realise, as it's a much bigger project, one that also requires consensus from the community. "It'll also require a soft fork to get off the ground," he concluded.

Despite these relative shortcomings, Todd praised the system. He said that Lightning was proposing that users change how they use bitcoin in exchange for allowing the system to scale, without decreasing its security. He pointed out that for those who think that bitcoin is potentially under threat of regulation or attack, this was a good trade off to make.

Dryja and Poon coincide with Todd's reservations, agreeing that more works needs to be done before the project can completely take off. Dryja said:

The developer confirmed that they were still looking into easy-to-use messaging and authentication, independent of the bitcoin network.

Poon confirmed that they are expecting to release a revised version of the white paper and that next steps would probably include the "BIP (Bitcoin Improvement) and community input".

Pete Rizzo contributed reporting.

What do you think about the proposal? Let us know in the comments section below.