From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2068BC000B for ; Sun, 6 Mar 2022 23:15:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 07E7C817A7 for ; Sun, 6 Mar 2022 23:15:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67lxGez9gHRy for ; Sun, 6 Mar 2022 23:15:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9053D81765 for ; Sun, 6 Mar 2022 23:15:54 +0000 (UTC) Received: by mail-yb1-xb31.google.com with SMTP id z30so14827770ybi.2 for ; Sun, 06 Mar 2022 15:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zjOKts7H4/jk0TfxniesGuDrJDDMRIJg1VH8t+w5Nq0=; b=ZU8F6vG/9z7s0Rtms2VCUoetesp0SKDOZ+ENKdti6CgsAr36vMgL/+cV3VESJAqii+ IIDJb2IjvV7eATdG3PWemm+dzPrmDuft1GPdPSV7vFPUVDFrq8M5UKrQ/syHwnAyV5si zw+e4O8IJwQJmiHpXEEr3iVFeyYmkocbaMOxcHuHqxWkTeGoh77AtzFVWVsKNZLb9joo RFJMpmc9H2cwRnvgffm+cdKN3BbFoHH7u0HkeRczeDMQ7LZjQ7TOmZrvcNqzplLTJniH tOJ8DcIlSxbTS20myRQpN9mgjYX0xzvvOJnsBNmyKSdJX/OAML6C3PtCS/zn9t1stpRB r71g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zjOKts7H4/jk0TfxniesGuDrJDDMRIJg1VH8t+w5Nq0=; b=78MAdl6cRk3m0p9SBnLbmTyjDmrHEhKazSQKjvv0vq1d/6lXbiCRBnX/Y5Vr/IADmf mWA1um6hGoGBHcRRheRBudexCfstddypluTsLqpGDwSBoiSbJ2mXRuHmTPwAOdYlrj+r MW2scNSlRKs/szrFZPIqDoDKoL4Spd9OzB9IfgUPbnIBvYVfeI5/rp2n5NATPbgy8Xvz As4hrSkHui5TDLKdANBSQbjwIcnbjFrObNyNl+0ZtnUsI1Z7+9I9MpC4AXJKqqPpaWp0 D+2O5i23LPXQjZX2DnOVRzqq6qRpmeVgqP1+k6VjA7nBF4nKxpDnSDKylwPgjpqsK6/8 DtkQ== X-Gm-Message-State: AOAM531eHZTmTYHz21GTC29QOHwYd6Fx69RjloINkN3QpGRRKnYFqz4I 9mYIyLH1VXuO8KskBbDFWEVzS3Ex4Gi+TyoLHmNqUsjnZmg= X-Google-Smtp-Source: ABdhPJydyZuMHpqGD6x0lILC/FPDfcZGbwz1kQuQ+o6LRIOceQwyDEbPV9a07rW7YRMWKFQgiseuvVfJUPJ4dmjcJyA= X-Received: by 2002:a5b:4ce:0:b0:61d:c863:d3c8 with SMTP id u14-20020a5b04ce000000b0061dc863d3c8mr6038288ybp.467.1646608553421; Sun, 06 Mar 2022 15:15:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Sun, 6 Mar 2022 18:15:41 -0500 Message-ID: To: "James O'Beirne" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000e92cec05d994edd4" X-Mailman-Approved-At: Mon, 07 Mar 2022 17:42:31 +0000 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: Sun, 06 Mar 2022 23:15:56 -0000 --000000000000e92cec05d994edd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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 ), 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. "With 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 (, ), 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. "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. Can we think about other criterias on which to sort vault designs ? (I would say space efficiency is of secondary concern as we can expect vault users as a class of on-chain space demand to be in the higher ranks of blockspace "buying power". Though it's always nice if the chain is used reasonably...) Antoine Le dim. 6 mars 2022 =C3=A0 12:35, James O'Beirne via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > A few months ago, AJ wrote[0] > > > I'm not really convinced CTV is ready to start trying to deploy > > on mainnet even in the next six months; I'd much rather see some real > > third-party experimentation *somewhere* public first > > In the spirit of real third-party experimentation *somewhere* in public, > I've created this implementation and write-up of a simple vault design > using CTV. > > https://github.com/jamesob/simple-ctv-vault > > I think it has a number of appealing characteristics for custody > operations at any size. > > Regards, > James > > > [0]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019= 920.html > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000e92cec05d994edd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi James,

Interesting to see a sketch of a CTV-base= d 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 tra= nsaction fields
corruption (e.g a unvault_tx output amount superior to t= he root vault UTXO amount) or key endpoints compromise (e.g the cold storag= e key being stolen).

Especially corruption, in the early phase of v= ault toolchain deployment, I believe it's reasonable to expect bugs to = slip in affecting the output amount or relative-timelock setting correctnes= s (wrong user config, miscomputation from automated vault management, ...) = and thus definitively freezing the funds. Given the amounts at stake for wh= ich vaults are designed, errors are likely to be far more costly than the o= nes we see in the deployment of payment channels.

It might be more c= onservative to leverage a presigned transaction data design where every dec= ision point is a multisig. I think this design gets you the benefit to corr= ect or adapt if all the multisig participants agree on. It should also achi= eve 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 p= aths are matching their spending policy.

Of course, relying on pres= igned transactions comes with higher assumptions on the hardware hosting th= e 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 t= o 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, bef= ore sending to vault custody.

I think the remaining presence of trus= ted hardware in the vault design might lead one to ask what's the secur= ity advantage of vaults compared to classic multisig setup. IMO, it's i= ntroducing the idea of privileges in the coins custody : you set up the flo= w 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 privi= lege. Partial unvault authorizations can come with a reduced set of verific= ations, at lower operational costs. That said, I think this security advant= age is only relevant in the context of recursive design, where the partial = unvault sends back the remaining funds to vault UTXO (not the design propos= ed here).

Few other thoughts on vault design, more minor points.
=
"If Alice is watching the mempool/chain, she will see that the unv= ault transaction has been unexpectedly broadcast,"

I think you = might need to introduce an intermediary, out-of-chain protocol step where t= he unvault broadcast is formally authorized by the vault stakeholders. Othe= rwise it's hard to qualify "unexpected", as hot key compromis= e might not be efficiently detected.

"With <hash> OP_CTV,= we can ensure that the vault operation is enforced by consensus itself, an= d the vault transaction data can be generated deterministically without add= itional storage needs."

Don't you also need the endpoint sc= riptPubkeys (<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 requirem= ent, just reduce the surface.

"Because we want to be able to re= spond 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 wo= uld imply the presence of a set of watchtowers, redundant entities able to = broadcast the cold transaction in reaction to unexpected unvault. One featu= re which could be interesting is "tower accountability", i.e know= ing 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 p= ast value). Though I believe with CTV you would need as much different hash= es than towers included in your unvault output (can be wrapped in a Taproot= tree ofc). With presigned transactions, tagged versions of the cold transa= ction are stored off-chain.

"In this implementation, we make us= e of anchor outputs in order to allow mummified unvault transactions to hav= e their feerate adjusted dynamically."

I'm not sure if the = usage of anchor output is safe for any vault deployment where the funds sta= keholders 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 t= he RBF with a pinning.

Can we think about other criterias on which t= o sort vault designs ?

(I would say space efficiency is of secondary= concern as we can expect vault users as a class of on-chain space demand t= o be in the higher ranks of blockspace "buying power". Though it&= #39;s always nice if the chain is used reasonably...)

Antoine

Le= =C2=A0dim. 6 mars 2022 =C3=A0=C2=A012:35, James O'Beirne via bitcoin-de= v <bitcoin-dev@= lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
A few months ago, AJ= wrote[0]

> I'm not really convinced CTV is ready to start tr= ying to deploy
> on mainnet even in the next six months; I'd much= rather see some real
> third-party experimentation *somewhere* publi= c first

In the spirit of real third-party experimentation *somewhere= * in public,
I've created this implementation and write-up of a simp= le vault design
using CTV.

=C2=A0 =C2=A0https://github.com/jamesob= /simple-ctv-vault

I think it has a number of appealing char= acteristics for custody
operations at any size.
Regards,
James


[0]: htt= ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019920.h= tml
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000e92cec05d994edd4--