Bitcoin Cash has capabilities that are not available in any other Bitcoin fork

The new OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY opcodes added to Bitcoin Cash in the November 2018 upgrade hard fork allow for interesting new forms of transactions. In this article, I explore one such transaction type: multi-party escrow with a “blind” referee (also called an “oracle”). I also propose a new transaction standard, Pay To Escrow Script (P2ES), to describe this transaction type. I have released an extension to the popular Bitcore Node.js module, bitcore-lib-cash. This module, called Jeton Lib allows easy construction and spending of P2ES transactions.

Applications

The application for a P2ES transaction is any scenario where funds deposited to a (P2SH) BCH address should be dispersed to a particular party based on the outcome of some future event. That outcome is signified by the signing of a particular message by a referee who is chosen beforehand by the participants in the escrow transaction. The most recognizable example of such an application, and therefore the one used in this article, is sports wagering. In the simplest sports wager, one party wagers that one team will win a contest while his counter-party wagers that the opposing team will win. The referee (oracle) publicly broadcasts a signature of the message associated with the victorious team at the end of the contest.

Prediction markets of all kinds, including futures trading, can be facilitated by P2ES transactions.

Pay To Escrow Script

A P2ES transaction consists of one or more depositors and one or more possible beneficiaries. There can be more than one referee (to provide redundancy), but typically only one referee will be used. Any ScriptPubKey (output script) logic can be used so long as it evaluates to true for the following stack format for the ScriptSig (input script):

Winning Message Referee Signature Winner Public Key Signature For Winning Public Key

The input script itself will appear as:

[signature] [public_key] [referee_signature] [winning_message]

In Jeton Lib the scriptPubKey logic operates in the following manner:

Performs a check to see if the winning message is one of the messages included in the escrow If the message is valid for the transaction, performs OP_CHECKDATASIGVERIFY for the message, referee public key, and referee signature. If the operation succeeds (outcome is validated), performs a standard Pay To Public Key Hash (P2PKH) operation for public key associated with winning message and provided transaction signature and public key.

Additional logic such as timelocks and multiple referees is possible with the same input script format. Because the output script are non-standard, Pay To Script Hash (P2SH) must be used. The advantage of P2SH is that every P2ES contract has an associated address, the format of which is indistinguishable from existing multi-signature addresses.

Funding The Escrow

A P2ES transaction being used in an application such as a wager has an important differentiating factor from the transactions commonly used on BCH in that such an escrow needs to be funded by two individuals who may not have trust between them.

If two individuals have significant trust between them, they can simply generate the contract and verify that the P2SH hash matches the agreed upon ScriptPubKey. If it does, then both parties can simply fund the escrow by sending funds to the associated address. This is no different than sending funds to a multi-signature address and is supported by most (if not all) wallets.

The escrow can also be funded in a trustless manner by leveraging the SIGHASH_ANYONECANPAY signature type. An excellent, easy to understand explanation of the various signature types can be found here. Trustless escrow funding can be accomplished in the following manner:

Both parties to a wager construct and sign individual transactions which share exactly the same outputs. One of these outputs is the P2ES output. The signature type for all inputs is SIGHASH_ALL | SIGHASH_FORKID | SIGHASH_ANYONECANPAY . The total input for each transaction should be less than the total output — therefore each of the separate transactions is invalid on its own One party transmits his signed transaction to his counter-party (or a trusted third party), who then proceeds to combine the two transactions, creating a valid transaction where the input amount is greater than the output amount. This is possible because the inputs are using the SIGHASH_ANYONECANPAY signature type The valid, merged transaction is broadcast to the BCH network

The challenge with this method of merging inputs is facilitating change outputs. One method for mitigating this issue is for the parties to include only inputs that do not need an associated change output. This can be done by broadcasting a preparatory “splitting” transaction before constructing the P2ES funding transaction. The splitting transaction can create an output with “exact change” (required percentage of output plus portion of miner fee) which can be used as an input in the P2ES transaction. Bitcoin Cash’s ultra-low fees and 0-conf capabilities make this a viable solution.

Jeton Lib

Jeton Lib can be used in place of (or alongside)bitcore-lib-cash. It adds functionality to construct and spend P2ES transactions of the kind detailed above. The extended functions are described in the module’s documentation. The module also includes an example, similar to what has been described in this article, that does the following: