path: root/6b/aa9e3faeaf0a9328d5f32ffafe8ed280a17d09

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 32446C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <WC-djV9Bhn2JE3cIjjp432LVwg0OBI3z4AZVxxLuplrNisfXMfIM48SnTKOTzzUYpz_KnJ04Q6OnG3_5lxXp4MqqYA1MJux4JnQ1jlpif_4=@protonmail.com>
In-Reply-To: <CALZpt+FQWWeVuJzye3oPeX+5myRpsT9BwGU8s=PeFcr-pn2ZTQ@mail.gmail.com>
References: <CAPfvXfK4PckDdKG4aLASF4p-E8L8YyAbD8M3S_Zwk=wOuA0vfA@mail.gmail.com>
 <CALZpt+FQWWeVuJzye3oPeX+5myRpsT9BwGU8s=PeFcr-pn2ZTQ@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <cold_pubkey>), 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 <hash> 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 (<cold_pubkey>, <hot_pubke=
y>), 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