zkPoH: Zero-Knowledge Proof-of-Hodl

The design of Zero-Knowledge Proof of Holdings (zkPoH) necessitates an explicit step to confirm the ownership of Unspent Transaction Outputs (UTXOs). This process involves the verifier issuing a unique challenge to the prover, who must then select UTXOs from a committed snapshot and sign the challenge with the keys controlling those outputs. The proof verifies not only the existence and cumulative value of these UTXOs but also the authority of the prover over them, ensuring that the values sum to meet a predefined threshold.

The current prototype of this system demonstrates the capability for Merkle inclusion and privacy-focused threshold logic, but it lacks a clear integration of the ownership verification step in the Noir circuit as noted should be detailed further in the README documentation. Two potential approaches have been proposed to enhance the privacy and security of these proofs. The first approach, labeled v0, involves an off-circuit check where the prover signs the challenge for each UTXO and the verifier externally verifies these signatures. Although simpler, this method could potentially expose details about the UTXOs or public keys used, thus compromising the privacy aspect of the transaction.

The second and preferred approach, v1, keeps the UTXO selections, public keys, signatures, and even the Merkle paths confidential within the circuit, which internally verifies the necessary conditions. This method ensures enhanced privacy as the verifier only sees the final proof and does not know which UTXOs were specifically utilized. This version is particularly advantageous for complying with Taproot by using Schnorr signatures for verification, and for broader Bitcoin script support, BIP-322-style message signing might be suitable, although integrating arbitrary script satisfactions within a ZK circuit presents more complexity.

Furthermore, the application of zkPoH in scenarios like the Lightning Network requires careful consideration of how proofs handle different types of UTXOs such as 2-of-2 multisig, MuSig2, or Taproot key-path. Each type might dictate specific proof requirements to adequately demonstrate control without revealing the underlying funding output details. The development needs to clearly define and implement these nuances in the proof of concept to ensure robustness and applicability in varied real-world use cases.