From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 32446C000B for ; Tue, 8 Mar 2022 00:57:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 3094C41754 for ; Tue, 8 Mar 2022 00:57:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUcauHet6VUE for ; Tue, 8 Mar 2022 00:57:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by smtp4.osuosl.org (Postfix) with ESMTPS id A84EF4175F for ; Tue, 8 Mar 2022 00:57:32 +0000 (UTC) Date: Tue, 08 Mar 2022 00:57:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1646701049; bh=a81Av9raszzczc1xVL0ueDG68XJNTXX1KZrJXRdrkG0=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=REd3OLw4AdlPZny3WGDH9iVNKhajrG8HaLLUzolkStzzP2UB2Cityv5e8WcD9xt2x wIOPTPY17+SAbwfJMk8LknwmDcdTW3UEJniLVhIZNG2PXQW735gUU44XJsNLAfWvWv CK+XqXO+E+XctV23EiI8tzXYXAXv951+Hl5kFFzAkrPrQtGe2MfDDvN9AQDv5ZMHRh N2ANX92cX56Abc3BMDcpyvxHHgWWAw4tJVB9qMhEA1EmO4qmEWpD8+12tpgSv/RHhg FczMeaRBk9hg6alX9C8vE8gJy8zUmdxPI/N/8NdaBrkxCi3nyU2IQMhc1wPVsprtXq eMcOaOdjzcHlg== To: Antoine Riard , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] CTV vaults in the wild X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2022 00:57:34 -0000 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 va= ult 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 UTX= O amount) or key endpoints compromise (e.g the cold storage key being stole= n). > > Especially corruption, in the early phase of vault toolchain deployment, = I believe it's reasonable to expect bugs to slip in affecting the output am= ount or relative-timelock setting correctness (wrong user config, miscomput= ation 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 de= sign 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 asse= rt that flow paths are matching their spending policy. Have not looked at the actual vault design, but I observe that Taproot allo= ws 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 t= o 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 assumption= s on the hardware hosting the flow keys. Though as hashchain-based vault de= sign imply "secure" key endpoints (e.g ), as a vault user you'= re still encumbered with the issues of key management, it doesn't relieve y= ou to find trusted hardware. If you want to avoid multiplying devices to tr= ust, 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 mi= ght lead one to ask what's the security advantage of vaults compared to cla= ssic multisig setup. IMO, it's introducing the idea of privileges in the co= ins custody : you set up the flow paths once for all at setup with the high= est 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 w= ith a reduced set of verifications, at lower operational costs. That said, = I think this security advantage is only relevant in the context of recursiv= e 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 tr= ansaction has been unexpectedly broadcast," > > I think you might need to introduce an intermediary, out-of-chain protoco= l step where the unvault broadcast is formally authorized by the vault stak= eholders. Otherwise it's hard to qualify "unexpected", as hot key compromis= e 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 OP_CTV, we can ensure that the vault operation is enforced b= y consensus itself, and the vault transaction data can be generated determi= nistically without additional storage needs." > > Don't you also need the endpoint scriptPubkeys (, ), the amounts and CSV value ? Though I think you can grind amounts and C= SV 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 o= ut our cold private keys, we use an additional OP_CTV to encumber the "swep= t" coins for spending by only the cold wallet key." > > I think a robust vault deployment would imply the presence of a set of wa= tchtowers, redundant entities able to broadcast the cold transaction in rea= ction to unexpected unvault. One feature which could be interesting is "tow= er accountability", i.e knowing which tower initiated the broadcast, especi= ally 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 nee= d as much different hashes than towers included in your unvault output (can= be wrapped in a Taproot tree ofc). With presigned transactions, tagged ver= sions 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 t= apleaf 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 deployme= nt where the funds stakeholders do not trust each other or where the watcht= owers 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