One of the core value propositions of bitcoin is censorship resistance. As a result, bitcoin developers spend a lot of time thinking about how to design the protocol in such a way that is conducive to this goal. This blog post is going to discuss censorship resistance one level up the stack, the application level.
We at Suredbits have been working on designing a protocol called Discreet Log Contracts (DLC) that enables censorship resistant financial products to be built on bitcoin. For those that know a little bit about Discreet Log Contracts, this might sound like a paradox. How can something that depends on an oracle be fundamentally censorship resistant? Well, you are right, it is not. Censorship resistance is not binary, rather it exists on a spectrum. The purpose of this blog post is to compare and contrast the censorship resistance merits between DLCs and the next best technological tool available to bitcoin developers looking to build financial products — multisig contracts.
For the purposes of this blog post, unless otherwise specified, assume I am referring to a 2-of-3 multisig. At a very high level, there may not seem like there is much distinction between multisig and DLCs. DLCs at the bitcoin protocol level are a 2-of-2 multisig contract. An oracles key is used to encrypt your counterparties signatures, which gives us the effect of having a 2-of-3 multisig output.
While similar at first glance, the privacy, scalability and censorship resistance of DLCs all come from how the oracle is used. The single greatest feature of DLCs is that the oracle is not involved in the bitcoin transaction. Since the oracle is not directly involved in the transaction, they cannot selectively censor transactions. If they attest to an outcome, everyone has the same outcome applied to their transaction.
This is not the case with native 2-of-3 multisig on the bitcoin blockchain. Let’s take a look at a popular lending setup. One key is controlled by the borrower, one key is controlled by the lender, and a 3rd key is controlled by an arbitrator. This means 2-of-3 people in this multisig output need to agree to move the funds.
Notice, there is no smart contract that encodes the loan terms and conditions into the contract here. For any reason, if the lender and arbitrator collude, the borrower can be liquidated out of your loan. Even worse, you can be unfairly discriminated against. Here is an example:
Let’s say both Alice and Bob enter into a loan with a lender. They both borrow $50,000 USD and post 0.5 BTC as collateral in a 2-of-3 multisig output on the bitcoin blockchain. The lender stipulates in advance that they will liquidate the 0.5BTC of collateral if the bitcoin price drops below $30,000. One day later, Bitcoin price dropped to $30,000. Bob is good friends with the lender. Bob believes bitcoin price will rise and convinces his friend — the lender — to not liquidate him. Unfortunately for Alice, she is not good friends with the lender. The lender contacts the 3rd party arbitrator to sign off on liquidating Alice’s 0.5 BTC of collateral.
In this hypothetical, Bob was correct! Bitcoin price rebounded 2 days later to $50,000. This means Bob still has his 0.5BTC collateral in the multisig output, while Alice has nothing. With multisig, different users of the same smart contract can be treated unfairly. Alice was not extended the same opportunity that Bob received.
Using the same example above, with DLCs, both Alice & Bob would be liquidated. This is because the oracle does not know who is using them, they just blindly broadcast signatures. With a DLC, the liquidation logic is built into the smart contract. If the oracle broadcasts the signature that corresponds to $30,000, both Alice & Bob will have their collateral liquidated.
In the example above, I use a lending product example. However this same principle applies to all financial products built on the bitcoin blockchain with multisig. For instance, a government might want to censor the settlement of certain derivatives settling on the bitcoin blockchain. With multisig, they just need to convince the arbitrator(s) to censor the settlement. With DLCs, they need to censor all financial products based off of that oracle. They can still achieve financial censorship with DLCs, but you have to censor more people to achieve that effect.
There are caveats to this. For instance if you are the only user of an oracle, and the oracle is aware of that fact along with the party that wishes to censor you, you revert back to the exact same security model as multisig. This is why when selecting oracles you should bias yourself to oracles whose signatures are used in a wide variety of financial products.
Let’s give an example of this. Let us assume you are doing a DLC based on the BTCUSD market price. You can choose between two oracles, Olivia and Oliver.
Olivia’s oracle is used by tens of thousands of users. A lot of people depend on Olivia to settle their DLCs on the bitcoin blockchain. If Olivia were to not attest to the bitcoin price, tens of thousands of DLCs would fail to settle. This means it is very hard for Olivia to selectively censor only you. She can participate in mass censorship of all DLCs related to her oracle, but she can’t pick and choose who gets what.
The second oracle is Oliver. Oliver only has 3 users, one of which happens to be you. In Oliver’s case, it is very easy to make the choice to selectively censor a DLC. The stakes are that 2 other DLCs will not settle. It is also practical for Oliver to distribute oracle signatures to the other 2 users, while selecting to not distribute them to you.
The blowback on Oliver for censoring settlement of a DLC is relatively small, while Olivia will have thousands of unhappy users.
You can even choose to use multiple oracles for your DLC if you are concerned about censorship of your financial product. In our example above, you could use both Olivia and Oliver for your oracles. If you are interested in this topic, refer to our previous blog posts on how this can be achieved. This gives redundant censorship resistance so that just a quorum of the oracles need to broadcast signatures.
With the advent of new tools being built on top of Bitcoin, it is time for application developers to consider modernizing their technical stack. DLCs provide significant improvements in scalability, privacy, and censorship resistance of financial products built on bitcoin. With existing multisig setups, there is also trust in the arbitrator to treat you fairly in the case of disputes. DLCs make that trust model explicit by encoding the rules in the contract beforehand, and preventing the arbitrator (the oracle) from discriminating against you. You will be treated the exact same way as everyone else using the oracle.