Good morning Antoine, > Hi James, > > Interesting to see a sketch of a CTV-based vault design ! > > I think the main concern I have with any hashchain-based vault design is the > immutability of the flow paths once the funds are locked to the root vault > UTXO. By immutability, I mean there is no way to modify the > unvault_tx/tocold_tx transactions and therefore recover from transaction > fields > corruption (e.g a unvault_tx output amount superior to the root vault UTXO > amount) or key endpoints compromise (e.g the cold storage key being stolen). > > Especially corruption, in the early phase of vault toolchain deployment, I > believe it's reasonable to expect bugs to slip in affecting the output amount > or relative-timelock setting correctness (wrong user config, miscomputation > from automated vault management, ...) and thus definitively freezing the > funds. Given the amounts at stake for which vaults are designed, errors are > likely to be far more costly than the ones we see in the deployment of > payment channels. > > It might be more conservative to leverage a presigned transaction data design > where every decision point is a multisig. I think this design gets you the > benefit to correct or adapt if all the multisig participants agree on. It > should also achieve the same than a key-deletion design, as long as all > the vault's stakeholders are participating in the multisig, they can assert > that flow paths are matching their spending policy.
Have not looked at the actual vault design, but I observe that Taproot allows for a master key (which can be an n-of-n, or a k-of-n with setup (either expensive or trusted, but I repeat myself)) to back out of any contract. This master key could be an "even colder" key that you bury in the desert to be guarded over by generations of Fremen riding giant sandworms until the Bitcoin Path prophesied by the Kwisatz Haderach, Satoshi Nakamoto, arrives. > Of course, relying on presigned transactions comes with higher assumptions on > the hardware hosting the flow keys. Though as hashchain-based vault design > imply "secure" key endpoints (e.g <cold_pubkey>), as a vault user you're > still encumbered with the issues of key management, it doesn't relieve you to > find trusted hardware. If you want to avoid multiplying devices to trust, I > believe flow keys can be stored on the same keys guarding the UTXOs, before > sending to vault custody. > > I think the remaining presence of trusted hardware in the vault design might > lead one to ask what's the security advantage of vaults compared to classic > multisig setup. IMO, it's introducing the idea of privileges in the coins > custody : you set up the flow paths once for all at setup with the highest > level of privilege and then anytime you do a partial unvault you don't need > the same level of privilege. Partial unvault authorizations can come with a > reduced set of verifications, at lower operational costs. That said, I think > this security advantage is only relevant in the context of recursive design, > where the partial unvault sends back the remaining funds to vault UTXO (not > the design proposed here). > > Few other thoughts on vault design, more minor points. > > "If Alice is watching the mempool/chain, she will see that the unvault > transaction has been unexpectedly broadcast," > > I think you might need to introduce an intermediary, out-of-chain protocol > step where the unvault broadcast is formally authorized by the vault > stakeholders. Otherwise it's hard to qualify "unexpected", as hot key > compromise might not be efficiently detected. Thought: It would be nice if Alice could use Lightning watchtowers as well, that would help increase the anonymity set of both LN watchtower users and vault users. > "With <hash> OP_CTV, we can ensure that the vault operation is enforced by > consensus itself, and the vault transaction data can be generated > deterministically without additional storage needs." > > Don't you also need the endpoint scriptPubkeys (<cold_pubkey>, <hot_pubkey>), > the amounts and CSV value ? Though I think you can grind amounts and CSV > value in case of loss...But I'm not sure if you remove the critical data > persistence requirement, just reduce the surface. > > "Because we want to be able to respond immediately, and not have to dig out > our cold private keys, we use an additional OP_CTV to encumber the "swept" > coins for spending by only the cold wallet key." > > I think a robust vault deployment would imply the presence of a set of > watchtowers, redundant entities able to broadcast the cold transaction in > reaction to unexpected unvault. One feature which could be interesting is > "tower accountability", i.e knowing which tower initiated the broadcast, > especially if it's a faultive one. One way is to watermark the cold > transaction (e.g tweak nLocktime to past value). Though I believe with CTV > you would need as much different hashes than towers included in your unvault > output (can be wrapped in a Taproot tree ofc). With presigned transactions, > tagged versions of the cold transaction are stored off-chain. With Taproot trees the versions of the cold transaction are also stored off-chain, and each tower gets its own transaction revealing only one of the tapleaf branches. It does have the disadvantage that you have O(log N) x 32 Merkle tree path references, whereas a presigned Taproot transaction just needs a single 64-byte signature for possibly millions of towers. > "In this implementation, we make use of anchor outputs in order to allow > mummified unvault transactions to have their feerate adjusted dynamically." > > I'm not sure if the usage of anchor output is safe for any vault deployment > where the funds stakeholders do not trust each other or where the watchtowers > are not trusted. If a distrusted party can spend the anchor output it's easy > to block the RBF with a pinning. I agree. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
