One question our community often asks is: if DLCs lock Bitcoin into escrow for conditional payments, what validators are used to secure the escrow itself? Our customers are surprised to hear when we answer that our DLCs actually do not require separate validators. Unlike wrapping or bridging, Bitcoin locked in our DLCs are secured by the full hashrate of the Bitcoin network.
But how can this be, when all bridges require separate validators to lock and secure the assets? It's natural to want to think of DLCs as needing decentralized consensus. But DLCs actually utilize a game-changing innovation that makes them secure, trustless and private.
Unlike cross-chain bridges, our Bitcoin Attestation Layer does not form consensus. DLC nodes are not aware of each other and don't have to collectively agree. Instead of securing assets in a network, attestors translate instructions from a smart contract (e.g. on Ethereum) into settlement instructions for a Bitcoin transaction between two wallets.
This feature of DLCs protects the privacy of the transaction. Attestors do not know who the parties to the transaction are, the amount of Bitcoin locked, or whether there is a transaction at all. It's impossible to hack a specific transaction in a DLC because there is no traceability between the Bitcoin locked and the attestor nodes.
Customers implementing with us can choose from utilizing a single attestor or utilizing our multi-attestor layer. Multiple attestors ensure high availability: if a node goes down, the other nodes can still attest to a given result. The Attestation Layer that DLC.Link provides features a large collection of attestors run by multiple node operators to ensure maximal uptime and fast response times.
The math that makes this possible is described elegantly in Thaddeus (Tadge) Dryja's original whitepaper in 2018 (https://adiabat.github.io/dlc.pdf). To quote Tadge: “Discreet Log Contracts are a system which addresses the scalability and privacy concerns and seeks to minimize the trust required in the attestor which provides external data. The contracts are discreet in that external observers cannot detect the presence of the contract in the transaction log.”
For each potential outcome, the attestor publishes a one-time use number called a nonce. This nonce is published into a public space and the two parties (Alice and Bob) use these nonces create pre-signed conditional outcomes called CETs.
Later, when the outcome is broadcasted by a smart contract, the attestor publishes another number called a discrete log, also into the public space. Either party can use that discrete log to create a Bitcoin transaction and execute it.
To restate, DLCs pre-publish a set of numbers and later confirm one of numbers. But, they don’t know which parties are using the numbers, why they’re using them, and they don’t know when a transaction has happened (or if one has happened at all).
Unlike an oracle network, the attestation layer does not publish any price feeds, data feeds or execute application logic. Instead, attestors are all fed from the smart contract and the oracles that they use. Although we have a strategic partnership with Chainlink, our customer can choose which oracle they choose to trust.
This is why DLCs are so powerful. Bridges depend on their own validator networks, which make them subject to hacking, regulatory control and other vulnerabilities that could lead to users losing funds. Once Bitcoin is moved into a bridge or a sidechain, its security benefits are diminished.
Join us as we enable a Trillion dollars of Bitcoin capital to be used in smart contracts. Contact us: