I DLC, Discreet Log Contracts o Contratti a Registro Discreto, sono smart contract basati su Bitcoin in cui due o più parti bloccano fondi in un indirizzo multisig, e l'oracolo pubblica le informazioni specificate in un momento specifico, come il risultato di una partita sportiva o la quotazione di un prezzo di un asset da parte di un exchange.
L'oracolo non ha bisogno di conoscere i termini del contratto. Il protocollo DLC rende le transazioni indistinguibili da molte altre transazioni Bitcoin e può essere eseguito all'interno di un canale Lightning Network.
Inoltre, i DLC sono argomentabilmente più sicuri dei precedenti metodi basati su oracoli perché un oracolo che si impegna in un falso risultato genera chiare prove di frode.

La parola discreet è stata scelta come gioco di parole partendo dal discrete log problem, il problema del logaritmo discreto che è un problema matematico fondamentale nell'ambito della crittografia e della teoria dei numeri, storpiando la parola discrete in discreet che si riferisce più all'aspetto della privacy.

Il fatto che le transazioni che creano e regolano il contratto possano essere rese indistinguibili da altre transazioni Bitcoin o possono essere eseguite all'interno di un canale Lightning rende i DLC più privati ed efficienti rispetto ad altri metodi di contratto basati su oracoli.
I DLC offrono un miglioramento rispetto ad altri tipi di smart contract in quanto il loro impatto sulla blockchain non è diverso da quello di una transazione multisig normale. Tuttavia, i DLC non risolvono completamente il problema degli oracoli, l'incapacità di incorporare dati del mondo reale in un contratto intelligente in modo affidabile.

Con i DLC due o più parti concordano di scambiare denaro a seconda dell'esito di un certo evento determinato da un oracolo (o da diversi oracoli). Per costruire un DLC, due parti bloccano fondi in un indirizzo multisig. Questi fondi possono essere spesi solo quando l'oracolo rilascia le informazioni specificate in un momento specifico. Dopo che l'evento si è verificato, l'oracolo pubblica un commitment o impegno sull'esito dell'evento che la parte vincente può utilizzare per reclamare i propri fondi. L'oracolo non ha bisogno di conoscere i termini del contratto (o persino che un contratto sia stato stipulato). Un oracolo per un DLC può essere qualsiasi tipo di feed di dati, come la pubblicazione da parte di un sito web del risultato di una partita sportiva o la quotazione di un prezzo di un asset da parte di un exchange.
Tuttavia, i DLC non risolvono completamente il problema degli oracoli, l'incapacità di incorporare dati del mondo reale in un contratto intelligente in modo affidabile, poiché si basano ancora su un oracolo affidabile per rilasciare dati veri.

La costruzione originale dei DLC era specifica per le firme Schnorr. Successivamente è stata sviluppata una versione per utilizzare adattatori di firma che sono compatibili con il sistema di firma ECDSA già esistente di Bitcoin prima dell'introduzione delle firme Schnorr.

Un DLC funziona utilizzando la firma dell'oracolo di un determinato messaggio come chiave privata, il che consente al vincitore della scommessa di firmare una transazione che spende i fondi che le due controparti hanno impegnato all'inizio del contratto.

Ad esempio, se Alice e Bob desiderano creare un DLC per scommettere sull'esito di un lancio di moneta, creano innanzitutto una transazione di finanziamento, in cui entrambe le parti inviano bitcoin, ad esempio 1 BTC ciascuno, a un multisig 2-su-2. Successivamente, Alice e Bob ottengono chiavi pubbliche le cui chiavi private sono appena state create dalla firma dell'oracolo di entrambi gli eventi - testa o croce nel caso di un lancio di moneta. Si noti che queste chiavi private non sono la chiave privata utilizzata per creare le firme degli eventi. Una firma non può essere utilizzata per derivare la chiave privata che l'ha creata.

Con queste chiavi pubbliche, Alice e Bob creano due transazioni di commitment o impegno, chiamate CET, Contract Execution Transactions o Contratti di Esecuzione, una delle quali spende i 2 BTC della transazione di finanziamento alla chiave pubblica testa e l'altra alla chiave pubblica coda. Entrambe queste transazioni richiedono firme da parte di Alice, Bob e la chiave pubblica testa o coda. Poiché né Alice né Bob hanno la chiave privata testa o coda, queste transazioni hanno solo 2 delle 3 firme richieste e rimangono non pubblicate sulla blockchain per il momento.

Dopo che l'oracolo determina il risultato del lancio della moneta, ad esempio testa, l'oracolo pubblica la firma corrispondente a testa e Alice o Bob utilizzano questa firma per derivare la chiave privata testa. Alice e Bob possono ora firmare solo il CET che invia i bitcoin alla persona che ha scelto testa. Il CET firmato viene pubblicato sulla blockchain e il vincitore della scommessa riceve i 2 BTC. Il CET che richiedeva la firma coda è obsoleto e viene scartato.

Per incentivare il perdente della scommessa a firmare e pubblicare la transazione, viene aggiunto bitcoin extra alla transazione di finanziamento da entrambe le controparti. Se la scommessa è di 1 BTC, ogni controparte potrebbe scommettere 1,5 BTC. Il vincitore riceverà quindi 2,5 BTC e il perdente avrà restituiti i suoi 0,5 BTC. Ciò consente di implementare una condizione di time lock, secondo la quale, se il perdente non ha firmato e pubblicato la transazione entro un certo tempo, il vincitore potrebbe inoltre reclamare i 0,5 BTC di garanzia del perdente.