This page contains information about upgrading from v70 LTS to the latest release. You may want to do this to get access to the latest features.

📘

While all our releases are production quality, we only guarantee that LTS releases will receive non-breaking patches. If you wish to minimise upgrades with breaking changes, we recommend that you use our latest LTS release (v70) and only upgrade when the next LTS release is available.

Upgrading from v70 to v71

Changes to Import/Export and Backup/Restore

There have been some changes to how import and export work. Prior to version 71, there were the following ways of exporting and importing keys:

• BackupKeyShare/RestoreKeyShare: Would do a local (unencrypted) export of a key share that could later be restored.
• ExportKeyShares/ImportKeyShares: Would export a (encrypted) raw key share and chain code to all players participating in the MPC protocol. This key share would be rerandomized, so to use the imported key, you needed all the shares.

In version 71 these methods have been changed:

ExportKeyShares/ImportKeyShares have been renamed to ExportKey/ImportKey to make it clearer that you are actually exporting the entire key. The functionality remains the same.

BackupKeyShare/RestoreKeyShare have been replaced by the new methods ExportKeyShare/ImportKeyShare. They work similarly to BackupKeyShare/RestoreKeyShare, but with a few significant differences:

• The exported key share is encrypted with a wrapping key
• The export can (optionally) include presignatures as well. If presignatures are exported, then they are removed from the source to reduce the risk of reusing a presignature.

These changes apply to ECDSA, Schnorr, RSA, AES, and HMAC. Note that only ECDSA and Schnorr support the ExportKeyShare/ImportKeyShare methods.

Key Import using Node's Own Wrapping Key

When an MPC node exports a key share, the share is wrapped using a provided public wrapping key. The node only accepts this key if it exist in a whitelist in the node's configuration. The node's own public wrapping key is now automatically part of this whitelist. This means that you can now always import key shares that were earlier exported by the node itself, without manually having to add the node's public wrapping key to the whitelist.

Upgrading from v71 to v72

Management API

In v72 we have introduced a new Management API, which means that the management endpoints for a Builder Vault node now looks like this:

/admin/pause - removed /admin/resume - removed /admin/health - moved to /management/health /admin/configuration/authinfo - moved to /management/configuration/authinfo /admin/configuration/auditsigningpublickey - moved to /management/configuration/auditsigningpublickey

In addition, the metrics server has been moved into /management/metrics

Furthermore there has been changes to the config file for the Builder Vault node:

• The sections [MetricsServer] and [ProfilingServer] have been removed
• A new section [ManagementServer] has been added
• The [Authentication] section has a new value DynamicAPIKeys If enabled it is possible to dynamically add and remove API keys using the management server. When dynamic API keys are used, you cannot use static API key.

When the management server is enabled, it now includes Swagger UI documentation, and a URL for downloading the OpenAPI yaml definitions, found under:

/management/docs

/management/openapi.yaml

There's a new way to get unauthenticated access to Management API. Specifying an empty API key under the management server API keys in the node configuration, grants unauthenticated access with the specified permissions. Previously you would need to enter a hash of the empty string to achieve the same result.

Debug information with duration

When running Builder Vault with a log level of DEBUG, many operations are now logged together with a duration indicating how long time the operation took. If the operations fails, then no duration is logged.