Bitcoin is usually not considered the blockchain best suited for self-executing conditional payments, better known as smart contracts. While it does support basic programmability to enable features like time locks and multi-signature (multisig) schemes, competing projects like Ethereum, Ethereum Classic or Qtum are often expected to better support more advanced applications.
However, a new wave of research is increasingly questioning this assumption. For example, Scriptless Scripts, a project spearheaded by Blockstream mathematician Andrew Poelstra, cleverly utilizes the magic of cryptography to move smart contracts off-chain, while leveraging Bitcoin’s security, but without requiring extensive smart-contract support on the Bitcoin protocol itself.
Along similar conceptual lines, Discreet Log Contracts (DLCs) could deploy another class of smart contracts on top of Bitcoin. A project by one of the authors of the original Lightning Network white paper, Tadge Dryja, and recently presented at Scaling Bitcoin Stanford, DLCs could realize blockchain-enforced insurance companies, futures contracts, dollar-pegged coins and much more.
Here’s how that works.
Many types of smart contracts essentially boil down to “bets.”
Let’s say, for example, that someone wants to insure himself against being unable to travel due to a potential pilot strike. That person can then “bet” there will be a strike. If there is no strike, the “bet” is lost as if it were an insurance down payment. If there is a strike, on the other hand, the “bet” is won, like an insurance payout.
As a more interesting example perhaps, people can also bet on the price of BTC relative to the US dollar: a futures market. If someone bets that the BTC price will go down, and the BTC price does go down, he “wins” more BTC; if the BTC price goes up, he “loses” some BTC. Interestingly, this can be structured to ensure that the person entering into these “bets” is practically guaranteed to end up with the same USD value in BTC regardless of what happens. This can, in turn, be used to realize a “stablecoin” with fixed USD value on Bitcoin's blockchain. (It should be noted that there are extreme examples where this doesn’t hold up, like a scenario where Bitcoin fails completely and BTC drops to zero dollars — but, in most cases, it works.)
However, while these types of smart contracts are interesting, they cannot be executed based on blockchain-based data alone. A blockchain cannot tell whether pilots are striking, nor what the USD/BTC exchange rate is. This requires data input from outside of the blockchain, and this is where “oracles” come in.
Oracles are essentially trusted sources of information; they provide data that cannot itself be “read” by a blockchain. This data can be inserted into a smart contract, which will then execute based on the oracle’s input.
Since the types of smart contracts described above need to rely on such external data sources anyway, it makes sense to leverage the trust in oracles in order to simplify a smart contract. Instead of more complex solutions, oracles can, for example, be “plugged into” a relatively basic multisig scheme.
As a simple example, let’s say that next summer Alice and Bob want to bet a bitcoin on the FIFA World Cup final between Argentina and Brazil. Alice thinks Argentina will win; Bob thinks Brazil will. To make this bet blockchain-enforceable, Alice and Bob both send one bitcoin to a multisig address that requires two of three signatures to spend the coins. One of these three keys is held by Alice, another key is held by Bob and the third key is held by the oracle.
If Argentina wins, Alice and Bob should both sign a transaction from this address that sends both bitcoins to Alice. Since this requires only two signatures, Alice and Bob’s signatures suffice, and the oracle never comes into play. (Needless to say, if Brazil wins it’s the other way around: Alice and Bob sign a transaction sending both coins to Bob.)
A problem arises only when the losing party — Bob — refuses to sign the transaction. It’s in this scenario that the oracle would use its third key to help Alice claim the two bitcoins. Importantly, exactly because this is an option, Bob really has no reason not to sign. (This is even more true if Alice and Bob put up some collateral so Bob gets refunded some of his BTC if he signs.)
Ideally, the oracle’s signature should hardly ever be needed at all; Alice and Bob can complete the bet on their own.
Still, the basic multisig and oracle solution has its weaknesses. For example, the oracle would probably have to be involved with setting up the bet; or at least it should be available to act as a sort of judge whenever needed. This means that the oracle could potentially be corrupted, for example, if Bob offers the oracle a share of the coins if they collude to steal both. And Alice and Bob also have no privacy from the oracle: the oracle will know exactly what they are betting on and how much they are betting. Meanwhile, the rest of the world can tell that Alice and Bob used an oracle for their bet (and, therefore, that it was a bet).
These are the problems that Discreet Log Contracts could solve. They maintain the benefits of the straightforward multisig and oracle solution — but eliminate most of its weaknesses.
As mentioned, Dryja, who is currently working for MIT Media Lab’s Digital Currency Initiative, is one of the authors of the lightning network white paper. His DLC project is based on a similar concept.
A key idea behind the lightning network is that two people can open a payment channel, allowing them to transact with each other. Such a payment channel utilizes Bitcoin’s basic programmability (like time locks and multisig addresses) and combines it with some clever tricks to commit transactions to other transactions, all without broadcasting them to the network unless needed.
Over time, as the people in the channel transact with each other, these payment channels are updated with new balances or “channel states.” Either party can then “drop” the latest channel state on the blockchain at any time and claim their balance whenever they want to. And importantly — this is where Bitcoin’s basic programmability is leveraged — both parties can only safely broadcast the latest channel state. If they try to cheat by broadcasting an earlier channel state, their counterparty can actually claim every single coin in the channel.
DLCs works similarly. But where a lightning network payment channel only lets the parties involved broadcast the most recent channel state, DLCs limit them to broadcasting only the channel state reflecting the correct outcome of a bet.
This is where the oracle comes in — but this time combined with some fancy math tricks.
As opposed to 2-of-3 multisig schemes where oracles act a bit like judges, oracles in DLCs more closely resemble broadcasters. For our World Cup bet, it would make sense that the oracle is a sports-betting service, a football news website, perhaps the FIFA or another entity that broadcasts the winner anyway and that is reasonably trusted not to lie about it.
Let’s say the oracle in this case is a sports-betting service that regularly publishes the score and winner of the World Cup final on their website. To enable a DLC, the same sports-betting service only needs to add a minor additional step.
Basically, this “broadcast oracle” has a public key and a private key. (A private key is really just a randomly generated number, while the public key is a seemingly random number derived from that private key.) This public key is published somewhere, most likely on the betting service’s website for anyone to find. The private key is, of course, kept private: This can be used by the oracle to sign a message. (Such a signature, too, is a seemingly random number but is derived from the private key in combination with the message.)
The possible outcomes of the bet are known as well: either Argentina wins the World Cup final or Brazil wins. The sports-betting service, therefore, announces that it will broadcast one of two very specific messages: “Argentina won” or “Brazil won.”
Now, what’s interesting about public key cryptography is that the sports-betting service’s public key can be used to figure out what a signature of the message — “Argentina won” or “Brazil won” — will mathematically “look like.” (“Look like,” in this case, doesn’t mean that Alice and Bob can produce the signature themselves, but they can calculate certain mathematical properties that it will have.)
Because Alice and Bob can calculate what the potential oracle signatures will “look like,” they can use it in their DLC.
First, before the World Cup final, Alice and Bob pay one bitcoin to a “funding transaction.” From this funding transaction, several potential transactions are constructed — but these are not yet broadcast over the network.
What the sports-betting service signatures “look like” is cleverly embedded in these several potential transactions, where each potential signature enables a different transaction. (Specifically, and somewhat unconventionally, what the signatures “look like” is used as public keys in key-pairs for the different transactions.)
In other words, knowing what the oracle’s potential signatures will “look like,” Alice and Bob can construct their payment channels such that the two different potential signatures can be used to validate two different channel states: one where Alice gets two bitcoins and one where Bob gets them.
Then, the actual oracle signature, which is published after the World Cup final is played, is used as private key to validate the winning transaction — and only the winning transaction. If the sports-betting service broadcasts a signature for “Argentina won,” Alice can take this signature, use it as a private key (in combination with her own private key) and claim the two bitcoins from the channel. If the oracle signs a message for “Brazil won,” Bob can. Meanwhile, if either tries to claim the bitcoins without the oracle signature, they will fail, and their counterparty can instead claim both coins.
Further, like lightning network payment channels, the outcome of the bet — two bitcoins for Alice if Argentina wins — can now also be broadcast by Alice and Bob as a fairly regular multisig transaction from the funding transaction. And indeed, exactly because Alice can enforce the outcome with the oracle signature anyway, there is little reason for Bob not to cooperate.
As a result, the “bet” is fully blockchain-enforced through the sports-betting service’s signature, while this service doesn’t need to do anything for this specific bet; it doesn’t even need to know it ever took place.
And, notably, while this bet is relatively simple (either Argentina wins or Brazil wins), in reality DLCs could allow for far more complex scenarios. Exactly because only a fairly regular multisig transaction is broadcasted in the end, it doesn’t really matter if a “bet” has two, 200, or 200,000 potential outcomes.
-> https://steemit.com/@blockchain-group
-> https://steemit.com/steem/@blockchain-group/trade-recommendation-steem
