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 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.