Open Tx Protocol Brainstorm: (4) An Implementation Proposal

Serial articles on this topic:
Open Tx Protocol Brainstorm: (1) OTX in General
Open Tx Protocol Brainstorm: (2) Design a Practical Protocol on CKB
Open Tx Protocol Brainstorm: (3) Scenarios Analyzing on CKB

As mentioned in previous series articles, I suggest the OTX signature to cover scope level 2 of raw transactions to fit various user scenarios. We need a data package to indicate the verifier how to check the fields that a OTX signature covers.

Data Structure

Compared with secp256k1_blake160_sighash_all, this proposal adds a sighash_coverage_array field before the signature to identify which fields the signature covers.

The sighash_coverage_array field consists of a list of tx_component, which is a 3-byte package with the following structure.

Label here is the category ID of the component in a transaction. And it also serves as an end mark.

label meaning index_code mask
0000 sighash_all any any
1111 end of list any any
0001 output index of output cell mask
0010 input index of input (cell) cell mask
0011 input index of input (cell + since) cell mask
0100 input index of input (outpoint) outpoint mask
others reserved / error

The cell index is a 12 bit uint number, which allows up to 4096 input or output in a single transaction.

The cell mask is a 8 bit hash mask to set which fields in a cell to be covered by signature.

cell mask bit field in cell
0 capacity
1 type.code_hash
2 type.args
3 type.hash_type
4 lock.code_hash
5 lock.args
6 lock.hash_type
7 data

The outpoint mask is used to set the fields in outpoint mode of input.

outpoint mask bit field in outpoint
0 tx_hash
1 index
2 since
others reserved / error

Verification Logic

The Lock with this OTX protocol will use the following verification process.

  • Group transaction inputs by Lock, and load witness for every group
  • Read the first 3-byte package in witness, if its label is equal to 0000, then hash the whole transaction as the input of signature verification, or
  • Initialize hash data by the input cells with the specific Lock
  • Read every tx_compenont until the end package with 1111 label
  • Update the hash data with every cell field that the tx_compenont identified
  • Continue to extract the signature from the witness
  • Process to verfiy the signature validity

Multi-party Interaction

For two or more parties who want to interact with each other to combine their otx into a valid transaction, they should follow these rules.

  • Every participator assembles their own open transactions, setups the sighash_coverage_array, and provide the signature.
  • The final aggregator combines the open transactions, re-arrange their inputs and outputs, and modifies the index_code in sighash_coverage_array correspondingly.
  • The aggregator verifies and broadcasts the combined transaction.

Can we add the following 2 more masks for the sake of simplicity in coding?

  • 0xFF in cell mask bit means hashing all fields in a cell(including data)
  • 0xFF in outpoint mask bit means hashing all fields in an outpoint.

I think the cell mask bit has already enabled the 0xFF as a full hashing indicator (bit 0~7 means every possible field in a cell).

And 0xFF for outpoint mask hashing all fields is reasonable. Thanks for the implementation.

First, I didn’t realize that it’s actually a bit mask, I misinterpret them as direct value to use. Will fix this.

Second, I think we can use 0xFF as a special value in both cases. If one is specifying individual fields, each field will be loaded and processed separately, however if one uses 0xFF, we can read the whole CellOutput/CellInput directly to save us huge amount of cycles. That’s why I suggest we explicitly define 0xFF in both masks: since they will be processed differently than just including certain fields.

1 Like

Agreed :100: