Bitcoin, the programmable currency revolution: Discreet Log Contracts and their implications

Bitcoin’s DeFi Looks Promising – Crypto enthusiasts often have the preconceived notion that Bitcoin is unable to accommodate complex smart contracts. Although the programming language in which Bitcoin is encoded, the famous Script language, is quite rigid, it is simply wrong to claim that Bitcoin cannot serve more advanced needs of smart contracts.

One of the hottest and most anticipated means by the Bitcoin community is DLC’s (Discreet Log Contracts) . The idea was originally formulated through an academic dissertation in 2017 by cryptographer and Bitcoin researcher, Thaddeus Dryja. The second main contributor to the project and the software developer is Gert-Jaap Glasbergen. These two keyboard wizards work together at MIT (Massachusetts Institute of Technology) under the digital currencies initiative . It is also at one of the events organized by this branch of MIT in 2018 which aimed to explore the second layer solutions that the two developers are presenting for the first time. their project.

The challenges of smart contracts

They first mention the challenges of implementing smart contracts in the financial sector, namely their scalability, as well as the difficulty in collecting external information from the financial market. Another big challenge with smart contracts published on a public network such as Ethereum Code is confidentiality: it can indeed be very disadvantageous for two parties to make their financial bets visible.

The main idea of a DLC is the creation of a monetary contract which specifies the distribution of funds between two parties in contingency with conditions specified a priori of the formation of the contract. The outcome necessary for the determination is controlled by an external entity independent of the contractors, either an Oracle or a combination of Oracle chosen by the parties.

The DLC has a structure similar to a 2 of 2 multi-signature contract . The funds can only be distributed following the publication of a valid signature by the oracle which then specifies the results in it through an API ( Application Programming Interface) . The publication time of this data is programmed in advance. To avoid collusion between the oracle and one of the potential contractual agents, the conditions of distribution of funds are not visible to the oracle.

Graphic representation of a DLC by the firm Crypto Garage

The fact remains, however, that the oracle constitutes the unique link between the blockchain and the real world, so it must necessarily be a legitimate and reliable source of information . In order to mitigate the risk of corruption of an oracle, parties may decide to use several oracles at the same time and calculate the average result. This risk mitigation is not yet possible, but is already under development.

The Evolution of DLCs – The “Signature Adapters”

The first major readjustment of the DLC project was the adaptation of their general structures to allow the use of “Signature Adapters” . This type of signature allows a scaled and more anonymous integration of DLCs than the type of signatures used previously. In short, “Adaptors signatures” allow the creation of two invalid signatures by contractors, only one of which could ultimately be validated in conjunction with the signature issued by Oracle. This allows one-sided resolution from a cryptographic point of view.

Obviously, the science and cryptography of “Adaptors signatures” goes far beyond the objective of this article, which is intended to be more general. For those who would like to know more, I invite you to consult these more detailed explanations made by Tari labs.