Noncustodial Trading with 10101

Fast Bitcoin trading has never been safer.

We are building 10101 to allow you to use your bitcoin. Needless to say, you will be able to send and receive coins, both on-chain and off-chain via Lightning. But what we are most excited about is bringing noncustodial trading to the Lightning Network.

Trading with Bitcoin as the underlying asset is very popular, but there are almost no options to do so without accepting the risk of a platform vanishing with your funds. To the best of our knowledge, only ItchySats, our latest product, offers noncustodial trading on Bitcoin.

With 10101 we are upping the ante, bringing noncustodial trading to Lightning on your phone. In this post I will outline how we are making this happen.

What makes a trade noncustodial?

If you've ever traded on any custodial platform before, at some point you will have had to cede custody of your funds. Some platforms force you to do this when you first deposit your coins; others wait until you place an order or open a position.

A noncustodial trade is one in which you never give up full custody of your funds to anyone. There are three things that need to happen for this to be possible:

1. Before opening a position, your coins are stored in a wallet owned by you.

2. When the position is open, your margin is stored in a multi-signature output on-chain which you partially own.

3. After the position is closed, your coins return to your own wallet.

The key innovation of 10101 shows up during step 2. Where other platforms take custody of your coins to be able to enforce the rules of the contract, 10101 relies on a cryptographic protocol, guaranteeing that your coins are always yours. Furthermore, the multi-signature output also holds the margin provided by your counterparty, meaning that trades on 10101 carry no counterparty risk.

The mechanism that ensures that the terms of the contract are upheld is known as a Discreet Log Contract (DLC).

Brief introduction to DLCs

A DLC is a 2-of-2 multi-signature output with spend conditions based on events that happen outside of the Bitcoin blockchain. This is very powerful, because up until its discovery we could only express programmable conditional payments based on (1) events happening on Bitcoin, (2) events happening on other blockchains and (3) time.

For DLCs to work we need to involve a trusted third party known as an oracle. Oracles attest to the outcomes of real world events. Said attestations are used to cryptographically unlock coins held in DLC outputs. This is achieved by, ahead of putting the DLC on-chain, signing several Contract Execution Transactions (CETs) spending from the DLC, each activated only if the oracle attests to a particular outcome.

Crucially, oracles are oblivious to the existence of any DLC. One cannot link oracles with DLCs just by looking at the blockchain.

This does not prevent an oracle from colluding with one of the parties involved in a DLC. But, as public entities, misbehaving oracles would be identified as untrustworthy and never be used again.

Regardless, putting too much trust into any one oracle is inadvisable, particularly as the size of the contract increases. With this in mind, one can create DLCs governed by multiple oracles, where only a subset of them (e.g. 2-of-3 or 5-of-9) need to agree on the outcome of an event for the funds to be divvied up in a particular way.

DLCs on Lightning

As mentioned, ItchySats already provides noncustodial trading. You can install the app on Umbrel, RaspiBlitz or desktop and enjoy CFD trading powered by DLCs on Bitcoin mainnet, today.

As a Lightning-first wallet, 10101 will provide noncustodial trading powered by DLCs, on Lightning. This means that the DLC is embedded in the channel, like any other Lightning output. The main benefit of combining Lightning and DLCs is the ability to settle into the Lightning channel without having to go on-chain.

Lightning doesn't currently support DLCs out of the box. This means that we need to make changes to a regular Lightning node in order to make this happen. This is exactly what we started doing for our project for the Legends of Lightning tournament organised by BOLT.FUN. Under the name of 10101, we built a proof-of-concept mobile Lightning wallet, with CFD trading as its flagship feature.

There are multiple ways to approach this problem, with varying degrees of difficulty and levels of integration with Lightning. Back in October, we considered a few before we started building:

1. Creating a DLC channel next to the Lightning channel, by chaining both to a parent commitment transaction¹.

2. Implementing the necessary BOLTs in ItchySats, so that creating a DLC would simultaneously open a Lightning channel.

3. Adding the DLC output directly to the Lightning commitment transaction.

We settled on the last option because it is the most ambitious out of the three. Our vision is to have a Lightning channel where DLCs can be seamlessly added, modified and removed, lightning fast. This approach wouldn't add any new transactions to Lightning and it would allow you to use your DLC winnings to make payments directly.

Adding a DLC to a Lightning commitment transaction

A Lightning commitment transaction, which represents the state of your Lightning channel off-chain, can only contain three kinds of outputs:

• Simple outputs that pay to either party.

• Revocable outputs that pay to either party, after a timelock expires.

• Revocable HTLCs, used to route payments through the network.

This means that we need to extend what the commitment transaction supports in order to introduce a DLC.

Our current design involves adding a revocable output with arbitrary spend conditions, something that we've called custom output. We offload the responsibility of managing the custom output to the layer above the Lightning node. But the Lightning node is still responsible for revoking the output as the state of the channel progresses.

Add custom output Lightning protocol

Other than the arbitrary script, the custom output also differs from standard Lightning outputs in being created with coins from both parties involved in the channel. This is important as DLCs commonly lock up funds from two parties.

Collaborative settlement of a DLC

When settling a DLC, the Lightning node doesn't need to know the specifics. It just needs to be instructed to collaboratively remove a custom output, splitting its coins in a particular way.

Remove custom output Lightning protocol

This is analogous to what happens when a HTLC is removed after a payment has been claimed.

Force-closing a channel containing a DLC

Force-closure must be supported so that you don't have to trust your counterparty in the DLC. You must be able to unilaterally close the channel, committing the DLC to the blockchain in the process.

Once the oracle (or oracles) attests to a particular outcome for the relevant event, one CET becomes spendable and is published, splitting the funds according to the original terms of the contract.

Since the Lightning node does not understand the DLC protocol, it is still the responsibility of the layer above to get the right CET on-chain before the DLC can be refunded².

Staying compatible with vanilla Lightning nodes

When coming up with the design, we knew that our modified Lightning node must still be compatible with all other regular Lightning nodes. One of the main appeals of integrating with Lightning is becoming part of the network, tapping into its fast-growing userbase.

Since we are only making additive changes, it follows that this DLC-compatible Lightning node is still able to send an receive payments with anyone else on the network.

Lessons learned and future work

After spending the last couple of months working on this topic we've learnt a few things which could influence how we approach our next steps with 10101.

Updating a channel that contains an externally-managed custom output is cumbersome

It is nice to be able to ignore the specifics of DLCs at the Lightning node level, but it makes it quite complex to update the channel state. For instance, every time a new payment is routed, there needs to be a lot of communication between the Lightning node, the layer managing the DLC and the counterparty.

We didn't tackle this part of the implementation yet, so we should consider rethinking how much the Lightning node knows about the DLC before continuing.

Dual-funded channels

As mentioned, a DLC is a shared output with funds coming from two parties. As Lightning currently only supports opening unilaterally-funded channels³, it is impractical to set up the channel in such a way that creating the desired DLC is possible.

One can use submarine swaps to circumvent this problem, but changes to the Lightning specification that would enable dual-funded channels have already been proposed and are being reviewed.

Get involved!

If you are as excited as we are about noncustodial trading and all the really cool stuff that can be built with DLCs (trustless stablecoins 👀), you have options:

• If you are into cutting-edge tech, join the closed beta for 10101.

• If you want to trade on Bitcoin today, download ItchySats for Umbrel, RaspiBlitz or desktop.

• If you are a hacker at heart like us, check out our GitHub repositories: 10101, our rust-lightning fork, ItchySats and more.

• If you'd like to work with us, drop us an email at hello@10101.finance.

• And if you just want to chat, join our Telegram group or follow us on Twitter.

1. Our colleagues at Crypto Garage recently posted about their experience with DLCs on Lightning. We are in conversation with them to see if we can collaborate on this topic.

2. A DLC could theoretically remain unspendable on-chain if the parties involved don't agree to settle and the oracle never attests to the outcome of the relevant event. Because of this we have to add a refund spend path to the DLC, so that the funds can be recovered after a lengthy timeout.

3. Certain implementations of Lightning such as Core Lightning (aka C-Lightning) do support dual-funded channels.