MCCV: A full-featured safe using only CTV (Central Safe Module).

Author: ademan

Source: https://delvingbitcoin.org/t/ctv-only-vault-concept-v0-1-0-release/2539

I am pleased to announce the release of the first version of MCCV—my concept for a “ more complex CTV safe ”; it was developed using BIP-119 OP_CHECKTEMPLATEVERIFY (OP_CTV). MCCV demonstrates that a fully functional safe contract can be constructed using only OP_CHECKTEMPLATEVERIFY , without relying on more expressive covenant opcodes. While the final design is computationally burdensome and not very convenient, it successfully provides features such as deposit, delayed withdrawal, recovery, withdrawal speed control, and repetitive safe operations.

In summary, funds are deposited into a vault from a regular wallet in predefined increments; withdrawals are also made in predefined increments, and the time lock they face extends with each withdrawal. This relative time lock provides a challenge window during which pending withdrawals and the remaining funds in the vault can be cleared to a recovery key; the recovery key can then be used with a more secure storage device.

Because the time lock extends linearly with the amount of withdrawals, this safe deposit box contract provides a withdrawal speed limit enforced by a consensus mechanism, which can reduce potential losses.

Overview

Note : This is an experimental proof-of-concept software, and it is only used on testnets such as signet (or regtest).

The current implementation is a working command-line interface software, a proof-of-concept, written in Rust and dependent on BDK and rust-bitcoin . It runs on regtest and signet using Bitcoin Inquisition v29; Bitcoin Inquisition provides support for OP_CHECKTEMPLATEVERIFY , TRUC (topology-restricted transactions before confirmation), and "temporary anchors".

This implementation supports:

• Generate a safe
• Use a hot wallet to receive and spend money.
• Deposit a fixed amount of incremental funds into the safe.
• Initialize delayed withdrawals with a fixed-size increment
• Transfer mature withdrawals to a hot wallet.
• Restore the entire safe to a cold-stored recovery key.
• GitHub repository address: GitHub - LNHANCE-Expedition/mccv: More Complicated CTV Vault · GitHub
• User Guide: mccv/docs/user-guide.md at master · LNHANCE-Expedition/mccv · GitHub
• Protocol Details (WIP): mccv/docs/protocol.md at master · LNHANCE-Expedition/mccv · GitHub

characteristic

Preventing unauthorized withdrawals

Like all safes, funds withdrawn from this type of safe enter a challenge window: during this time, the user can clear the withdrawn funds and any remaining funds in the safe to a recovery key.

Withdrawal speed control

This type of safe not only provides a way to recover funds in the event of unauthorized access, but also adds a withdrawal speed limit enforced by a consensus mechanism.

Multiple operations

This agreement supports a considerable but limited number of deposits and withdrawals on the same safe. This makes this safe design far more flexible than a one-off safe design.

Backup

This type of safe can back up data into a very small, constant-size data set.

Major shortcomings

Complexity

This protocol could generate millions of transactions; it requires rigorous code quality checks and audits to achieve a basic level of trustworthiness. Moreover, its complexity itself is a risk, making the protocol less attractive for its target use case—large sums of money. However, this most worrying risk can be mitigated to some extent by having a cold storage/recovery key escape pod.

Calculation is arduous

The computational burden increases with the granularity of deposit increments, the number of increments allowed for simultaneous withdrawals/deposits, and the total number of operations supported by the vault. Any practice that improves user experience will lead to increased computational burden and on-chain transaction fees.

The process of creating a trust safe

The computational complexity of this approach leads to the need to establish trust. The device generating the safe must be powerful enough to enumerate the user's desired operations, and it must also be trustworthy. Currently, generating safe instances with practical parameters requires hardware with performance comparable to the latest commercial PCs or mobile devices, but these systems are difficult to trust. Offline PCs best meet this requirement, but offline PCs themselves can already meet users' security requirements to a considerable extent without the need for any complex safes. STARKs may be able to practically verify safes within a hardware signer, which I believe is an important direction for future work.

Withdrawing money requires two steps

Because each vault is pre-calculated, funds cannot be directly withdrawn to the recipient. Instead, matured withdrawals can be spent by a hot wallet, which can then forward the funds to the recipient. This means that if the hot wallet is compromised, matured withdrawals can also be stolen. It also means that authorizing a single withdrawal is complex because the final destination of the funds is not included in the withdrawal transaction. OP_VAULT and OP_CCV both solve this problem (in fact, they would completely render this design obsolete).

Privacy

Strict withdrawal speed controls require funds to be pooled into a single UTXO. This represents a significant sacrifice of on-chain privacy.

handling fee

This flaw is not inherent to the protocol, but rather stems from the design of this proof-of-concept implementation: the hot key is associated with the hot wallet key. Therefore, an attacker could drain your hot wallet first, preventing you from paying fees to confirm recourse/recovery transactions.

This problem can be mitigated by ensuring that the watchtower uses a different key and by allocating dedicated funds to pay for restoration transaction fees, regardless of whether the watchtower service is run by the user or a third party.

Agreement Overview

The detailed specifications of the agreement are still being drafted.

A vault is a large-scale DAG (Directed Acyclic Graph) composed of pre-computed transactions; the transitions between these transactions are enforced using OP_CHECKTEMPLATEVERIFY . The vault is configured with the following parameters:

• scale : Basic withdrawal and withdrawal increment. Each operation on the safe is a multiple of this amount.
• delay : The number of additional blocks that need to be waited for to retrieve each additional increment.
• max-withdrawal : The maximum number of items that can be withdrawn at once.
• max-deposit : The maximum amount that can be deposited at once.
• max-depth : The number of operations the safe can support (the depth of the DAG).

These parameters control the trade-offs between security, convenience, and pre-calculated costs.

history

This vault project began with an experiment: how likely is it to create a user-friendly vault using only CTV? It's generally believed that CTV alone is insufficient to construct an ideal reactive vault, but CTV can indeed be used to develop pre-computed state machines. These constructs can lead to a wide variety of on-chain contracts, the only limiting factor being pre-computation. In purely theoretical terms, CTV plus taproot can express extremely complex but ultimately enumerable transaction transition graphs, but this can only be achieved by exhaustively enumerating every possible state and state transition. In reality, this becomes computationally infeasible once the parameter set exceeds the strictly constrained size.

My findings suggest that this approach is practical for a small number of parameters, but the speed of pre-computation quickly degrades the user experience as the parameter set expands. Caching is feasible and should be implemented to mitigate latency in subsequent runs, but even then, the initialization computation of the safe can be quite lengthy. Therefore, the hope for a "virtually unlimited" safe, with far more parameters than any practically predictable use case, seems dashed. However, accepting some practical limitations (which can be explicitly communicated to the user), MCCV offers useful functionality.

Compare

This solution is neither the first safe design nor the first to utilize OP_CHECKTEMPLATEVERIFY . However, to my knowledge, it is the first publicly disclosed safe design that combines OP_CHECKTEMPLATEVERIFY and taproot in this manner.

simple-ctv-vault

As the name suggests, the " simple-ctv-vault " aims to be as simple as possible. It inspired my development of MCCV, as I wanted to see how practical more complex constructs could be. The simple-ctv-vault allows a UTXO to either withdraw to a hot address (with latency) or be swept to a cold address. This is still the basic principle of MCCV, except that the simple-ctv-vault only supports one-time deposits and withdrawals.

“Bitcoin Vaults” by Bryan Bishop

I really wish I had known about Bryan Bishop's " Bitcoin Vaults " sooner. This design is conceptually and directionally similar to MCCV. Like MCCV, it also divides the vault into several parts based on value, called "shards." It supports constrained vault operations, either enforced with a pre-signed transaction that destroys the private key, or via OP_CHECKTEMPLATEVERIFY , except that it was designed before taproot activation. Without taproot, increasing the number of spending paths would require using a larger witnessScript script (for spending transactions). Bryan carefully selected spending paths so that the vault can: push funds to cold storage; divide the vault into many parts; strip one part, leaving the rest in the vault. This last point is particularly similar to MCCV. My current intuition is that the ability of taproot to efficiently represent alternative spending conditions significantly reduces the need to divide the vault into many parts. Using MCCV, users can withdraw enough increments to meet their needs, while the remaining vaults protect the remaining balance. Taproot's efficiency also allows MCCV to deposit funds into existing vaults, something Bryan's protocol cannot do, although this comes at the cost of pre-calculating many states. Although the MCCV protocol design was finalized before I knew about Bryan's work, some similar design elements, such as dividing the vaults into multiple parts and stripping amounts during withdrawals, felt like finding a kindred spirit.

OP_VAULT and OP_CHECKCONTRACTVERIFY design

Hopefully, this won't cause any controversy regarding the restrictive terms opcodes; I simply want to point out that these opcodes will largely replace my design. Using these opcodes avoids all the pre-calculations that make this safe design seem daunting. Furthermore, they allow for single-step withdrawals, meaning the recipient can specify this in the withdrawal transaction. This facilitates thorough authorization performed by the watchtower and allows the recipient to directly collect their funds (although the recipient will need additional information to clear these outputs). That said, I believe OP_VAULT and OP_CHECKCONTRACTVERIFY are far less likely to be activated than OP_CHECKTEMPLATEVERIFY , thus warranting exploration of a design using only CTV.

Request feedback

I would greatly appreciate any feedback on the following:

• Overall protocol design
• This design choice versus a simpler design
• Overall Thoughts on Safes
• User Experience: This is only a proof-of-concept project, and there are some known user experience flaws, but all possible user actions are ready for testing. Please participate in the user guide.
• Performance and pre-calculated cost

in conclusion

While this approach has numerous drawbacks, it still offers interesting improvements in the security of managed funds. It provides a comparable user experience without relying on OP_VAULT and OP_CCV , especially if improvements are made in the following directions.

Future jobs

Many other projects are also catching my attention, so this isn't a commitment to dedicate myself to those areas anytime soon. However, there are some that I find particularly interesting and worth exploring as soon as possible.

Potential future jobs include:

• Watchtower software: All the features required for a watchtower are available in this command-line interface tool, but they are not yet integrated into a useful automation feature.
• Delegated Restoration: Allows quasi-trusted watchtower safes to initiate restoration operations by delegating only the ability to do so.
• Cache vault calculation: Significantly improves software responsiveness after the vault is initialized for production.
• CPU optimization: There are many optimizations, many of which are easy to achieve.
• Generalization: Adapt to software stacks to support other CTV state machine protocols.
• GPU acceleration: The parallel-friendly design of this safe also makes it suitable for acceleration using a GPU.
• It is expected to enable STARK-based verification for hardware signers.

The idea of STARK verification is very interesting. It would allow powerful consumer hardware to generate evidence of the vault and its formal correctness, while more secure hardware signers would use compact evidence to verify formal correctness.

(over)