Date: Tue, 08 Mar 2022 00:57:21 +0000
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
Precedence: list

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