Anchoring an SPV light client on another chain: checkpoint trust, retargeting and reorg handling

This system is still under development in a testnet phase and has not undergone a formal audit, highlighting the need for thorough review especially of its Bitcoin handling mechanisms. The protocol utilizes a Pay-to-Witness-Script-Hash (P2WSH) output for managing Bitcoin collateral, which includes a specially crafted redeem script. This script ensures security through provisions that allow cooperative release of funds post-loan repayment with signatures from all parties involved, or unilateral withdrawal by the depositor after a fixed period of about 37 days, facilitated by an absolute timelock.

In terms of transaction management, the protocol departs from a purely stateless design due to identified vulnerabilities in minimal proof validation strategies. Instead, it adopts an on-chain light client model that mandates more extensive proof of work verification than traditional models. This includes the use of a single trusted checkpoint which supports the submission of contiguous block headers subject to strict validation rules concerning 'bits', linkage to previously stored parent blocks, and adherence to timestamp requirements. Transaction proofs are required to align with a Merkle path verified against a header that has achieved at least six confirmations, adding layers of security but also increasing complexity and associated costs.

Several areas within the protocol's design have been earmarked for further examination and potential enhancement. These include the reliability of checkpoint trust, which currently depends on a single administrative setting and could benefit from a system incorporating multiple independent verifications to reduce risks related to central points of failure. Additionally, the protocol's approach to confirmation depths varies based on the size of deposits, posing questions about whether a fixed or scalable depth would be more effective. Other aspects needing attention are the choices between absolute and relative timelocks, strategies for managing fee variations in release transactions, cost implications of header submissions, and decisions around bounds for block reorganizations to maintain network stability.

For those interested in delving deeper into the technical framework and initial concepts behind the Writz Protocol, further information can be accessed through the whitepaper available here and the source code hosted on GitHub here. These resources provide detailed insights into the foundational structures and operational mechanics critical for a comprehensive understanding of the protocol’s capabilities and areas requiring improvement.