3.3.1. Tapret commitments

Tapret commitment is structured as an OP_RETURN-based script, containing the multi-protocol commitment, placed inside an unspendable script path within taproot script tree. Thus, the script/commitment is never exposed to the external world inside bitcoin transaction or blockchain data (neither in script output nor witness); and only scriptPubkey of the transaction output contains a commitment to the actual tapret data created with the standard taproot procedure defined by BIP-341.

The tapret commitment script (tapret leaf script) always consists of 64 bytes: this allows distinguishing of tapret leaf script from a data used in production of taproot branch hash, such that the proof of the absence of an alternative tapret commitment can be validated by simple comparison of the first of the child node hashes to the tapret leaf script prefix.

The leaf with the tapret leaf script is always put into a leaf the same depth of the taproot script tree, and this depth is 1 (in 0-based indexing of depth levels, where depth 0 corresponds to the merkle tree root). The commitment is always put into the rightmost node of the tree by using consensus ordering of the nodes, as it is defined in BIP-341 merkle path construction (lexicographic ordering). This precise definition of the possible place of the commitment allows to prove the uniqueness of the commitment, i.e. the absence of any alternative tapret commitment in the same tree.

If at depth 1 in the rightmost position of the tree another taproot node is present (either leaf script or branch), an additional branch node is created with both tapret leaf script and the parent of the rightmost depth-1 node becoming its children.

If the original taproot script tree does not have depth 1 nodes on its right-side (in terms of consensus lexicographic ordering of each branch child hashes), a subtree (tapret subtree) consisting of repeated tapret script leaves is created and inserted at the depth of the last node of the tree on the right-side merkle path. The height of the subtree is selected to put the taproot script leaves at depth 1.

Since addition of the new node will change the merkle hashes of all its parents, and the merkle hash value is used in the lexicographic ordering of the tree, this operation with 1 - 1/(2 ^ 1) = 50% probability will make just inserted tapret subtree merkle root to be non-rightmost node of the modified tree. Since the deterministic nature of the tapret commitments requires ability to prove the absence of any alternative commitment in the same tree, two components are used to keep the determinism of the commitment position and ability to prove its uniqueness.

First, a special one-byte variable (nonce) is added to the taproot leaf script, which allows "mining" the hash value in a way that the added subtree will appear at the right-side of the tree. At depth 1 there might be only 2 possible tree position, and 256 iterations (per one nonce value) should be enough to solve the issue.

Second, if it was not possible to solve the issue with the nonce, a special uniqueness proof is produced, which ensures that none of the nodes at depth 1 on the right side of the tree does not contain alternative commitment. This proof includes leaf script (for leaf nodes) or two child node hashes (for branch nodes) for each of the nodes right to the tapret leaf script.

The tapret commitment is put into a transaction output scriptPubkey as a modified BIP-341 output key value, which is produced from the same internal key and new merkle root of the taproot script tree containing the embedded tapret commitment. The number of the transaction output with the commitment, if multiple taproot outputs are present in the same transaction, must be deterministically defined by an upper-level protocol using the present tapret commitment scheme.

Internal key value, merkle proof and uniqueness proof are combined to construct tapret proof, passed to the validators as off-chain data for client-side validation.