Open Tx Protocol Brainstorm: (1) OTX in General

Background

Open Transaction (OTX) is a deliberately constructed portion of transaction, which can be combined together to form a valid transaction. It is not a simple slice of a valid transaction. Firstly, OTXs are signed by participants to restrict the final transaction to their intentions, like predefined output amount, receiver address, and so on. Sencondly, one OTX can be freely combined with other OTXs as long as the combined TX follows the constraints defined by the OTXs.

OTX is important for off-chain multi-party collaboration. Every participants’ intentions acheive simultaneously. Here follows several examples.

  • Alice agrees to spend her 1 BTC only if Bob receive 1.5 BTC
  • Alice agrees any one spend her 10 USDT if she receives 100 CKByts
  • Alice signs a smart contrat call action, while its operator pays for the mining fee
  • Candidate collects off-chain votes from users, form a valid multi-input-single-output transaction on-chain.
  • One board member agrees to proceed a payment only if other members also agree it.

OTX is a critical infrastructure for UTXO based blockchains (such as Bitcoin and Nervos CKB). It’s not applicable on account based blockchains (such as Etheruem). For account based blockchains, off-chain multi-party collaboration has to rely on cryptographic mechanisms, since they only allow one initiator for every transaction.

Sighash in Bitcoin

OTX is firstly introduced by Bitcoin through one byte sighash non-script argument in its signature. Sighash is not partial signed bitcoin transaction (aka PSBT), which is an interchange format for Bitcoin transactions that are not fully signed yet, together with relevant metadata to help entities work towards signing it.

image
* Image from libbitcoin documents.

As shown above, sighash is part of bitcoin signature, and signed together with (partial) transaction data. There are six types of sighash defined in Bitcoin.

Sighash Type Marker Signature Coverage
SIGHASH_ALL 0x01 default, all input and output
SIGHASH_NONE 0x02 all the inputs, but none of the outputs
SIGHASH_SINGLE 0x03 all inputs, and exactly one corresponding output
`SIGHASH_ALL SIGHASH_ANYONECANPAY` 0x81
`SIGHASH_NONE SIGHASH_ANYONECANPAY` 0x82
`SIGHASH_SINGLE SIGHASH_ANYONECANPAY` 0x83

Take SIGHASH_SINGLE | SIGHASH_ANYONECANPAY as an example, it signes exactly one input and one output. Raghav Sood gave a great description to this sighash type and it’s user journey.

This allows Alice, who holds 100 COIN to sign an input authorizing the movement of 100 COIN, and an output to an address she controls with a value of 1 BTC. She then publishes this incomplete and invalid transaction (since there are no inputs for 1 BTC). We call it an open transaction.

Anyone who wishes to purchase 100 COIN for 1 BTC can then add an input >= 1 BTC, an output claiming the 100 COIN (remember, Alice’s output only claims the BTC), and any change outputs if required. This then makes a complete tx, which can be broadcast to execute the sale trustlessly.

User Scenarios of OTX on CKB

User scenarios of Bitcoin sighash are very limited. Firstly, there are only six types of sighash, covers a few circumstances. For example, it only constrains all, none or one of the inputs/outputs in a transaction, so one cannot pay to more than one addresses by authorizing only one input in an OTX. Secondly, Bitcoin supports multi assets and smart contracts badly, however, the best scenarios for off-chain collaboration are assets swap and user defined interactions.

IMHO, OTX on CKB is very promising in such user scenarios:

  • DApp operators pay transaction fees instead of users.
    • Users sign DApp calls OTX, and its operators add inputs as tx fees.
  • Atomic swap for different UDTs on CKB.
    • Alice signs a 10 UDT-A input and a 5 UDT-B output with her controlled address, and wait for someone completing the OTX.
  • Users pay transaction fees by UDT instead of native tokens.
    • One needn’t to hold any native token if he/she can pay tx fees by UDT.
    • One signs a zero fee otx with some extra USDTs, and anyone can append another otx with an input contains some native tokens as the transaction fee and an output contains these USDTs as his/her reward.
  • DEXs that match users otxs
  • Coinjoin-like TX pravicy enhancement
    • Support not only payment TX mix, but also general-purpose TX mix.

An otx protocol or standard should be defined to facilitate off-chain collaberations. It will dramatically improve collaberation efficiency and increase layer 1 TX throughput. In the future two parts of this topic, I will share my thoughts on CKB transaction structure and a preliminary design of otx protocol on CKB. I’m looking forward to hear your ideas.

8 Likes

Bitcoin has improved this feature in segwit, see details in bip-0143. However, this BIP does not change the mechanism and the semantic of the field Sighash.

1 Like

If I understand right, here should be output instead of input ?

In Bitcoin sighash schema, the signature in an input can only authorize (cover) zero / one / all outputs.

1 Like

What a magical protocol OTX is! Here I have two quick questions.(tbh I haven’t read the other pieces of OTX)

1.What does that means?

Does it mean that DEX could match the difference buying or selling between different tokens? like the pro uniswap that doesn’t limit in the scope of ERC-token?

2.How to operate OTX? By verifying type script (and lock script) on CKB? or should we use this protocol on off-chain environment like channel ?
(Finding the answer here :Open Tx Protocol Brainstorm: (2) Design a Practical Protocol on CKB)

Yep, here is a demostration: Open Tx Protocol Brainstorm: (3) Scenarios Analyzing on CKB Layer 1.5 DEX

1 Like