Scalable Funding of Bitcoin Micropayment Channel Networks

Abstract

The Bitcoin network has scalability problems. To increase its transaction rate and speed, micropayment channel networks have been proposed, however these require to lock funds into specific channels. Moreover, the available space in the blockchain does not allow scaling to a world wide payment system. We propose a new layer that sits in between the blockchain and the payment channels. The new layer addresses the scalability problem by enabling trust-less off-blockchain channel funding. It consists of shared accounts of groups of nodes that flexibly create one-to-one channels for the payment network. The new system allows rapid changes of the allocation of funds to channels and reduces the cost of opening new channels. Instead of one blockchain transaction per channel, each user only needs one transaction to enter a group of nodes – within the group the user can create arbitrary many channels. For a group of 20 users with 100 intra-group channels, the cost of the blockchain transactions is reduced by 90% compared to 100 regular micropayment channels opened on the blockchain. This can be increased further to 96% if Bitcoin introduces Schnorr signatures with signature aggregation.

A Appendix

1.1 A.1 Coordination of Allocation Updates

When a new allocation is created, the members of a channel factory need to coordinate the creation of a new allocation transaction and all transactions to make the new or recreated subchannels of this new allocation. Due to the number of involved parties this might take a considerable amount of time. However this is not a problem, as normal channel operation can be continued as long as care is taken to make changes to the subchannels of both the old and the new allocation. An allocation update can be executed in the following order:

• 1. A member decides that an update of the allocation is necessary, e.g., because it wants to move funds to another channel, and broadcasts to all nodes of the group that a new allocation should be created.

• 2. As soon as someone receives the allocation update request, he will issue a request to all his subchannel partners to use the current channel state as the base for the new allocation.

• 3. In each subchannel the two cooperating parties decide on a starting state for the new subchannel and broadcast it to the group. Nodes can apply changes that move funds to other channels in this step.

• 4. Each node creates the new allocation transaction. These should all be identical, as they fund the same two party shared accounts.

• 5. The two cooperating parties of each subchannel create the subchannel commitment transactions and sign them. From this point on they keep both subchannels based of the old and new allocation updated.

• 6. All nodes sign the new allocation and exchange signatures.

• 7. After receiving all signatures on the new allocation, a node can stop to update the subchannels based on the old allocation, as those cannot be enforced anymore.

From the view of any node there are three states during this process. In the first state the node knows that only the old allocation may come into effect. In the second state the node has given away its signature on the new allocation, however not received all signatures from the other nodes, thus it is uncertainty which allocation may be enforced on the blockchain. After receiving all signatures the node can enforce the new allocation due to its lower timelock. By starting to apply changes to both the old and new subchannels before giving away the own signature on the new allocation it is always ensured that the newest subchannel state is enforceable on the blockchain.

Note that it is ensured that movements of funds are consistent, i.e., no node can create money by telling different partners different information about moving funds between channels, as the total sum must not exceed the locked funds of the group. A net gain for some party must result in a net loss for another party, which will refuse to sign the new allocation. Furthermore if there are different versions of the new allocation the signatures will not match and the new allocation cannot come into effect. This case can be resolved either by retrying with another new allocation or by giving up and eventually resolving the situation on the blockchain.

The described procedure uses broadcasts of subchannel sizes and signatures. This results in a communication overhead of $O(p^2)$. If this is considered too large, a leader can be chosen, e.g., the node with the smallest input index in the funding transaction of the channel factory. The leader can collect and distribute the information, reducing the number of messages to O(p). The time used by the protocol is constant.

1.2 A.2 Scripts

This appendix lists the different Bitcoin scripts to implement the proposed system. For completeness we also include the already known scripts for two-party payment channels. For every output there is one script that describes the conditions to claim the output and another one that fulfills those conditions and is provided in the input. These scripts depend on a deployed fix for malleability, e.g., Segregated Witness. Note that an implementation might move the output script into the input and use a hash commitment to ensure its integrity and authenticity as usually done in Bitcoin transactions.

1.3 A.3 Two-Party Channel with Timelocks

These scripts implement the transactions in Fig. 5.

The funding and kickoff transactions use Script 1 in their output, which is then claimed with Script 2.

All transactions in the invalidation tree have a simple multisignature output with a timelock, implemented in Script 3.

The locktime is smaller each time a transaction is replaced and thus a new branch in the tree created. They can all be spent with the same input script as the funding transaction, Script 2. The leaves of the invalidation tree split the funds into two outputs, one to each party without restrictions.

1.4 A.4 Multi-party Channel with Timelocks

These scripts implement the timelock based multi-party channel in Fig. 7. Assume p parties. The funding transaction has a regular p-party multisignature output, Script 4.

It is spent by the kickoff transaction with Script 5.

The kickoff transaction creates another output with the same conditions, again Script 4. The transactions of the invalidation tree have one multisignature output with an additional timelock, Script 6.

These are all spent with the corresponding input script of the next node in the tree with Script 5.

The leaves of the tree have any number of outputs, each creating a two-party subchannel with Script 1.