Skip to main content

· 11 min read

Logo

Welcome to a new chapter in financial freedom. At 10101, we are not just building a platform; we are crafting the future of how Bitcoin trades, driven by the vision of an economy liberated from central authority. Join us on this transformative journey, where innovation meets security, and individual sovereignty is the standard, not the exception.

Trading Bitcoin is Broken!

Where is my money

If you're familiar with Bitcoin, you know its core promise: to serve as unstoppable, censorship-resistant digital money. Central to this promise is the ability to self-custodize your Bitcoin—ensuring you never need to trust anyone else with your assets. The mantra "don’t trust, verify" isn’t just a slogan; it's a fundamental principle of the Bitcoin ecosystem.

Yet, when it comes to trading Bitcoin, this principle falters. Traders must deposit their funds into another party’s wallet, trusting that they’ll see their money returned. This trust has been breached more than once and has led to high-profile collapses: from MtGox a decade ago, to the recent downfall of FTX. Each incident not only harms individual investors but also sets back Bitcoin's global adoption.

This is where 10101 (pronounced "Ten Ten One") comes in. We are pioneering a trading solution that completely eliminates counterparty risk. With our platform, there's no need for a centralized exchange or an escrow service. Your keys, your Bitcoin, your control. Join us in making truly trustless Bitcoin trading a reality.

The Why

Sovereign Individual
Image source: The Sovereign Individual: Mastering the Transition to the Information Age

Empowering Individual Sovereignty

At the heart of our mission lies a fundamental belief in individual sovereignty1. Bitcoin's promise of financial autonomy is compromised when traders are forced to rely on centralized exchanges or escrow services.

We founded 10101 with the conviction that every Bitcoin holder deserves the opportunity to trade without sacrificing control or security.

Addressing Systemic Risks

The systemic risks inherent in centralized exchanges pose a significant barrier to the widespread adoption of Bitcoin. The collapse of major exchanges not only undermines investor confidence but also erodes trust in the entire cryptocurrency ecosystem.

By eliminating the need for intermediaries, we aim to mitigate these risks and foster a more resilient and trustworthy trading environment.

Advancing Bitcoin's Core Principles

Bitcoin was designed to operate without intermediaries - to enable peer-to-peer transactions that are trustless and censorship-resistant. However, the current state of the trading landscape falls short of realizing this vision.

At 10101, we are committed to upholding Bitcoin's core principles by providing a platform that empowers users to transact directly, without third-party custodians that control user funds.

Towards a future without central authority

10101 is not only about enhancing the security and efficiency of Bitcoin trading; it's about championing a broader movement towards an economy liberated from central authority. We aim to democratize access to financial services, making it possible for anyone, anywhere, to participate in the global economy securely and independently. 10101 serves as a gateway for widespread adoption, where trust is built on cryptographic proof rather than institutional promise.

In summary, our why is rooted in a deep commitment to individual sovereignty, a desire to address systemic risks, a dedication to advancing Bitcoin's core principles, and a relentless drive to pioneer innovation in the world of decentralized finance.

The What: Revolutionizing Bitcoin Trading with 10101

Future of trading

At 10101, we are dedicated to enhancing the trading experience while maintaining the core principles of Bitcoin. Here's what sets us apart:

Direct Trading on Bitcoin’s Blockchain

We leverage the inherent security and decentralization of Bitcoin by building our trading platform directly on its blockchain. Currently, our focus is on perpetual futures. This specialized financial instrument allows traders to speculate on the price of Bitcoin without ever needing to hold any other assets. It simplifies trading by ensuring that users can remain invested in Bitcoin while still bet on market movements.

Eliminating Counterparty Risk

One of the fundamental aspects of 10101 is the elimination of counterparty risk. Traditional trading platforms require users to deposit funds into a centralized wallet, leading to potential security risks and trust issues.

At 10101, we negate this risk by enabling a fully self-custodial trading experience. Traders are provided with a secure wallet, generated by 12 seed words that they back up and control completely. This means that at no point do users need to relinquish control of their funds to trade.

Specialized Trading Interfaces

Screenshots

We understand that our users have diverse needs and preferences, which is why we offer two distinct solutions:

  • Retail Application: Accessible via Android, iOS, and direct APK download for those who prefer not to use Google's Play Store, our app is designed for everyday retail users. It features a user-friendly interface that makes navigating the complexities of derivative trading as straightforward as possible.
  • Institutional Application: For institutions requiring greater control over their trading environment, we offer a server-side application. This setup provides enhanced security features and customization options, catering to the specific needs of institutional traders.

Future-Proofing Trading

Looking forward, we are committed to continuous innovation. We're exploring other financial instruments like synthetic assets and options and futures to empower users with variety of different financial instruments to trade and to management risk. Reintroducing Lightning Network support and synthetic stable coins (USDp) further solidifies our commitment to accessibility and inclusivity.

The How: Building trust-minimized trading

Leveraging Discreet Log Contracts (DLCs)

At the core of 10101's technology is the use of Discreet Log Contracts (DLCs)2, an ingenious cryptographic protocol that allows for conditional payments directly on the Bitcoin blockchain. DLCs work by enabling two parties to distribute funds based on agreed-upon conditions, without any of these details being visible on the blockchain. This not only preserves privacy but also keeps the blockchain free from any additional complexities. These contracts appear as ordinary multisignature outputs, making them indistinguishable from standard transactions to outside observers.

Innovating with DLC Channels on Layer 2

Building on the foundation of vanilla DLCs, we have pioneered the concept of DLC Channels. This advancement allows for the creation and settlement of DLCs off-chain, drastically reducing transaction fees and improving scalability. By moving these operations to Layer 2, we enhance the efficiency of our trading platform while ensuring full self-custody at all times.

Open Source Development

Our development is anchored in the open-source library, rust-dlc, which we maintain and contribute to actively. This ensures that our platform benefits from community-driven enhancements and peer reviews, keeping our technology at the cutting edge and secure. The source can be accessed here: rust-dlc3. The remainder of our project is also fully open source and can be found here: 101014.

User Interface and Experience

To complement our Rust backend, we use Flutter to develop intuitive and aesthetically pleasing user interfaces. Our goal is to demystify the complexities of derivative trading and make it accessible and engaging for both novice and experienced traders. The result is a seamless user experience that makes trading as straightforward as using a conventional app.

Our Team's Track Record

Our team's journey reflects our deep-rooted passion for pushing the boundaries of innovation in cryptographic protocols and Bitcoin. Since our inception in 2018 as an R&D lab, we've been at the forefront of pioneering developments. We've facilitated groundbreaking achievements like orchestrating the world’s first ERC-20 and Bitcoin atomic swap5 with our project comit-rs6. Additionally, we've bridged Monero and Bitcoin7 and delved into trustless lending on the Liquid network. Our experiences, including ventures like ItchySats8, have equipped us with a wealth of knowledge and hands-on experience. With over six years of immersion in the crypto landscape, we are poised to continue driving innovation and shaping the future of decentralized finance. Join us on our journey as we continue to innovate and redefine the possibilities of cryptographic protocols.

Current Availability

10101 is live and operational. You can start trading today by downloading our app for Android and iOS. Visit 10101 Finance for direct links to your favorite app store and get started in no time.

Where We're Headed: Expanding Horizons at 10101

Short-term Goals: Perfecting the Platform

Our journey with the public beta of 10101 on Android and iOS has been encouraging, but we recognize there's more to be done to refine our service. We are committed to reinstating key features and introducing new functionalities:

  • Reintegration of Lightning Network: Earlier this year, we had to remove support for the Lightning Network9. We plan to reintroduce this capability, enabling faster, cheaper Bitcoin transactions which are critical for efficient microtransactions and real-time trading.
  • Re-launching USDp: Our synthetic stable coin, USDp, will return to the platform. This feature allows users to hedge against Bitcoin’s volatility without leaving Bitcoin’s ecosystem, maintaining value in USD while benefiting from the security and potential of Bitcoin. USDp's integration with the Lightning Network further enhances its utility, making it transferable as sats.

The next major milestone for us is moving out of beta. Achieving this status means reaching feature completion and ensuring platform stability, a milestone we believe is within close reach.

Long-term Vision: Untethering Self-sovereign Bitcoin Finance

Road into the future

Looking beyond immediate improvements, our goal is to address some of the fundamental challenges in the crypto trading space:

  • Innovating Liquidity Pools: Current channel-based trading is limited to two-party interactions. We aim to expand this by developing liquidity pools directly on the Bitcoin network. Although this research is nascent, technologies like BitVM and potential softfork enhancements like OP_CTV or OP_CAT show promise. These advancements will pave the way for a more interconnected and fluid trading environment.
  • One App, All Things Bitcoin: In the future, 10101 aims to be the all-encompassing app for everything Bitcoin-related. From trading without counterparty risks to managing both hot and cold storage, or even making everyday purchases with Bitcoin or USDp, we envision 10101 as the ultimate tool for Bitcoin enthusiasts.

Catalyzing Broader Adoption

As our platform matures and our libraries stabilize, we will encourage third-party developers to integrate USDp and trustless trading features into their applications. This initiative will broaden the utility of our innovations, embedding them into a wider array of services and applications.

Embracing the Mission: Untethering Self-sovereign Bitcoin Finance

Our broader mission is to untether the power of self-sovereign Bitcoin finance. We believe in an economy liberated from central authority, where individuals can manage their financial lives independently and securely. By continuously pushing the boundaries of what is possible within the Bitcoin ecosystem, 10101 aims to lead the way in creating a truly decentralized financial system.

Conclusion: Join Us on the Journey to Transform Bitcoin Trading

Road into the future

As we continue to build and expand 10101, our focus remains steadfast on empowering traders with the tools they need for secure, private, and efficient Bitcoin trading. From the reintroduction of features like the Lightning Network and USDp to our long-term vision of a fully integrated Bitcoin app.

Get Involved

  • Try Our Platform: Experience the future of Bitcoin trading today by downloading the 10101 app. Available for Android and iOS, you can start exploring all our features in the current beta version. Visit our website10 for direct links to download the app.
  • Follow Us on Social Media: Join our community on Twitter11 or Telegram12 to stay engaged with our developments and participate in discussions with like-minded individuals.
  • Provide Feedback: As a beta user, your feedback is invaluable to us. Help us refine and perfect our app by providing your insights and suggestions. Contact us through Telegram or on Twitter.
  • Spread the Word: If you believe in what we’re building, share our story and app with your network. Every mention helps us grow our community and improve our offerings.

Thank You for Your Support

We are grateful to everyone who has joined us so far on this exciting journey. Your support and participation are what fuel our continuous innovation and dedication. Together, we are paving the way for a decentralized financial future that aligns with the true ethos of Bitcoin—empowering and liberating.

Cheers, Philipp and the whole 10101 team

Footnotes

  1. Recommended read: The Sovereign Individual: Mastering the Transition to the Information Age, by James Dale Davidson and Lord William Rees-Mogg

  2. https://dci.mit.edu/smart-contracts

  3. https://github.com/p2pderivatives/rust-dlc

  4. https://github.com/get10101/10101

  5. https://bitcoinmagazine.com/technical/worlds-first-erc-20-and-bitcoin-atomic-swap-has-taken-place

  6. https://github.com/comit-network/comit-rs

  7. https://github.com/comit-network/xmr-btc-swap

  8. https://www.itchysats.network/

  9. https://10101.finance/blog/see-you-later-mr-lightning

  10. https://10101.finance

  11. https://twitter.com/get10101

  12. https://t.me/get10101

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

Footnotes

  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

· 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 ItchySats[^1]) 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 fields[^2]. 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.

Footnotes

  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