---
robots: noindex, nofollow
---

# 2024-11-25 Wolf Update

## MuSig2 availability in the Bitcoin `secp256k1` crate API

- The last update to [the PR](https://github.com/rust-bitcoin/rust-secp256k1/pull/716) was November 23.
- It looks like necessary upstream dependencies have been resolved and work is proceeding on final integration of the PR.
- I couldn’t find any planned release date.

## FROST availability in the ZF Foundation `secp256k1` crate API

- [Release 2.0.0](https://crates.io/crates/frost-secp256k1) on October 23 appears to include this functionality.

## `gstp` Crate

- Now fully supports `Event` as a first-class object.
- Breaking change: crate objects (`SealedRequest`, `SealedResponse`, `SealedEvent`) all now use `XIDDocument`s to identify senders and access their public keys.
- The `gstp` crate still needs to be published to GitHub and crates.io.

## `bc-envelope`: Envelope Signatures With Metadata

- Envelopes can now be signed including an optional `SignatureMetadata` object, which is any set of assertions.
- All previous APIs work exactly the same, and verifying signatures that have metadata works transparently, verifying both the metadata signature and the payload signature.
- The metadata in the envelope includes the payload signature and all of this MUST be signed by the same private key that made the payload signature.

### Example

Without Metadata:

{
    "Hello."
} [
    'signed': Signature
]

With Metadata:

{
    "Hello."
} [
    'signed': {
        Signature [
            'note': "Alice signed this."
        ]
    } [
        'signed': Signature
    ]
]

So if the object of the 'signed' assertion is wrapped, the wrapped envelope MUST be the payload signature with the metadata added as assertions, and that wrapped envelope MUST itself be signed by the same key that made the payload signature.

Right now the set of assertions is completely unconstrained and no specific types of metadata assertions are specially supported. Determining what “standard” set of signature metadata to support is TBD.

- This work has been pushed to the GitHub repo but not yet released on crates.io.

## `bc-xid`: XID Documents with Private Keys

I have added proof of concept code to the XID crate to demonstrate how `XIDDocument`s can carry private keys as well as public keys.

### Example

Unsigned `XIDDocument` with only public key:

XID(71274df1) [
    'key': PublicKeyBase [
        'allow': 'All'
    ]
]

Unsigned `XIDDocument` that includes the corresponding private key:

XID(71274df1) [
    'key': PublicKeyBase [
        {
            'privateKey': PrivateKeyBase
        } [
            'salt': Salt
        ]
        'allow': 'All'
    ]
]

Things to note:

- The `'privateKey'` assertion has been salted to decorrelate the digest of the private key.
- The *whole* assertion is salted, not just the object, so it can be elided in its entirety.
- If this envelope is deserialized, the `XIDDocument` will not only include the `PrivateKeyBase` but also the `Salt`.
- This allows both deterministic round-tripping as well as the production of inclusion proofs.

The API makes it convenient to produce envelopes from a `XIDDocument` that:

- Omit the private key (default)
- Include the private key (for private backup)
- Elide the private key (when inclusion proofs may be necessary)

Example with elided private key:

XID(71274df1) [
    'key': PublicKeyBase [
        'allow': 'All'
        ELIDED
    ]
]

Note that receivers can tell *something* has been elided, but not that it is a private key, and cannot correlate the digest to the private key due to the salt.

Future work involves being able to add analogous functionality to the `ProvenanceMark`, adding assertions that provide the genesis seed as well as the state of the PRNG, providing everything needed to generate the next mark in $O(1)$ time (without the RNG state, it takes $O(seq)$ time. This private information can be similarly included for private backup, or omitted or elided for published versions.

- The `bc-xid` crate still needs to be published to GitHub and crates.io.

## Crates Not Mentioned Above Needing Tagged Releases

- `dcbor`: Now includes "flat" (single line) diagnostic formatting and new CBOR tag lookup system.
- `dcbor-cli`: To synchronize with changes to `dcbor` and possibly include a switch for flat diagnostic output.
- `bc-ur`: To synchronize with changes to `dcbor`.
- `bc-components`: To synchronize with changes to `dcbor` and other improvements the work I have been doing relies on.
- `bc-envelope-cli`: To synchronized with various changes. Work on incorporating signatures with metadata is a separate task.
- `depo-api` and `depo`: To synchronize with dependency changes.
- `seedtool-cli`: To synchronize with dependency changes.
- `provenance-mark`: Needs first release.

## Minor Fixes and Improvements to Swift Packages

In the process of implementing the Rust changes I found and fixed a couple bugs in `bc-envelope` dealing with assertions having assertions (as used in the salting of the `'privateKey'` assertions above. I rolled those fixes into the `BCSwiftEnvelope` package, including a tagged release.

## Outline of Oura Ring Capability Delegation using GSTP

Available [here](https://hackmd.io/@bc-community/B1kQCZQ7kl).

## Future Tasks for Consideration and Prioritization

- Updating lookup for Known Values, Function Identifiers, and Parameter Identifiers to follow patterns analogous to the new CBOR tag lookup system.
- Synchronize capabilities of Swift packages and Rust crates.

## Thanksgiving Vacation

I will be in Northern California from Wednesday the 27th to Friday the 29th to visit my parents for Thanksgiving.