The Lightning network is a design for a decentralized, scalable network that allows for fast, cheap Bitcoin transactions without requiring trusted third parties. However, it requires the presence of new functionality in Bitcoin: without this new functionality, the Lightning network can not exist. So, in order to make the Lightning network a reality, the Bitcoin community must be convinced to accept this new functionality. While none of this new functionality is known to have any controversial characteristics, some of it has, so far, no use case outside the Lightning network.

Since any new functionality makes Bitcoin more complex, and more complex systems have more places where vulnerabilities can exist, the Bitcoin community might be reluctant to accept new functionality, unless convincing evidence is provided about the value of the new functionality. However, so far, the Lightning network only exists on paper, and has not been demonstrated to be useful in real-life conditions. This creates a catch-22 situation: in order to convince the Bitcoin community, we would like to make a working implementation of the Lightning network, but in order to do that, we need to convince the Bitcoin community to include the required functionality.

There are a couple of ways to escape this catch-22 situation:

• The Bitcoin community might accept the required functionality, even without a working Lightning network.
• It is possible to demonstrate the Lightning network on an alt-coin (possibly one specifically designed for this purpose), or on a side-chain, once side-chains are realized.
• It might be possible to emulate the missing functionality, with some loss of desirable properties, using only the already existing functionality of Bitcoin. This would allow Bitcoin users to become familiar with Lightning-like technology, while simultaneously increasing the pressure to "fix" the loss of desirable properties by including the missing functionality in Bitcoin.

This paper describes a design that follows the third approach. The "no trusted third parties" requirement is relaxed, by introducing a partially trusted escrow party, which can be audited by arbitrary third parties. The design is such that, after the missing functionality is introduced to Bitcoin, the migration to a full- featured Lightning network can happen gradually: pairs of neighboring nodes are free to choose when they upgrade their link to a real Lightning link, and during the migration period, transactions can be routed through both old-style and new-style channels (in any order).