kip-10

kip-0010.md

@@ -0,0 +1,143 @@
+```
+  KIP: 10
+  Layer: Consensus, Script Engine
+  Title: Extended mass formula for mitigating state bloat
+  Authors: TODO
+  Status: proposed, implemented in the rust codebase
+```
+
+## Abstract
+
+This KIP introduces four new opcodes to the Kaspa scripting language: `OpInputSPK`, `OpOutputSpk`, `OpInputAmount`, and `OpOutputAmount`. These additions enhance the flexibility and functionality of Kaspa's scripting system, enabling more complex script conditions and use cases, particularly in support of mutual transactions as discussed in the context of KIP-9.
+
+## Motivation
+
+Following the introduction of the extended mass formula in KIP-9 to mitigate state bloat, this proposal addresses the need for more flexible and powerful scripting capabilities. The new opcodes allow scripts to access input and output data directly, enabling the implementation of various advanced transaction types, including mutual transactions and other complex scripting scenarios.
+
+The introduction of these opcodes will:
+1. Enable more sophisticated smart contracts and conditional spending scenarios.
+2. Support the implementation of mutual transactions as discussed in KIP-9.
+3. Allow for more efficient handling of micropayments and recurring transactions.
+4. Enhance the overall flexibility and expressiveness of Kaspa's scripting language.
+
+## Specification
+
+### 1. New Opcodes
+
+The following new opcodes are introduced to enhance script functionality:
+
+1. `OpInputSpk`: Retrieves the script public key of the current input.
+2. `OpOutputSpk`: Retrieves the script public key of the output at the index corresponding to the current input.
+3. `OpInputAmount`: Retrieves the amount of the current input.
+4. `OpOutputAmount`: Retrieves the amount of the output at the index corresponding to the current input.
+
+### 2. Opcode Behavior
+
+#### 2.1 `OpInputSpk` and `OpInputAmount`
+
+- These opcodes push the script public key or amount (in sompis) of the current input being executed onto the stack.
+- They do not require an index parameter, as they always refer to the input currently being processed in the execution context.
+
+#### 2.2 `OpOutputSpk` and `OpOutputAmount`
+
+- These opcodes push the script public key or amount (in sompis) of the output with the same index as the current input onto the stack.
+- They do not require an explicit index parameter. The index is implicitly derived from the current input's index in the execution context.
+- If there is no corresponding output (i.e., the number of outputs is less than the current input index + 1), the script execution fails.
+
+### 3. Script Execution Context
+
+- The new opcodes operate within the context of the current input being validated.
+- For input opcodes, they directly access the data of the input being processed.
+- For output opcodes, they access the output data at the index corresponding to the current input's position.
+- This design maintains a clear relationship between inputs and outputs during script execution.
+
+### 4. Consensus Changes
+
+- The implementation of these opcodes requires a hard fork, as they introduce new functionality to the scripting language.
+- All nodes must upgrade to support these new opcodes for the network to remain in consensus.
+- The activation of these opcodes should be scheduled for a specific block height or timestamp, allowing sufficient time for the network to upgrade.
+
+## Rationale
+
+The introduction of these new opcodes addresses several key issues:
+
+1. Enables more complex script conditions, allowing for advanced transaction types.
+2. Supports the implementation of mutual transactions as discussed in KIP-9.
+3. Improves the flexibility of Kaspa's scripting language without introducing new address types.
+4. Allows scripts to make decisions based on the relationship between inputs and outputs.
+
+These opcodes are designed to work within the existing P2SH framework, maintaining compatibility with current address types while significantly expanding the possibilities for script design.
+
+## Backwards Compatibility
+
+This proposal requires a hard fork, as it introduces new opcodes to the scripting language. Older software will require an update to support these new features. Existing scripts and addresses remain valid, but cannot use the new functionality without being updated.
+
+## Reference Implementation
+
+A reference implementation of the new opcodes and example usage can be found in the following pull request to the rusty-kaspa repository:
+
+[https://github.com/kaspanet/rusty-kaspa/pull/487](https://github.com/kaspanet/rusty-kaspa/pull/487)
+
+Additional examples demonstrating the use of these opcodes can be found in:
+
+[https://github.com/biryukovmaxim/rusty-kaspa/blob/kip-10-mutual-tx/crypto/txscript/examples/kip-10.rs](https://github.com/biryukovmaxim/rusty-kaspa/blob/kip-10-mutual-tx/crypto/txscript/examples/kip-10.rs)
+
+## Example Usage
+
+To illustrate the practical application of the new opcodes, we present three scenarios: a threshold scenario, a shared secret scenario, and a mining pool payment scenario.
+
+### 1. Threshold Scenario
+
+This scenario demonstrates a script that allows for two types of spending conditions:
+
+1. Owner spending: The owner can spend the UTXO by providing a valid signature.
+2. Borrower spending: Anyone can spend the UTXO if they create an output with a value greater than the input by a specified threshold amount, sent to the same script.
+
+### 2. Shared Secret Scenario
+
+This scenario demonstrates a more complex script that allows for:
+
+1. Owner spending: The owner can spend the UTXO by providing a valid signature.
+2. Borrower spending with shared secret: A borrower can spend if they know a shared secret and create an output with a value greater than or equal to the input, sent to the same script.
+
+### 3. Mining Pool Payment Scenario
+
+This scenario demonstrates how the new opcodes can be used to optimize mining pool payouts, allowing for efficient M:N transactions where multiple inputs can be used to pay multiple participants.
+
+Concept:
+1. Pool Operation: The pool manages a KIP-10 compatible P2SH address for each participant, ensuring each address always has at least one UTXO.
+2. Payout Process: When a block is mined, the pool can efficiently distribute rewards using a single transaction with multiple inputs and outputs.
+
+The script for this scenario would allow two types of spending:
+1. Borrowing (used by the pool for payouts): Allows spending the UTXO if an output of greater value is created with the same script.
+2. Owner spending: Allows the participant to spend their funds normally with their signature.
+
+Advantages:
+1. Efficient M:N transactions: The pool can use M inputs (including the coinbase and participant UTXOs) to create N outputs (payouts to participants) in a single transaction.
+2. Reduced transaction costs: By combining multiple payouts into a single transaction, the overall transaction costs are significantly reduced.
+3. Improved payout frequency: The ability to efficiently batch payouts allows pools to distribute rewards more frequently without incurring excessive fees.
+4. Simplified pool operations: Pools can manage payouts more efficiently, streamlining their operational processes.
+5. Participant flexibility: Participants maintain full control over their funds while allowing the pool to optimize payouts.
+6. Enhanced scalability: As the number of pool participants grows, the efficiency gains from this approach become more pronounced.
+
+These examples demonstrate how the new opcodes enable complex spending conditions that were not possible before, allowing for innovative use cases such as threshold-based spending, shared control over UTXOs, and efficient mining pool operations.
+
+## Security Considerations
+
+1. Increased complexity in transaction validation, requiring careful implementation and testing.
+2. Potential for resource consumption attacks if scripts using these opcodes are not properly limited.
+3. Implications for transaction caching and optimizations, as scripts may now depend on broader transaction context.
+4. Potential privacy implications of allowing scripts to access more transaction data.
+
+Implementers should be aware of these considerations and implement appropriate safeguards, such as script size and complexity limits, to mitigate potential risks.
+
+## References
+
+1. KIP-9: Extended mass formula for mitigating state bloat
+   [https://github.com/kaspanet/kips/blob/master/kip-0009.md](https://github.com/kaspanet/kips/blob/master/kip-0009.md)
+
+2. Auto-Compounding Additive Addresses Discussion
+   [https://research.kas.pa/t/auto-compounding-additive-addresses-kip10-draft/168](https://research.kas.pa/t/auto-compounding-additive-addresses-kip10-draft/168)
+
+3. Micropayments Discussion (KIP-9 Follow-up)
+   [https://research.kas.pa/t/micropayments/20](https://research.kas.pa/t/micropayments/20)