Documentation

On-Chain verification for Abort transition. It verifies that:

• All PTs have been burnt: The right number of Head tokens with the correct head id are burnt, one PT for each party and a state token ST.
• All committed funds have been redistributed. This is done via v_commit and it only needs to ensure that we have spent all comitted outputs, which follows from burning all the PTs.

On-Chain verification for CollectCom transition. It verifies that:

• All participants have committed (even empty commits)
• All commits are properly collected and locked into η as a hash of serialized tx outputs in the same sequence as commit inputs!
• The transaction is performed (i.e. signed) by one of the head participants
• State token (ST) is present in the output

Try to find the commit datum in the input and if it is there return the committed utxo

The close validator must verify that:

• Check that the closing tx validity is bounded by contestation period
• Check that the deadline corresponds with tx validity and contestation period.
• The resulting utxo hash is correctly signed or the initial utxo hash, depending on snapshot number
• The transaction is performed (i.e. signed) by one of the head participants
• State token (ST) is present in the output
• Contesters must be initialize as empty
• Value in v_head is preserved

The contest validator must verify that:

• The transaction does not mint or burn tokens.
• The contest snapshot number is strictly greater than the closed snapshot number.
• The contest snapshot is correctly signed.
• The transaction is performed (i.e. signed) by one of the head participants
• Party can contest only once.
• The transaction is performed before the deadline.
• Add signer to list of contesters.
• State token (ST) is present in the output
• Push deadline if signer is not the last one to contest.
• No other parameters have changed.
• Value in v_head is preserved

Hash a potentially unordered list of commits by sorting them, concatenating their preSerializedOutput bytes and creating a SHA2_256 digest over that.

NOTE: See note from hashTxOuts.

Hash a pre-ordered list of transaction outputs by serializing each individual TxOut, concatenating all bytes together and creating a SHA2_256 digest over that.

NOTE: In general, from asserting that `hash(x || y) = hash (x' || y')` it is not safe to conclude that `(x,y) = (x', y')` as the same hash could be obtained by moving one or more bytes from the end of x to the beginning of y, but in the context of Hydra validators it seems impossible to exploit this property without breaking other logic or verification (eg. producing a valid and meaningful TxOut).

Check if TxOut contains the PT token.