Add KIP-10 Transaction Introspection Opcodes, 8-byte arithmetic and Hard Fork Support

[biryukovmaxim]

Overview

This pull request implements KIP-10 by introducing transaction introspection capabilities to the Kaspa scripting language through a new set of opcodes. These additions require activation through a new fork parameter (kip10_activation_daa_score).

Added Opcodes (following Transaction struct field ordering)

Transaction Level

• OpTxInputCount (0xb3): Get number of inputs (Implemented)
• OpTxOutputCount (0xb4): Get number of outputs (Implemented)
• OpTxInputIndex (0xb9): Get current input index (Implemented)
• OpOutpointTxId (0xba): Get previous transaction ID (Reserved)
• OpOutpointOutputIdx (0xbb): Get previous output index (Reserved)
• OpTxInputScriptSig (0xbc): Get input script signature (Reserved)
• OpTxInputSeq (0xbd): Get input sequence number (Reserved)

UTXO Related

• OpTxInputAmount (0xbe): Get input amount (Implemented)
• OpTxInputSpk (0xbf): Get input script public key (Implemented)
• OpTxInputBlockDaaScore (0xc0): Get input block DAA score (Reserved)
• OpTxInputIsCoinbase (0xc1): Check if input is coinbase (Reserved)

Output Related

• OpTxOutputAmount (0xc2): Get output amount (Implemented)
• OpTxOutputSpk (0xc3): Get output script public key (Implemented)

Key Changes

• Added fork activation parameter kip10_activation_daa_score
• Added support for 8-byte integers via Kip10I64 type
• Modified script validation to support new opcodes when KIP-10 is activated
• Updated script tests to handle new opcodes and 8-byte integer support
• Added comprehensive example scripts demonstrating mutual transaction patterns

Example Usage

The example provided demonstrates common logic that should be used with the new opcodes. The script allows for two main scenarios:

1. Owner Scenario: The script checks if the input is used by the owner and verifies the owner's signature.
2. Borrower Scenario: The script allows the input to be consumed if the output with the same index has a value of input + threshold and goes to the P2SH of the script itself. This scenario also includes a check where the threshold is not reached, demonstrating the validation of input and output values.

For detailed code, refer to the example

Motivation

The introduction of these new opcodes and the hard fork support enhances the flexibility and functionality of the Kaspa scripting language.

These changes are part of the implementation of the KIP-10 proposal.

For more information, refer to the KIP-10 research document.

[michaelsutton]

Unrelated directly to this PR, but I noticed the following try_from is redundant:

impl OpcodeData<i32> for Vec<u8> {
    #[inline]
    fn deserialize(&self) -> Result<i32, TxScriptError> {
        let res = OpcodeData::<i64>::deserialize(self)?;
        i32::try_from(res.clamp(i32::MIN as i64, i32::MAX as i64))
            .map_err(|e| TxScriptError::InvalidState(format!("data is too big for `i32`: {e}")))
    }

The res.clamp expression can be safely casted as i32 due to the i32 bounds used within the clamp