Anchors
Last updated
Anchors are the client-side validated structures that summarize all the data needed to validate contract commitments, which were described in the previous section. They are composed of the following ordered fields:
Txid
MPC Proof
Extra Transaction Proof ETP
Where:
Txid is the 32-byte ID of the transaction containing the Opret / Tapret commitment. Note that TxId could theoretically be reconstructed from the off-chain data of pointing to each and thus following the chain of . However, to simplify the validation task, they are included in the anchor.
The MPC Proof of the contract c_i consists of pos_i ,cofactor andMerkle Proof which were described so-called.
If an commitment is used, no additional proof is provided in this field, since, as described in , the verifier inspects the first OP_RETURN output finding the correct mpc::Commitement.
If a commitment is used, a so called Extra Transaction Proof - ETP must be provided, which consists of:
Internal Public Key P of the Taproot output used.
Partner node(s) of the Script Path Spend which is either:
The top left branch (in the : tHABC) if the Tapret commitment is on the right side of the tree.
The left and right nodes of the upper right branch (in the same example they are: tHAB and tHC) if the Tapret commitment is on the left side of the tree.
The , if used, to optimize the Partner node part of the proof.
In the next section, we will introduce concepts purely concerning the off-chain part of RGB, i.e. contracts, giving an abstract view of the partially replicated finite state machine that gives RGB a much greater expressiveness than can be achieved through Bitcoin Script without sacrificing confidentiality.