Distributed Log Contracts allow two or more participants to fund a contract that pays amounts according to outcomes determined by an Oracle. These have been explained elsewhere: On distributed Oracles, DLC's and prediction markets with peercoin
In this post, I will outline how DLCs can be implemented utilising ANYPREVOUT (APO), MuSig2 and FROST to provide major improvements over existing designs:
- Once a DLC is funded, a participant is always able to obtain their payout if the Oracle attests to an outcome, or a refund if the Oracle does not provide cooperate. Previous designs were not secure and required a level of trust in counterparties.
- DLC execution only requires a single on-chain key and signature.
- Oracles can be distributed over large distributed entities reducing reliance on single actors.
- DLC privacy is enhanced, revealing nothing more to chain-observers than a regular Taproot single-key spend in the best case, or that APO was used in the worst case.
Existing Designs
Existing DLC designs require that participants create an output for a Funding Transaction (FT) that they collectively control as an N-of-N. Basic designs use a multi-sig output and more advanced designs use MuSig2. In either case, existing designs require that the FT is signed before any Contract Execution Transactions (CETs) or the Refund Transaction (RT).
Participants may refuse to sign CETs or the RT after the FT is completed. They may hold other participants to ransom or they may lose their wallet making it impossible for them to co-operate. Existing designs require participants to deposit collateral to incentivise signing of transactions so they can receive their collateral, however there is still possibility of intentional or accidental misbehaviour.
The risk that CETs or RTs may not be signed, makes existing designs dangerous.
In addition, existing proposals for Oracles either use a single-party which is subject to misbehaviour, requires N-of-N which is subject to non-performance, or requires complex combinatorics to combine T-of-N oracles.
The design I propose here, solves these issues thanks to ANYPREVOUT (APO) which was recently activated on v0.15, and FROST. The Noosphere software shall allow for the coordination of distributed Oracles using FROST.
Innovative Atomic DLCs
Here I will outline the process for a new type of DLC that is fully atomic. This means the DLC will be fully completed or it will not exist. The FT is signed last after all CETs and the RT are in place. This means there is no risk of blackmail or non-performance and no collateral is required.
Decision of Contract Terms
The first step can be much the same as the existing designs, however no collateral needs to be decided. All participants must agree upon the terms of the DLC including:
- The public keys of participants.
- What Oracle to use.
- The particular event that the Oracle will attest, as pre-announced and signed by the Oracle.
- The payouts for each outcome.
- The deadline of the DLC, after which refunds may be obtained.
In a simple 2-party DLC, one party can act as a maker (offerer), and another party can act as the taker (acceptor). The maker will propose the terms and the taker can choose to accept or not.
For simplification, DLCs can initially use a single event and provide CETs for every possible outcome for this event. Using a combination of events may allow for more complex DLCs such as providing arbitrary precision for numerical outcomes.
The existing DLC designs require that Oracles provide a signature for an outcome, but this is not compatible with ROAST. Therefore oracles will create keys for each possible outcome and share the public keys to DLC participants which they can use to produce adaptor signatures. Oracles will construct and share the private key (discrete log) for a given outcome to allow an adaptor signature to be decrypted to complete a given CET.
Output Construction
All participants need to construct a Taproot output controlled by all of them. To compress required on-chain signatures and keys to one per DLC, MuSig2 can be used to aggregate the keys of all participants into a single key. Alternatively an N-of-N multisig with OP_CHECKSIGADD can be used but this requires more space and gives less privacy.
MuSig2 is assumed in this design as it has benefits. Compared to multi-sig, it allows there to be a single on-chain signature and key. It allows the Taproot key-path to be used which looks indistinguishable from regular Taproot single-key spends. It involves a simpler process to generate N-of-N keys compared with FROST.
The aggregated key should be used for both a key-path key and a script-path APO key with OP_CHECKSIG. The key-path spend will allow participants to hide that APO is being used if they all agree to create a key-path settlement transaction. The APO script-path will allow CETs to be presigned and any participant may broadcast a CET after an Oracle private-key is revealed.
A modified secp256k1 library such as secp256k1-zkp can be used to create MuSig2 keys, where the library supports adaptor signatures which are necessary for DLCs.
Contract Execution Transactions & Refund Transaction
Once the Taproot output is created, it is possible to create CETs using APO which spend from this output without specifying the previous outpoint of an FT. All CETs for every possible outcome must be created and signed using MuSig2 with the Oracle adaptor points (public keys) for the given outcomes.
Additionally a time-locked RT must be created and signed which returns funds to participants minus fees. The timelock should be set beyond the expected event date in case the Oracle does not provide a private-key for an outcome.
Funding Transaction
Only once all CETs and the RF are created should participants begin to sign a
Funding Transaction. This transaction must include the agreed input amounts from all participants and spend to the Taproot output which is valid for all of the CETs and RF. Only once all participants have provided their signed inputs will the DLC become active and the FT can be broadcast to the network.
Execution
Parties to a DLC will listen to an Oracle feed for outcome private-keys. The Oracle will use Noosphere to construct the private-key for a given outcome, requiring a threshold of the Oracle FROST participants. Once a private-key is revealed, the adaptor signature in a CET can be completed and a DLC participant may broadcast the transaction.
However, once a key for an outcome has been provided, DLC participants can avoid revealing the fact that APO was used in a CET by unanimously signing a key-path transaction that looks like a regular Taproot key-path transaction.
If oracles do not provide a key in time, the RF may be broadcast once the timelock is reached.
Distributed Oracles
Existing designs typically assume a single-party Oracle with a single key or they assume a combination of MuSig2 keys. FROST makes it possible for a threshold of Oracle participants to discover a shared private-key. This allows for distributed oracles with minimal complexity and maximal privacy.
Noosphere currently allows distributed key generation (DKG). However, I will need to add the ability for a threshold of participants to construct private keys.