BTC Locking and Mirroring
Last updated
Last updated
In Kaon, we anticipate that users may want to utilize BTC in scenarios that are only implementable using Solidity Smart Contracts. To facilitate this, our chain supports a comprehensive BTC locking and mirroring process.
The user makes a view call to the Kaon contract (at address 0x0…1, where addresses 0x0…1 to 0x0…1000 are reserved). It sends a lock script of P2WSH (Pay-to-Witness-Script-Hash) or P2TR (Pay-To-Taproot) type for users to use it to lock BTC in the Bitcoin Network.
Output New Lock (P2WSH or P2TR): The initial transaction output with a new P2WSH or P2TR lock script.
Output Updated Lock by Kaon in BTC: Subsequent transactions update the lock script managed by Kaon in the Bitcoin network.
Output BRC/ERC New Record in Kaon: A new record is created in Kaon’s transaction history, involving an Inventory container to spread information throughout the chain.
A voucher (similar to an NFT) is issued, identifying the exact lock and linking it to the user’s transaction.
The user’s voucher tokens are managed and utilized as part of the locking and mirroring process.
The user makes a view call to the reserved Kaon contract address.
The user initiates a request to lock BTC using a specialized P2WSH or P2TR script.
Initial and subsequent transactions manage the lock script on the Bitcoin network.
(EVM chains only) A voucher is issued to represent the locked BTC.
A BTC owner has the ability to lock BTC using Kaon’s Mirror Transaction technology on the Bitcoin network. This is achieved by creating a Mirror Transaction, a Bitcoin transaction that commits any amount of BTC to be locked using Kaon-recognised Bitcoin lock scripts. These scripts lock the BTC and delegate its management to the Kaon Consensus Layer. A significant feature of this mechanism is the ability of the Mirror Transaction to include a subprogram within its script, enabling complex and repeatable operations on the Bitcoin side by utilising Kaon's consensus as a service.
Additionally, this approach provides resistance to attacks even when every validator is a current Validator and Witness Groups has became malicious.
Requirements for a Valid Mirror Transaction:
Signature Hash Type: Must use SIGHASH_ALL.
Note: For continuous loops, ALL | ANYONECANPAY is used.
Can contain more than one input.
Can contain one or more outputs. One of these outputs must be a Taproot output committing to the BTC mirroring scripts recognised by Kaon, henceforth known as the Mirrored Output. In the case of multiple outputs to be mirrored, each will be processed separately.
The subprogram output is a Taproot output that can only be spent through a script spending path. The key spending path is disabled by utilising the "Nothing Up My Sleeve" (NUMS) point as the internal key. The chosen point is the one described in BIP341, specifically:
This represents an impossible key that cannot be used due to mathematical limitations. It has been proven that this internal key does not have a known solution for the Taproot signature, effectively making it impossible to spend via the key path.
The mirror control output can be spent through three script spending paths (and their subpaths), each designed to facilitate specific functionalities within the Kaon protocol.
Where:
<LABEL_VERSION> is the version of the protocol (currently set to 2).
<LABEL> is the name of the protocol (KAON).
ESCAPE_CODE is a code used to terminate the current path processing in Bitcoin Core.
<Options> is a set of predefined parameters that will be added to the spend script for the mirrored transaction.
<Commitment> is the data needed to compose the payment script of the mirrored transaction (for instance, an EVM contract address and the bytecode of the function to call).
<Descriptor> is either an EET-EVM predefined descriptor code to execute a smart contract or a scriptsig templator (which could be extended later).
<AUX_Signer> is an additional lock script that must be applied within the mirrored transaction outputs (supports SELF to set it to the sender's spent outputs and TEMPLATE to use outputs from the Descriptor as predefined constants).
Notes:
An int128 can be used in <Commitment> in the format <SizeOfIntHighAsVarInt> <int64High> <SizeOfIntLowAsVarInt> <int64Low>.
The mirror transaction has a strict structure following the ESCAPE_CODE.
The ESCAPE_CODE is not intended to be any of the OP_SUCCESSx opcodes, as using these would compromise the security of a soft fork and is thus not recommended. Additionally, OP_RETURN is not available within a Taproot script. Various implementations are being explored for a proof of concept (PoC), and the final design will be presented upon completion of testing.
Future extensions to the <Descriptor> and <AUX_Signer> fields may allow for greater flexibility and additional features as the protocol evolves.
This Recognition Path serves as a technical, non-spendable script that allows the Kaon protocol to recognise and process mirror transactions' subprograms on the Bitcoin network. By embedding specific protocol identifiers and parameters within the script, the transaction becomes compatible with Kaon's mirroring technology, enabling advanced functionalities such as cross-chain operations and smart contract interactions.
The Recognition Path establishes a foundational framework for integrating complex operations within Bitcoin transactions.
This script branch allows the TSS sMPC Validator Group to transfer BTC, provided it has been approved by the TSS sMPC Witness Group.
Where:
<SenderPk> is the BTC sender's public key.
<VALIDATOR_GROUP> is the MuSig2 Threshold Signature Scheme (TSS)-based key for the corresponding Validators sMPC group. This involves a partial signing session through the Consensus Layer, with nonces calculated according to Byzantine Fault Tolerance (BFT) protocol.
<WITNESS_GROUP> is the MuSig2 TSS-based key for the related Witness sMPC group. It becomes enabled only after the VALIDATOR_GROUP signature; it cannot spend funds but can only confirm transactions.
Note: Using MuSig2 allows the protocol to configure and support a flexible number of required signatures, enhancing scalability and security.
In a future iteration, we will work on validating the compatibility of MuSig2 with TSS; One consideration is to utilize FROST (Flexible Round-Optimised Schnorr Threshold signatures) for improved efficiency and security.
This script enforces a multi-layered authorisation process for transferring BTC, enhancing security by requiring multiple and dynamically changed parties from a non-restricted pool of stakers to approve a transaction.
Validator Group Approval: The script begins by verifying the signature of the <VALIDATOR_GROUP> via OP_CHECKSIGVERIFY. The Validators sMPC group must collectively agree, following protocols in the Consensus Layer with nonces calculated according to BFT.
Witness Group Confirmation: The <WITNESS_GROUP> signature is checked using OP_CHECKSIG. This group cannot spend the funds but provides an additional layer of confirmation. Their signature becomes valid only after the Validator Group has signed, resulting in a hierarchical approval process. They ensure that the send outputs over the original outputs are in-line with Kaon requirements.
Timelock Enforcement: The 1 OP_CHECKSEQUENCEVERIFY introduces a minimal timelock of one block. This means the transaction cannot be included in a block until at least one block has passed since the transaction's sequence number was set, providing a brief delay as a security measure. In the future, this timelock may be increased to 2 blocks. This is crucial so that emergency exits can be be made possible (more details below).
This script incorporates several sub-routes to enhance flexibility and security:
a) Degrading in 6 Hours
After six hours, a failsafe sub-route becomes available. This timelock allows the BTC to be returned to the sender if the script used is outdated or remains unused.
Explanation:
Sender's Signature Verification: The script begins by verifying the sender's public key <SenderPk> using OP_CHECKSIGVERIFY. This ensures that only the original sender can reclaim the funds.
Timelock Enforcement: The 360 OP_CHECKSEQUENCEVERIFY introduces a relative timelock of 360 blocks (approximately six hours). This means the transaction can only be included in a block after this period has elapsed since the transaction's sequence number was set.
This sub-route acts as a safety mechanism, ensuring that funds are not indefinitely locked if the script becomes outdated or remains unused. It allows the sender to retrieve their BTC without requiring approval from the Validator or Witness groups after the specified time.
b) Degrading in 50 Minutes
After 50 minutes, another failsafe sub-route becomes available. This timelock enables the BTC to be returned to the sender if the address used is outdated or remains unused.
Explanation:
Sender's Signature Verification: The script verifies the sender's public key <SenderPk> using OP_CHECKSIGVERIFY.
Witness Group Approval: It then verifies the <WITNESS_GROUP> signature with OP_CHECKSIGVERIFY. This requires the cooperation of the Witness group, adding an extra layer of security.
Timelock Enforcement: The 5 OP_CHECKSEQUENCEVERIFY introduces a relative timelock of 5 blocks (approximately 50 minutes). This means the transaction can be included in a block only after this shorter period has elapsed.
This sub-route provides a quicker failsafe mechanism compared to the six-hour timelock but requires the Witness group's approval. It's particularly useful when the script is outdated or unused, and a prompt return of funds is desirable while still maintaining security through the Witness group's involvement.
c) Mark as Corrupted
This sub-route enables the immediate execution of an emergency procedure without any delays, effectively marking the mirrored output as corrupted.
Where:
<VALIDATOR_GROUP> is the MuSig2 TSS-based key for the relevant Validators sMPC group.
<WITNESS_GROUP> is the MuSig2 TSS-based key for the corresponding Witness sMPC group.
<Preimage_Announce_Corrupted> is a preimage of a transaction that signals the corrupted state.
In this sub-route, the Validators group provides a signature verified by OP_CHECKSIGVERIFY but the spend script of proposed outputs has anomalies. The Witness group then detects it and provides their signature, verified by OP_CHECKSIG, to initiate a recovery procedure. The inclusion of <Preimage_Announce_Corrupted> allows for an immediate action without any time delays or timelocks. This mechanism is crucial for situations where the mirrored output needs to be invalidated or revoked promptly due to security concerns or detected anomalies within the related spending output script. By marking the output as corrupt, it triggers an emergency protocol that safeguards the system from potential threats.
Future Work:
Extending Applicable Timeframes: We aim to extend the timeframe for preimaged transactions to enhance flexibility and security. This will allow for a more adaptable response mechanism in particular scenarios.
Protocol Integration: As this is a proof-of-concept version of the protocol, there is potential for this path to be merged with the Slashing path in future developments. Consolidating these mechanisms may streamline the protocol and improve overall efficiency.
The Emergency path is a critical mechanism designed to safeguard the network by allowing immediate revocation of delegation to Validators and Witnesses in response to malicious activity or protocol violations.
In this scenario, the Witness Group has signed a spending transaction that is considered malicious. The emergency script enables the following immediate action:
<WITNESS_GROUP> provides their signature, verified by OP_CHECKSIG.
<Preimage_Announce_Emergency> is a preimage of a transaction signalling the emergency state.
This allows the protocol to react promptly, invalidating the malicious transaction and preventing further harm.
If the owner of the lock detects misbehaviour, they can initiate the emergency procedure:
<SenderPk> is the BTC sender's public key, verified by OP_CHECKSIGVERIFY.
<Preimage_Announce_Emergency> signals the emergency state.
This empowers the owner to protect their assets when they suspect foul play.
When mirrorBTC has been sold on the Consensus Layer and needs to be transferred to a new owner, but the delegated Validators and Witnesses are inactive:
<Kaon_ConsensusLayer_mirrorBTC_Owner> is the public key of the new owner on the Consensus Layer, verified by OP_CHECKSIGVERIFY.
<Current_Epoch_Validators_ConsensusLayer> represents the current epoch's Validators on the Consensus Layer, providing their signature via OP_CHECKSIG.
360 OP_CHECKSEQUENCEVERIFY introduces a timelock of 360 blocks (approximately six hours).
This script allows the transfer of BTC to the new owner, even if the original delegated groups are inactive, by involving the current Validators from the Consensus Layer.
Explanation: The Emergency Recover process, the process is collaborative and requires consensus.
The Emergency transaction becomes active only when the required signatures are received by the Kaon Consensus Layer validators. The lack of constraints in the Emergency path means that after the delegation becomes active, anyone in the Bitcoin Network can send an Emergency transaction at any time without requiring permission from the Consensus Layer validators, even while the funds are locked. Separately, the emergency transaction may be submitted to Bitcoin Network as well using Kaon's mirroring mechanics.
Considerations:
Mirroring from Consensus Layer: Transactions can be mirrored from Kaon's Consensus Layer to the Bitcoin Network, ensuring synchronization between layers.
Design in Progress: As this is a proof-of-concept design, there are some known issues. The process of appointing an owner and integrating this information into the mirroring process is still under development.
Potential for Slashing: Problems with spending script signatures may lead to slashing penalties for responsible parties.
Signature Flexibility: The basic framework presented here can be extended. In practice, it may involve different sets of Validators and Witnesses representing smart contracts on the Bitcoin Network, especially when representation at the signature level is required.
Continuous Interaction: It is possible to produce a mirrored transaction on Kaon's Consensus Layer and have it mirrored into the Bitcoin Network. In that case it is important to use RBF or CPFP schemes to supply gas for a process. Otherwise the process will be paused, unlocking failsafe paths.
Important: Please note that this design is not final and may be optimised later. The protocol is still under development, and adjustments may be made to enhance security, efficiency, and fairness within the system. The balance between rapid response and collaborative decision-making is critical, and future iterations may refine these mechanisms to better serve the network's needs.
