Skip to main content

· 7 min read

If you are reading this post, you may have already heard that we have closed all Lightning channels with our users, replacing them with DLC channels. That may sound like a step backwards, so we want to explain our reasoning behind this decision and tell you why we think it is actually a good thing.

Why we started with Lightning

10101 was conceived as a mobile Lightning wallet with trading capabilities. We think most bitcoiners have heard about Lightning, and they have probably even used a Lightning wallet before. It made sense to us to package our offering together with something that our target user was already comfortable with.

And we saw some synergies between Lightning and DLCs, the technology that we have been using for years to help bitcoiners trade. We wanted our users to be onboarded instantly: generate a Lightning invoice; pay it with their own Lightning wallet; receive the funds instantly in their 10101 app; and start trading straight away. The user would then be able to move funds seamlessly between their trading and Lightning wallets. We even had ambitious plans to let users pay Lightning invoices with a synthetic US dollar stable coin, backed by a DLC.

And we actually managed to do all of that. But the user experience wasn't nearly good enough.

Why Lightning was slowing us down

We've had problems with Lightning at every step of the user's journey through 10101:

  • Users found it difficult to move coins into 10101. A Lightning payment can fail for many reasons, and it is often hard to pinpoint the cause. We generally overcame these issues as we learnt more about Lightning, but it is pretty scary to lose a potential user at the first hurdle.

  • Users found it very difficult to move coins out of 10101. If you have used 10101 to pay an invoice, you have almost certainly run into the dreaded route not found error message. Similar to the previous point, debugging these problems was not simple. In some cases, our node was at fault because routing channels were unusable or the channel-scoring component was not up-to-date. Other times, payments would fail because the 10101 app had a stale channel graph of the Lightning network.

  • Channels would be force-closed for no apparent reason. Of course, there is always a reason. Disagreements during fee negotiations and expired HTLCs were the main culprits here. Regardless, any unnecessary force-closure is catastrophic because it is a waste of money and time for everyone involved. And this is particularly egregious when you are in a high transaction fee environment, like the one we experienced in 2023.

  • When an LN-DLC channel1 was force-closed, getting the money back was a huge ordeal. The LN-DLC protocol requires up to 5 different transactions to be published when a channel is closed unilaterally. Several of these transactions have long timelocks to keep the protocol safe, and every transaction needs to pay a fee to be mined. This meant that it could take a very long time for a substantially smaller portion of the funds to be returned. And, in some edge cases, certain transactions would not even get mined because their reserved fees were too low compared to the rest of mempool2.

As you might imagine, many developer hours were spent chasing Lightning-related bugs3, and this was complicated further by the fact that we were maintaining an extremely complex chain of code dependencies to support Lightning in the first place. We received excellent support from the maintainers of rust-dlc and rust-lightning, but we were always fighting an uphill battle.

Ultimately, the main goal of 10101 was to let you trade self-custodially with your sats. We were spending a disproportionate amount of time working on problems related to Lightning, with little time left to improve the trading experience.

Ripping the band-aid off

At the start of 2024, we finally decided to pivot away from LN-DLC channels. It was not an easy decision, because we had invested so much time into improving the protocol4. But we knew that we had to simplify the tech in a way that better aligned with our priorities.

This pivot involved removing the "LN" out of LN-DLC channels. Fortunately, there already existed an implementation of DLC channels5 in rust-dlc, and we were very familiar with the code. We were able to replace LN-DLC channels with DLC channels in just a few weeks.

There are still some hiccups, but users are encountering fewer problems using the app and the dev team is in a much better position to fix bugs and add new features. Funnily enough, Lightning is a feature that we want to reintroduce in the future.

The comeback

We haven't planned this carefully in advance, but we have some ideas on how this re-integration could look like.

Since the 10101 user already has a DLC channel with us, we already have a place where funds can be moved between the two parties. The library we are using does not currently support using the DLC channel for payments between the two parties, but this would be relatively easy to implement.

Once we are able to make payments within the DLC channel, we just have to bridge the gap between this isolated channel and the Lightning Network. That is, to ensure that a payment within the channel can be propagated through the Lightning Network to reach the payment destination.

A naive approach would be for the user to send us some sats plus a Lightning invoice, and for us to pay the invoice once the payment in our DLC channel has been committed. This has the obvious downside that the user has to trust us to make the payment on their behalf. Nevertheless, it could be acceptable for small payments.

To make it "trustless", we would have to make the payment within the DLC channel conditional on the Lightning payment being claimed. The user would generate a Lightning invoice at the destination wallet and feed it into the 10101 app. The app would then add a HTLC to the DLC channel, locked against the secret hash of the invoice. Our 10101 node would then make the payment on Lightning, which, once claimed by the destination wallet, would reveal the secret back to us. With the secret we would then be able to claim the HTLC in the DLC channel, but we would then collaborate with the app to remove the HTLC altogether and update the balances accordingly.

Obviously, that just sounds like Lightning. But in reality the payment within the DLC channel could be unlocked by a secret that has nothing to do with a Lightning payment. Which means that the DLC channel can be oblivious of Lightning altogether, simplifying the implementation. And the app does not need to run a Lightning node!

Outro

On a personal note, I am proud of the team for being humble and admitting that we had to change our approach. As with most things in life, we now wish we had done it sooner, but hindsight is always 20/20.

If you have any further questions or comments, please reach out on Telegram or on Twitter. We always want to hear from you. And if you haven't used the 10101 app yet, head over to 10101.finance, where you can find download links for you app store of choice.


  1. LN-DLC channels are channels that support both the Lightning protocol (for payments) and DLC channels (for trading, in 10101). They are the construct that allowed 10101 to users to use Lightning and trade at the same time, with a single channel.
  2. We could have fixed this by ensuring that each LN-DLC transaction included an anchor output (per party). In fact, this is something that we now need to address for DLC channels, where the buffer transaction does not include anchor outputs.
  3. To be clear, this is not to blame Lightning for all of our problems. Users also encountered problems with parts of the app that did not involve Lightning directly. And, in any case, we take responsibility for the bugs that our users have run into during the beta.
  4. The author of which is Thibaut Le Guilly, the maintainer of rust-dlc.
  5. We used extremely similar technology in our previous project, ItchySats.

· 7 min read

2024 kicked off at full speed in the Bitcoin world: we celebrated the 15th Bitcoin anniversary on January 3rd; Bitcoin ETFs were approved and have recorded record-breaking trading volume; and, of course, we are heading towards the next Halving after block 840,000, which is estimated to happen around April 19th.

While this alone is already plenty to digest, we at 10101 will continue pushing the boundaries of self-custodial trading on Bitcoin using Discreet Log Contracts (DLCs).

2023 - A Year in Review: Achievements and Growth

2023 was the biggest year for us ever.

Winning $750k in NY

At the beginning of April, we packed our bags and flew to New York to participate in the first edition of the prestigious Bitcoin startup accelerator, Wolf (https://wolfnyc.com/). After completing the 8-week program and pitching in front of potential investors, we emerged victorious, securing an additional investment of $500k. Combined with the $250k cheque that every startup got for participating, we earned a whopping $750k. We are very proud of our achievements at Wolf, but that is just one small step in our journey towards untethering the power of self-sovereign Bitcoin finance.

Giving back to the community

During the summer, we shared our expertise on DLCs at various conferences, including BTC Prague, Baltic Honeybadger in Riga, The Bitcoin Conference in Innsbruck, and Adopting Bitcoin in El Salvador. It is one of our primary goals to not only develop groundbreaking technology, but also contribute to the wider community by imparting knowledge and educating others on how to continue growing the Bitcoin ecosystem.

Public launch of our beta program

In October, we reached a significant milestone with the eagerly awaited public launch of our mobile application, 10101, now available on both Android and iOS platforms. This marked a pivotal moment in our journey, bringing us closer to our audience and allowing users to experience firsthand the innovative features we had been working on.

The positive response from our initial users has kept us motivated as we refine and enhance the app based on all the valuable feedback.

USDP: Pioneering the World's First Self-Custodial Stablecoin on Lightning

In late 2023, we came second in second edition of the Legends of Lightning Tournament (https://bolt.fun/project/10101) organised by bolt.fun. During this event, we achieved a gret feat by launching the world's first self-custodial stablecoin on Lightning—USDP.

Checkout our video here: https://rumble.com/v40mwq7-usdp-the-first-usd-on-lightning.html

USDP meets the longstanding demand within the Bitcoin community, seamlessly blending the stability of a traditional "stable coin" with the censorship-resistant network of Bitcoin. Users can now send and receive satoshis around the Lightning Network while maintaining stability in USD value which makes USDP natively interoperable with any Lightning wallet.

This unique feature ensures users experience the benefits of a stablecoin while retaining full control over their private keys. USDP marks a significant stride in providing a secure and censorship-resistant financial experience on the Lightning Network.

2023 presented its fair share of challenges, as pushing the boundaries of self-custodial trading proved to be a formidable task. Our commitment to bringing self-custodial trading to the masses led us to integrate DLCs into Lightning. This allowed users to engage in self-custodial trading without counterparty risk, directly from their Lightning wallets.

The convergence of these cutting-edge technologies, however, introduced several hurdles: code complexity, protocol complexity and the number of transactions which have to be broadcasted when force-closing a DLC/Lightning channel.

Other challenges included random channel force-closures stemming from fee rate negotiation failures, dealing with amounts that risked pushing channel balances below dust values, and navigating high transaction fee environments that unexpectedly complicated Lightning transactions.

During this journey we learned a lot about Lightning, fee management, and the intricacies of the Bitcoin mempool. Despite the challenges, we remain convinced that DLCs are the ideal tool for self-custodial trading on Bitcoin. However, recognizing the need for Lightning improvement, we've adjusted our course to focus on building DLC Channels.

Building on the groundwork laid two years ago with ItchySats (https://comit.network/blog/2022/01/11/cfd-protocol-explained), we are now bringing DLC Channels to mobile devices, simplifying and enhancing accessibility. Today we are using the more advanced library rust-dlc (https://github.com/p2pderivatives/rust-dlc).

This strategic shift was driven by the complexity of merging both technologies seamlessly.

It's important to note that we are not abandoning Lightning. In an upcoming release later this year, we will connect DLC Channels with Lightning, offering users the best of both worlds: the simplicity of DLC Channels and access to Lightning’s large payment network.

For a more technical deep dive on this topic, stay tuned for an upcoming blog post on this topic.

Looking Ahead: Our Vision for 2024

We have very ambitious plans for 2024:

We've just relaunched our app with simplified DLC Channels. We have removed the ability to fund the wallet using Lightning, but this change is only temporary. In an upcoming release, we'll reintroduce this feature, and we will bring back USDP too. Users will once again be able to transact in stable coins on Lightning – fully self-custodial.

Having initiated a pilot program code-named DLC Connect, we're now also catering to institutional investors seeking counterparty-risk-free Bitcoin derivatives trading. This self-hosted solution aligns with our 10101 app, which is aimed at retail investors.

In anticipation of the next bull market, we foresee not only high volatility but also escalating on-chain fees for Bitcoin. Recognizing how this can prevent new users from setting up DLC or Lightning Channels, we are exploring looking at technologies like Fedimint or Liquid, as we aim to provide a more cost-effective and risk-reduced option as an alternative to layer-2 protocols on Bitcoin.

Join Us on the Journey: Your Role in Our 2024 Plans

To our valued retail users, your participation in self-custodial trading is not just about transactions – it's an opportunity to shape the early stages of our journey. We welcome your opinions, thoughts, and feedback as we continue to refine and improve.

Join us on Telegram (https://t.me/get10101) and follow us on X.com (https://x.com/get10101).

To our esteemed institutional investors, explore a new era in Bitcoin derivatives trading through our pilot program, DLC Connect. Your input is invaluable as we navigate these early stages. Share your insights, thoughts, and feedback to help us shape a secure and robust platform. Together, let's chart the course for a collaborative and successful future in 2024.

Charting a Bold Course: Together into 2024

As we enter 2024, several companies are delving into the topic of on-chain DLC protocols. Notable players like Atomic Finance, DLC.link, Mutiny, and LNMarkets, are making strides in various areas, from Bitcoin yield products to bridging blockchains and on-chain social betting.

However, it's essential to anticipate that the rise of on-chain transaction fees will pose a challenge for on-chain DLC protocols, ruling out small trades and retail investors.

At 10101, we take pride in pushing the boundaries of self-custodial trading using layer two protocols. Our recent relaunch features simplified DLC Channels, a testament to our commitment to reducing on-chain footprint while enhancing privacy and speed.

Read more on 10101.finance, join us on Telegram (https://t.me/get10101/1) and follow us on X.com (https://x.com/get10101) as we collectively steer towards a future marked by innovation, collaboration, and self-custodial excellence.

Download our app here:

Cheers, Philipp and the whole 10101-team

· 8 min read

How can I try 10101?

You can try out the public beta immediately by downloading it from Google Play if you're using an Android smartphone, and from TestFlight if you're using an iPhone.

10101 is a mobile application. It is not possible to access it from your browser.

Why "10101"?

10101 is pronounced "ten ten one", and it means 21 in binary. Just a pun! There will never be more than 21 million bitcoins!

What is 10101?

It's a self-custody-first Bitcoin app that includes: A Bitcoin wallet for sending and receiving sats on-chain, and the ability to trade financial derivatives directly from it, thanks to cutting-edge Discreet Log Contracts (DLCs) technology.

Once your wallet has been funded, the application will allow you to open an order directly from your wallet, thus opening your DLC Channel

Will 10101 manage the funds for me?

No, at no time will 10101 hold your bitcoin.

Our application makes a point of respecting and educating users in the principles of self-custody: you hold your own keys, you remain responsible for your wallet and funds, and you retain full control throughout your experience.

That's why you need to make sure you back up your recovery phrase and keep it safe.

What's the point of the recovery phrase?

Your recovery phrase (sometimes called "seed") is the only way to redeem your funds. If you've deleted the app or lost the data on your phone, you will not be able to access your funds without it. We will be unable to assist you either.

You absolutely must save it and keep it in a safe place.

In the case of 10101, this backup will enable you to restore your funds within the app from both your on-chain and off-chain balance, as well as your transaction history and open orders.

In the worst case scenario, you will be able to close your DLC channel after using your recovery phrase.

Do I have to run a node separately to use 10101?

You don't have to run your own node to use our app, however, it will soon™️ be possible to connect your own node, in order to be independent and sovereign in broadcasting and receiving your transactions from your device.

On-chain? Off-chain?

On-chain is a term used to designate the operations taking place on the traditional Bitcoin network: It is used for its high level of security and verifiability, and allows large amounts of money to be sent and received for a fee. Your on-chain balance

Off-chain is used to describe every operations taking place between actors inside a DLC Channel (just like Lightning, or any layer 2 protocol). While inheriting of the security of the base protocol, it allows to operate in a fast way and at very low cost, as long as the channel is kept open. By closing a channel, a settlement operation will take place on-chain, incurring fees.

In the case of 10101, you can close a position without having to close your channel. Your funds will then be displayed on your off-chain balance, allowing you to operate further trades at your convenience. At any time, you can withdraw your funds to your on-chain balance by closing your DLC Channel

How is it possible to trade directly from my wallet, without a platform?

This is made possible thanks to Discreet Log Contracts (DLCs).

A DLC is a multisig transaction output funded by two parties, which can be unilaterally spent by either one according to a future event external to the blockchain. One or more oracles are used as trusted, oblivious third parties, as they attest to the outcome of the event and determine how the funds will be split.

Applied to trading using 10101, a DLC is set up with the user providing part of the collateral and their counterparty in the trade providing the rest. In the case of BTCUSD perpetual swaps, the event external to the blockchain is the price of Bitcoin. The oracles eventually attest to the price and, depending on that value, the funds in the DLC can be split in a particular way, with the user realizing their PNL.

Off-chain DLCs can be seen as an additional layer built on top of Bitcoin.

If you want to learn more, we produced a series of blog posts on this topic, and another one on the specific case of trading settlements.

How is the DLC channel funded?

DLC channels are bilaterally funded during the first trade order.

We, on our side, will always put the necessary margin to cover the quantity (number of contracts) of your trade with a x2 leverage.

Examples:

  • If the opening price is $40,000 and you open a $2,000 position with a x4 leverage, your margin is 0.0125BTC, ours is 0.025BTC. Total channel value : 0.037BTC
  • If the opening price is $40,000 and you open a $2,000 position with a x1 leverage, your margin is 0.05BTC, ours is 0.025BTC. Total channel value : 0.075BTC
  • If the opening price is $40,000 and you open a $2,000 position with a x2 leverage, the channel will be perfectly balanced as both parties will have a 0.025BTC margin, for a total channel value of 0.05BTC

Conclusion : your margin in BTC will depend on the opening price, quantity, and on the leverage you choose. Ours will always remain relative to the opening price and quantity you have selected

As your first trade defines the configuration of your channel, it's important to take the above elements into account when assessing your payout expectations (our maring minus the order matchinng fees).

If this explanation isn't clear enough for you, please let us know!

We'll be publishing a detailed article on the financing of DLC channels and trading orders shortly.

How can I open a DLC Channel?

By creating your first order, you will automatically create your DLC Channel with 10101. You can close your position, but your channel will remain open until you decide to close it.

Depending on the size of this channel, you'll be able to open larger or smaller positions in the trading section, or hold more or less synthetic currency in your wallet (to be released)

Why my position has an expiry?

In an ideal world there would be no expiry, but it is the only way that we can safely simulate a perpetual swap using DLCs. DLCs are open until the oracle attests to the outcome of an event (attestation time). That's why we have a rollover protocol which replaces the old DLC with a new one with an attestation time further in the future.

Positions always expire on Sunday, 15:00 CET, and therefore have a maximum expiration time of one week.

You, as the trader can decide to close your position anytime by clicking Close position.

What if I don't want my position to expire after 1 week?

A position has an expiry of 1 week, i.e. it always expires on Sunday, 15:00 CET.

We introduced a quick and simple way to renew it, codenamed rollover weekends: If you come online between Friday, 15:00 CET and Sunday, 15:00 CET your position extends for another week.

If you've accidentally rolled over a position you didn't want to keep open, you can decide to close your position at any time by clicking on Close position.

For the time being, renewing a position is free of charge, but a funding rate will be introduced eventually.

Can I open several positions at the same time?

It is not yet possible to open several different positions. However, it is in our plans to make it possible to resize your position at any time, without changing the leverage.

If you want to resize your position beyond the limits of your DLC Channel, you would have to resize your channel (see next section).

Can I resize my DLC Channel (splicing)?

No, but definitely in the future. Splicing would be more cost-effective than closing and reopening a channel

Why can I not trade with my full off-chain balance?

You will not be able to open positions covering your entire off-chain balance, as you will need to keep a reserve.

Part of this reserve must remain so that on-chain transaction fees can be covered, enabling you to recover your funds in any worst-case scenario.

Can I fund my 10101 wallet using Lightning?

From version 1.8.0, it's no longer possible to fund your wallet nor your DLC Channel via Lightning. However, we are working on reintroducing this feature. Stay tuned!

As an Android user, I don't have access to the Play Store. How can I try out the application anyway?

We have a releases page on GitHub: https://github.com/get10101/10101/releases

You can find the APK corresponding to the architecture of your device and the associated signature files.

I need help / troubleshooting

If you use our TestFlight app for iOS, you can send us a crash report directly from your app, or from TestFlight. More details here: https://testflight.apple.com/#giving-feedback

Don't hesitate to get in touch with our team, who will be able to help you and answer your questions on our dedicated Telegram support channel. If possible, prepare your application logs for us to investigate.

I need guidance

You can count on our team and on the community!

Feel free to join our social channels and get in touch!

· 5 min read

This is the third and last part of the series on how to bring DLCs to Lightning. Check out the first two blog posts if you haven't already.

  • Part 1: A quick overview of Lightning, Adaptor Signatures and DLCs.
  • Part 2: Discusses an approach of expanding the commitment transaction with a custom output.

In part 3, we are going to show you how 10101 is utilizing virtual channels to bring DLCs to Lightning.

DLC Channel

In order to bring DLCs to Lightning we have to firstly bring them off-chain. (Note, we have done this in the past at ItchySats1) That is so that we do not have to go on-chain directly after a DLC has been been expired (after the oracle attested to the outcome of an event) or renewed.

A simple approach would be to make the CETs revocable, but that can't be done without putting the side revoking first at a disadvantage. The counterparty could then choose to publish the CETs from the previous or the current contract while they cannot, since they have already revoked them. For that reason we are using a revocable buffer transaction.

The buffer transaction is a simple transaction that takes the funding transaction output as an input and is itself the input of every CET. Now if the counterparty acting second is not revoking the buffer transaction in a timely manner, the party revoking first is able to broadcast the buffer transaction and settle the contract unilaterally.

But how to revoke the buffer transaction?

We can again make use of adaptor signatures. When a contract is set up, both parties give each other an adaptor signature for the buffer transaction input, encrypted with their counterparty publish (public) key.

If either party wants to broadcast the buffer transaction, they need to decrypt the adaptor signature received from their counterparty using the publish (secret) key. By broadcasting the buffer transaction the publish secret key is revealed, which is fine as long as the buffer transaction hasn't been revoked yet. However, if it has been revoked the counterparty is also in possession of the revocation secret and will be able to get the entire output funds. Note that CETs have a relative timelock, giving the cheated party time to punish the counterparty for broadcasting a revoked buffer transaction.

Embed DLC Channel into a Lightning Channel

In part 2 we talked about adding a custom output to the commitment transaction. This approach had the significant disadvantage that the CETs would have to be recalculated on every payment received or sent. That resulted in a lot of overhead that we did not want to have for our 10101 solution.

Consequently, we opted to split the Lightning funding transaction into a Lightning channel and a DLC channel. We are achieving that by spending the funding transaction into a split transaction containing two outputs: One for the Lightning channel and one for the DLC channel.

Lightning Channel

This split transaction is again revocable in the same manner as the buffer transaction described before. Unfortunately, this raises an issue if one party is publishing a revoked split transaction. The cheated party needs to have some time to notice the broadcasted transaction and punish the counter party, but the Lightning commitment transaction already uses both the nLockTime and nSequence fields2. To circumvent that issue an additional "glue" transaction is added, spending the Lightning commitment transaction and allowing to add the required timelock.

The following diagram illustrates the complete transaction structure of a DLC-enabled Lightning channel. Note that different publish and revocation keys are used for the split transaction and the buffer transaction.

Closing Thoughts

With a DLC channel living alongside the Lightning channel we are bringing DLCs to Lightning while still keeping a fully-functional Lightning wallet. However, while the proposed solution is certainly feasible there are still challenges that have to be addressed in future work.

  • On-chain footprint: Lightning and DLC channels are secure because either party can go on-chain unilaterally at any point. But the split channel setup involves so many transactions that the associated fee costs are considerable. It can be very expensive to go on-chain without collaboration.

  • Splicing: Managing channel capacity dynamically for two channels to the user's demands would really benefit from splicing capabilities. Interestingly our solution is already implicitly supporting a splice out, as we could for instance only close the DLC channel on-chain independently of the Lightning channel. However, a more ergonomic solution is required.

  • Anchor Outputs: The current transaction structure does not care for updating transaction fees. As there are multiple timelocks involved a simple CPFP is unfortunately not possible. One way to approach that issue is to add anchor outputs to the split and buffer transaction, but that would again increase the on-chain footprint significantly if the counterparty is not collaborative.

Acknowledgements & References

Our work is heavily inspired by our colleagues at CryptoGarage who were the first to open and close a DLC on Lighting. See https://medium.com/crypto-garage/dlc-on-lightning-cb5d191f6e64 to read about that in more detail. We are also happy to build upon their work to further improve DLCs on Lightning contributing to the open-source project rust-dlc.

1 https://comit.network/blog/2022/01/11/cfd-protocol-explained/

2 https://github.com/lightning/bolts/blob/master/03-transactions.md#commitment-transaction

· 4 min read

In the first part of this series, we provided an overview of Lightning, Adaptor Signatures and DLCs. If you need a refresher, you can find it here.

In part 2, we will now delve into the approach of expanding the commitment transaction with a custom output. This was our first attempt at bringing DLCs to Lightning.

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.

This 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.

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.

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 and receive payments with anyone else on the network.

Lessons learned and future work

After implementing that approach as PoC for the Legends of Lightning tournament, we've learnt a few things which influenced how we approached 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.

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 1, it is impractical to set up the channel in such a way that creating the desired DLC is possible.

Next

In the next and last blog post of this series we are going to write about how we are using virtual channels alongside the Lightning channel in 10101 to bring DLCs to Lightning.


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

· 5 min read

At 10101 we are working on extending the Lightning network to support DLCs, allowing Bitcoiners not only to pay and receive payments, but also to trade right from their channels.

In this series of blog posts, we will delve into how 10101 brings DLCs to the Lightning Network. The series will consist of three parts:

  • Part 1: A recap on Lightning and DLCs.
  • Part 2: Exploring the incorporation of a Custom DLC Output on top of the Lightning commitment transaction.
  • Part 3: Discussing the integration of a Virtual DLC channel alongside the Lightning channel.

Teaser: At 10101, we ultimately opted to develop virtual channels as our solution.

A recap on Lightning

In order to understand the process of setting up a Discreet Log Contract (DLC) within a Lightning channel, it is essential to have a basic understanding of the transaction structure associated with regular Lightning channels. Let us briefly review this structure, focusing solely on the aspects relevant to our discussion and omitting details like routing, liquidity, etc.

When two Lightning nodes establish a channel, they collaboratively construct and sign two types of transactions: the funding transaction and the commitment transactions.

  1. Funding Transaction: takes a number of UTXOs from one of the two parties as inputs. These funds are locked within a 2-of-2 output, which necessitates the signatures of both parties to be spent. This output is known as the funding output and serves as a repository for the channel's funds.

  2. Commitment transaction: references the funding output as its input and incorporates two outputs, each reflecting the balance held by the respective parties. It is important to note that these balances are subject to change throughout the channel's lifespan, thus requiring the commitment transaction to be updatable to accurately reflect these modifications. To achieve this, the commitment transaction is designed to be revocable. In practical terms, each party maintains a distinct version of the commitment transaction, with the output paying to themselves secured by a script that can be unlocked either by their own signature after a specific period or by their counterpart possessing a secret. When the parties reach an agreement to adjust the channel balance (e.g. one party intends to transfer a certain amount of sats to the other), they generate and exchange signatures for the updated commitment transactions while simultaneously revealing the secrets used in the previous versions. In the event of a party attempting to cheat the other by broadcasting an outdated commitment transaction, the opposing party has a window of time to respond and employ the revealed secret to claim all the channel's funds.

The following diagram illustrates the transaction structure of a lightning channel.

If you want to read up in more detail how Lightning works have a look at this blog post

A recap on Adaptor Signatures

An adaptor signature is a signature that has been encrypted with a secret, and for which we can prove that after decryption (or with knowledge of the secret) we obtained a valid signature for a given message.

For a DLC we use the oracle's signature as a secret to encrypt the counterparty's signature which unlocks a certain Contract Execution Transaction (CET). These signatures are created as adaptor signatures using the oracle's announcement that it will attest to an event outcome in the future. Using this publically available information both parties generate all possible signature points that could be released by the oracle and use them to encrypt their signatures. Upon exchanging and verifying these adaptor signatures, both parties have collected all data required to eventually broadcast the only valid CET.

If you want to read up in more detail about Adaptor Signatures and how they are used in the context of DLCs have a look at this blog post

A recap on DLCs

Discreet Log Contracts (DLCs) are a type of smart contract protocol that operates on the Bitcoin blockchain, allowing for the execution and settlement of contracts based on events external to the blockchain.

During the setup of a DLC both parties lock up funds in a DLC output. This output can only be spent with signatures from both parties. At the time of the DLC setup the actual event outcome is not know yet, but the oracle has announced that it will attest to its outcome at a specific point in the future. Both parties generate multiple CETs, each defining how to split up the locked up funds based on a specific potential future event outcome. After agreeing on the CETs, both parties exchange adaptor signatures on each of them. An adaptor signature for any given CET will only be unlocked if the oracle attests to the specific event outcome associated with the corresponding CET.

The key characteristics of a CET are the following:

  • Only one CET will become valid after the attestation of one or multiple oracles.
  • Neither party can publish a valid CET without having the oracle's attestation.
  • Publishing a CET is unilateral after the oracle's attestation.

The most simple example of a DLC is a binary option. The diagram below illustrates the transaction structure of such a DLC. As the potential future event outcomes can only be true or false, only two CETs have to be generated.

Note, in case of a numerical outcome, a CET would have to be created for every possible outcome or a range of outcomes.

Next

In the next blog post we are going to write about the first approach we tried to bringing DLCs to Lightning using a Custom DLC Output on the commitment transaction.

References

· 7 min read

In a previous blogpost we talked about self-custodial settlement paths in 10101. In this blogpost we explore how the 10101 app will enable you to stay self-sovereign in your self-custodial trade setup.

Without a certain level of self-sovereignty, your self-custodial setup might not be as protective as you think. If you depend on a single service provider too much, then you might not be able to act in a worst case scenario.

· 4 min read

In our previous blogpost we wrote about the motivation for self-custodial trading and when it matters. In this blogpost we explore how the self-custodial setup works and what happens when you click the button to close a position.

When you trade in 10101 there are three phases:

  1. Discovery: Finding a trading partner through the 10101 orderbook

  2. Execution: Opening the position by setting a P2P smart contract on Bitcoin

  3. Settlement: Closing the position by resolving the contract