Building a vault using blinded co-signers

This innovative approach emphasizes minimizing the information available to co-signers about transactions to enhance the protection of fund movements on the blockchain. The uniqueness of this system lies in its ability to ensure that co-signers are engaged in validating transactions based on preset policies, particularly verifying the correctness of a transaction's timelock via Zero-Knowledge (ZK) proofs before approval. The prototype is structured around four principal transaction types: vault_deposit, vault_recovery, unvault, and unvault_recovery, each pre-signed to cater to various scenarios involving the deposit, recovery, and use of funds within the vault. A significant feature of this setup is that it allows fund owners or their designated watchtower to redirect funds to a recovery address if an unauthorized access attempt is noticed, provided at least one signer strictly follows the protocol to guarantee fund security. For further exploration, detailed documentation and code have been made available on GitHub, accessible through documentation and prototype links. However, it's highlighted that this prototype is for testing environments only, such as regtest and signet, and not for real funds until thoroughly vetted. A challenge identified is the time-consuming process required for ZK proofs, especially in proving key and nonce aggregation adherence to the protocol without revealing sensitive details to co-signers. Efforts are underway to reduce this proving time significantly.

The initial part of the email acknowledges the recipient's work and expresses admiration for their efforts, indicating a positive reception and belief in the potential of blind co-signers to replicate specific functionalities on the Bitcoin platform. It specifically mentions the possibility of emulating certain Bitcoin script op_codes for Elf-trace and other fraud-proof applications, suggesting that this could significantly enhance the protocol's functionality and acceptance within the ecosystem. Highlighting the challenge of establishing trust in co-signers, the sender proposes a strategic approach to maximize their utility by emulating essential Bitcoin script op_codes. This strategy could enable the development of a robust protocol, possibly implemented using Trusted Execution Environments (TEEs), slashable bonds on alternative chains, or a combination thereof. The proposed simplicity of implementation would facilitate verification across different programming languages, potentially enhancing the protocol’s credibility and adoption. Furthermore, the visibility of these op_code executions on-chain is argued to be crucial for validating demand for such features and countering Miner Extractable Value (MEV) arguments. The sender stresses the importance of maintaining a track record of co-signers' honesty and liveness as a fundamental aspect of the system's trustworthiness.

In response, the recipient elaborates on generalizing the setup to accommodate more sophisticated ZK proofs within the protocol. They propose creating a taproot address that commits to a zk-verifier controlled by co-signers, allowing for proofs of valid spending according to committed policies, such as emulating covenants. This approach opens up possibilities for utilizing various proof systems, including TEEs, with the commitment uniquely identifying them. Building a reputation for co-signers with well-known public keys is considered crucial, as combining multiple reputable co-signers can achieve robust quorums without their mutual awareness. This discussion underscores the potential for achieving significant adoption and usage of the project, acknowledging the broader challenge of gaining widespread industry acceptance. The dialogue suggests that bootstrapping trust in co-signers could provide valuable insights into which op_codes might be considered for future soft forks, contributing to the ecosystem's growth and improvement.