Discreet Log Contracts (DLCs) have recently emerged as a contentious topic in Bitcoin development circles. These contracts, built on Bitcoin's base layer, aim to expand its functionality beyond simple value transfer. Proponents argue that DLCs could bring sophisticated financial instruments to Bitcoin without compromising its core principles, while critics warn of unnecessary complexity and potential vulnerabilities.
DLCs are presented as a solution offering several key benefits:
- Non-custodial escrow functionality
- Minimized vulnerability to online attacks
- Elimination of counterparty risk
- Utilization of Bitcoin's base-level security
So are DLCs the future, or are we straying off the yellow brick road? Let’s take a closer look.
#Understanding DLCs: The Basics
At its heart, a DLC is just a fancy multisig transaction with an oracle thrown into the mix. Specifically, it utilizes a 2-of-2 multisig output controlled by both parties involved in the contract, plus an oracle that broadcasts its judgments and doesn’t need to know about a specific contract. This mechanism allows two parties to form a contract that redistributes their funds based on preset conditions without revealing the details of these conditions. Using oracles distinguishes DLCs from traditional multisig transactions, allowing them to respond to external events. For example, in a simple binary bet, an oracle might report the result of a sports game, which then determines how the funds in the DLC are distributed.
Before we go any further, it must be said that the name "Discreet Log Contract" itself is problematic and bordering on misleading. It bears an apparently deliberate resemblance to "discrete logarithm" (itself often abbreviated to “discrete log”), a fundamental concept in cryptography, creating a potential for confusion among both newcomers and seasoned professionals in the field in the manner of typosquatting attacks (as “discreet” is a homophone and common misspelling of “discrete”). The authors might have thought it cute, but in practice, it makes them annoying to talk about.
But beneath the questionable branding lies a mechanism of surprising elegance. Three key elements form the backbone of DLCs: the Funding Transaction, Contract Execution Transactions (CETs), and Adaptor Signatures. These components work together to create a sophisticated contract system on Bitcoin's blockchain.
Setting up a DLC builds upon these elements in a logical sequence. It begins with the parties agreeing on terms and selecting an oracle. They then create the Funding Transaction to lock up the contract funds and generate CETs for all possible outcomes. The exchange of Adaptor Signatures for these CETs comes next, ensuring the contract's integrity. After signing and broadcasting the Funding Transaction, the contract lies dormant until the oracle provides its attestation. At this point, either party can execute the appropriate CET based on the outcome.
While this process introduces additional complexity compared to traditional multisig transactions, it ultimately relies on the exact fundamental mechanism of locking funds in a multisig output.
#Use Cases
With the technical explainer out of the way, one might wonder: What are these contracts actually good for? The potential applications are vast and span traditional finance to more exotic on-chain interactions.
Forward contracts represent one of the more straightforward applications. For example, Alice could use a DLC to agree to buy 5000 USD from Bob at a specific Bitcoin price on a future date. This agreement allows Alice to hedge against volatility and meet future USD obligations without losing sleep over price fluctuations. However, the amount of collateral required limits the range of price differences a DLC can handle. In a forward contract, if the price moves too far from the agreed-upon price, the collateral may no longer be sufficient to settle the contract fairly.
DLCs could also house more complex financial instruments on Bitcoin, such as options and derivatives. These contracts could replicate sophisticated trading strategies previously unavailable to Bitcoin holders, bringing tranches of financial engineering into the mix.
In fact, the oracle-based nature of DLCs lends itself particularly well to event betting and prediction markets. By leveraging external data sources, these contracts could facilitate wagering on various real-world events, from sports outcomes to election results.
However, it's crucial to note that while these applications show promise in theory, their practical implementation faces significant technical and regulatory challenges.
#Critique of DLCs
While DLCs' potential applications are intriguing, they're not without their critics. Let's peel back the layers and examine some of the key claims made by DLC proponents.
#On Privacy
DLC enthusiasts tout enhanced privacy as a major selling point. The idea is that contract details remain hidden from the blockchain, with even the oracles kept in the dark about specific contracts. That sounds great in theory, but is it true in practice? It's a bit like trying to hide an elephant under a napkin.
The primary advantage of DLCs lies in their ability to conceal the specific use of an oracle's judgment. This works great when secretly betting on the outcome of some event. However, this benefit disappears once a protocol such as dlc.link is implemented on top of the DLC. In such cases, the metadata necessary for the overlying protocol inherently reveals the purpose of the transaction and information about the participants.
NOTE: It is conceivable that privacy could be recovered even when the necessary metadata for such protocols is produced, but this requires substantial additional work that does not appear to be documented anywhere. If someone had actually published a ZKP method for doing this, we probably would have heard of it from DLC proponents.
In other words, while you can have privacy for bets or forward contracts, this does not extend to many proposed applications that do something more interesting with the assets locked in a DLC.
#On Decentralization and Security
DLC advocates quickly wave the flag of decentralization, claiming their creation eliminates central points of failure. By holding Bitcoin collateral in decentralized "escrows" (fancy talk for multisig UTXOs), they argue that intermediaries become obsolete and risk shifts to verifiable on-chain code.
But all that glitters ain’t gold. For starters, DLCs lean heavily on oracles. If an oracle goes rogue or gets hacked, it could wreak havoc on multiple contracts. This method appears far less robust than threshold custody, relying on an honest majority of a large number of signers. The failure of a single threshold signer may be more likely, but the failure of a majority would require a significantly deeper problem. In fact, only a threshold signature where a single party controls the majority of signers has the same single-point-of-failure characteristics. DLCs inherently restrict the possible recipients of the contract’s payout, but this can be achieved with ordinary multisignatures as well, and the oracle could collude with one participant to steal the full collateral. Sure, you could use multiple oracles to mitigate this risk, but that's like adding more cooks to the kitchen – it might help, but it also complicates things. In particular, if the oracles disagree on the outcome it can lead to a failure of the entire contract.
NOTE: Instead of using multiple separate oracles, it would be better to aggregate multiple sources into a single threshold oracle. This way, the honest majority can overcome individual oracles’ unavailability or disagreement, recovering the security and decentralization that basic DLCs lose. If four out of seven oracles say the price is 1050 while two others claim 1049 or 1051 and one has ceased to operate entirely, a threshold reconstruction of s_1050 is still perfectly doable.
Moreover, when compared to existing solutions like tBTC, DLCs might not be the decentralization darling they're made out to be. In fact, dlc.link cannot be minted by retail users, and the institutional minters are subject to KYC requirements. As a result, to most users dlcBTC is hardly distinguishable from similar wrappers relying entirely on institutional intermediaries. The main advantage DLCs have here over plain multisig constructions with similar output constraints appears to be for marketing. DLC.link’s blog holds numerous posts discussing the benefits that some other kind of DLC-based construction might have.
NOTE: DLCs couldn’t even provide privacy for the institutional minters because the attestation layer has to verify the collateral. DLC. link attestors are supposed to only listen and sign, but there appears to be no cryptographic mechanism preventing them from spying on the minters while still observably behaving in the exact same manner an honest attestor would. It’s like a VPN spamming sponsor reads on YouTube; they promise not to log your traffic, but how much do you actually trust them? The vanilla attestor software lacking such recording functionality guarantees nothing whatsoever. At best, it could use a “trusted execution environment,” of which there is no mention in the “DLC Attestation Network (TM)” documentation.
#On Flexibility and Interoperability
DLCs promise to usher in a new era of BitcoinFi and cross-chain interactions. It's a tantalizing prospect, but the road from theory to practice is paved with significant hurdles.
For example, imagine a fungible asset like DLCTBTC. If Alice sells her DLCTBTC to Bob, neither of them can pull them out unless Bob sells them back to Alice. Custody is traded for inflexibility. It's a bit like trying to fit a square peg in a round hole. This points to a fundamental limitation: while DLCs excel at locking funds based on external conditions, they struggle to create genuinely fungible, tradeable assets. It's as if they've solved one puzzle only to create another.
NOTE: This may be the real reason why retail users cannot mint dlcBTC, or at least a significant unmentioned factor contributing to it. With such a constraint, limiting minting to institutions that are able to deal with inflexibility is a reasonable decision.
In the end, while DLCs show promise in expanding Bitcoin's functionality, they're not the magic bullet some make them out to be. Like any novel development, they come with their own set of trade-offs and limitations.
#Additional Technical Challenges
DLCs face several technical hurdles that limit their practical application:
- Signature Explosion: The number of necessary signatures can become impractically large for contracts with many possible outcomes. Particularly in the forward contract use case, dividing and signing transactions for each and every individual possible value can lead to enormous numbers of signatures that need to be exchanged and stored. This can be mitigated to some degree with a supportive oracle, e.g. signing individual bits separately instead of the entire value, replacing a larger number of simpler transactions with a smaller number of more complex transactions.
- Lack of Built-in Order Matching: Current DLC implementations don't include mechanisms for matching parties who want to enter into contracts. This limits their practical use in creating liquid markets.
- Integration Challenges: Incorporating DLCs into existing Bitcoin wallets and services is a slow and arduous process. Oracles also need to support DLCs explicitly, even if they don’t need to know about the particular contracts being made.
#Future Outlook
As it stands, DLC technology is still in the proof-of-concept stage. No doubt, there are likely legitimate use cases where this technology is most appropriate. However, these are often overshadowed by scenarios in which it is easy to present a superficially convincing argument to non-technical readers about why DLCs could be utilized, despite not being the optimal solution for the task.
Thus, while DLCs offer intriguing possibilities for expanding Bitcoin's functionality, they are not a panacea for BitcoinFi, and in the absence of future technology, they lose their discreetness when used for this inappropriate application.
