Because the first unvault step is only encumbered with CTV and due to key reuse (which means the CTV template/hash are identical for a given amount), a network observer that sees the unvault spending tx could look for more utxos with the same scriptPubKey and unvault them too.
Making sure to always vary the CTV template (e.g. by avoiding key reuse, or theoretically even just [assuming taproot] by adding an OP_RETURN <nonce> tapleaf to the destination taptree) would fix this.
But it seems that requiring a signature by the hot wallet for the first unvault step would be a more robust solution that doesn't require giving extreme care to reuse avoidance. It is of course more expensive, though.
Because the first unvault step is only encumbered with CTV and due to key reuse (which means the CTV template/hash are identical for a given amount), a network observer that sees the unvault spending tx could look for more utxos with the same scriptPubKey and unvault them too.
Making sure to always vary the CTV template (e.g. by avoiding key reuse, or theoretically even just [assuming taproot] by adding an
OP_RETURN <nonce>tapleaf to the destination taptree) would fix this.But it seems that requiring a signature by the hot wallet for the first unvault step would be a more robust solution that doesn't require giving extreme care to reuse avoidance. It is of course more expensive, though.