Introduction

Custodial wallets remain part of the Bitcoin space, despite common exhortations of "not your keys, not your coins". One common reason for using custodial wallets is scaling: if you send to or receive from somebody on the same custodial wallet, nothing needs to appear on the Blockchain. Custodial wallets are arguably an offchain construction, with all the scaling benefits of offchain constructions.

However, custodial wallets are trusted third parties, with all the issues associated with such.

A Brief History of Bitcoin Scaling

The first problem of Bitcoin is scaling. It requires that every node is aware of every blockchain-level transaction, consuming tremendous bandwidth resources. Moving tranactions off the blockchain is necessary.

First Tries at Scaling

In 2014, an offchain mechanism that itself used a blockchain construction became popular. Eventual development of this idea lead to strong federations, a custodian composed of multiple entities, which hold the money of their customer in trust. The use of m-of-n signatures ensures that a supermajority of the signing keys is needed in order to defraud the customers.

• The strong federation requires trust in the federation.

• The strong federation presumes that the whole federation is more trustworthy than any of its parts.

• Even though it is a trusted third party, the federation does not prevent direct usage of the base Bitcoin layer.

• Important properties of the base Bitcoin layer (censorship-resistance, non-inflation, practical deployment of fullnodes) are preserved.

As of this writing (late 2018), two "strong federation" networks, Rootstock and Liquid, exist.

When Can I Truly Trust a Federation?

Suppose I refuse to trust anyone at all. Can I ever trust a federation, strong or not, to hold my coins?

Surprisingly enough, yes. I just need to be part of the federation. The other side of "not your keys, not your coins" is "your keys, your coins".

• I need veto rights on the federation so that the rest of the federation cannot defraud me, so we must use n-of-n multisig.

• I need to have some way of moving money back to the Bitcoin blockchain without permission from the rest of the federation.

• I don't need the federation to have many members, as long as I am one of them.

This segues to the other offchain scaling mechanism, payment channel networks. Let us examine first the payment channel.

• They are rooted at a 2-of-2 multisig transaction output.

• For modern payment channel designs, a backoff mechanism exists, which allows a payment channels to be closed by one side of the channel without the cooperation of the other side.

• Payment channels have 2 endpoints.

Each payment channel, then, represents a small federation of 2 members.

Now, each payment channel can be considered its own cryptocurrency, pegged by its federation (the two channel endpoints) to Bitcoins on the Bitcoin blockchain.

If payment channels could support HTLCs, then atomic swaps across multiple payment channels could be possible. Thus, payment channels that can transport HTLCs are powerful enough to build payment channel networks, which allow payment even without a direct channel between payer and payee.

Unlike a centralized strong federation, on this network I do not need to trust anyone else to hold my coins. I need to pay somebody to transfer my coins, but the same is true for the Bitcoin blockchain anyway: hodling is free, payment has a fee. Thus, payment channel networks — the Lightning Network — have no trusted third parties.

In summary:

• Strong federations solve the issue of third-party trust by making the third-party a single large conglomerate, on the assumption that a conglomerate can be more trustworthy than its parts.

• Payment channel networks solve the issue of third-party trust by requiring that every user be a signatory in every federation (payment channel) he or she directly holds money in.

The Lesson of History

To my mind, Liquid and Lightning show a simple fact: premature optimization is the root of all evil.

Strong federations tried to solve the issue of third party trust, by making large third parties that were trustworthy. In the end, however, strong federations are still custodians, and their use fails under the principle "not your keys, not your coins".

It achieves scaling, true, but one can argue that a little more thinking let us devise Lightning Network.

I predict (as of this writing, late 2018) that eventually Lightning will, in practice, be used for what Liquid is marketed today as providing: fast confidential transfers of large amounts.

Conclusion

I write this page, in reaction to common efforts to create custodial Lightning wallets.

To my mind, custodial Lightning wallets represent the same error that Liquid committed: settling for a custodial system.

I suggest that history shows us that people will be able to devise cryptocurrency systems that do not require third-party trust; one only needs to look at Lightning and how it is well-poised to supplant Liquid.

Today, I do not know how we will be able to further scale Lightning without third-party trust. I do not know if we can discover some good way to do so; perhaps Lightning is the last possible way to scale without third parties. Or it might not be: perhaps we need only some missing key insight to scale further without sacrificing trustlessness.

I humbly suggest, then, that those who are currently building custodial Lightning wallets, are better off investigating and devising systems that do not require a third party.

Let us then consider custodiality as a fallback later on, when we have exhausted all available avenues of trustless scaling, and make a good-faith attempt to devise further trustless scaling. ZmnSCPxj late 2018.