How Trustless Off-Blockchain Transactions Could Solve the Block Size Problem (Op-Ed)

Recent innovative ideas and projects, such as micropayment channels and the lightning network, are creating trustless channels between people so they can transact with each other without touching the blockchain. This could not only save time and memory resources, but it could also help solve the block size problem.

The blockchain requires massive memory, which will increase exponentially in the future and cause scalability issues. Developers have had many discussions and debates about increasing the block size from 1 MB to 20 MB. On the one hand, in order for bitcoin to go global, it needs a much bigger block size, and on the other hand, increasing the block size introduces inefficiencies.

The blockchain has offered people a way to transact with each other without trusting a third party. This is accomplished by replicating the history of all the transactions on all the full node users in the network. Manipulating the data would therefore require a huge amount of resources and be practically impossible.

Since each of us transacts regularly with a limited circle of people, we make repeated bitcoin transactions with the same people. All of these transactions must be added to the blockchain, the number of which could eventually become too numerous for it to handle.

But could we bypass the blockchain and make a trustless channel with someone? Is there any way to reduce the number of repeated transactions by taking advantage of the fact that we deal with the same people over and over again?

A feature in Bitcoin called nLocktime offers a parameter that can be attached to a transaction, which mandates a minimal time during which the transaction cannot be accepted into a block.

To put it simply, let's consider a unidirectional channel where one party sends money to a second party. In order to create this trustless channel, the user needs to lock his money in a 2-of-2 multisig transaction with the other party. But the sender needs a guarantee, in case a situation occurs in which the other party refuses to sign the transaction in the future.

Thus before transmitting this transaction to the multisignature account, the sender obtains a signature from the recipient with an nLockTime of 30 days, for example, before it goes back to his address. This means that if either party at some point doesn’t want to proceed with the transaction, the funds will go back to the sender after 30 days, which guarantees to the sender that he won’t lock his money with someone else without having a backup plan.

Once this channel is established, the sender can start sending money to the recipient off-blockchain from the locked multisig account. He only has to sign the multisig transaction. When the recipient wants to claim the money, he can sign the other half of the multisig transaction and broadcast it to the network. When the last transaction is broadcast to the network, the channel is terminated.

Instead of making multiple transactions between two parties, only one goes through. This means they will pay only one mining fee, and only one transaction needs to be stored in the blockchain.

This idea was initially proposed to solve the microtransaction problem in Bitcoin. Mining fees prevent very small micropayments, but with off-chain transactions, a fee is applied to only the final transaction once one party claims the money.

The idea described is uni-directional. By creating another channel, however, it becomes a bi-directional channel where both parties can send and receive bitcoin to each other.

An extension to this idea would be the lightning network, which creates a network of channels among users. Hence users, without transmitting the transactions to the blockchain, are able to transact without trusting each other.

Only one obstacle exists so far that prevents these technologies from taking off, and that is transaction malleability. Due to this, the nLocktime transaction, which makes the whole thing trustless, cannot be trusted. With a soft fork, however, it is predicted that the issue could be solved.

These innovations would not only solve the block size problems and scalability issues in the future, but they could also add many interesting features, such as trustless zero confirmation or micropayment channels. There could be a lot to come from this promising idea.