deterministic currency unit derivation path

[vnprc]

Description

Move the CurrencyUnit enum from nut00 where it was originally implemented before being added to the spec to nut01 to match the spec definition.

Implement deterministic currency unit derivation paths.

• use SHA-256 so results are identical across platforms and rust versions
• NFC normalization, lowercasing, and trim to ensure logically equivalent strings map to the same index
• reserve a low integer range for known variants

---

Notes to the reviewers

See also this impl from the portal team: PortalTechnologiesInc@0051f57
and this impl from a previous hashpool cdk branch: vnprc@0d11a5b

The implementation in this PR improves on both of the above impls.

Suggested CHANGELOG Updates

CHANGED

ADDED

REMOVED

FIXED

---

Checklist

• I followed the code style guidelines
• I ran just final-check before committing

[vnprc]

Suppose we want to add a new enum value, how does that work? Do we implement it as a custom variant?

[thesimplekid]

Suppose we want to add a new enum value, how does that work? Do we implement it as a custom variant?

What do you mean enum value?

[vnprc]

a new CurrencyUnit enum variant, like how Auth was recently added.

pub enum CurrencyUnit {
    /// Sat
    #[default]
    Sat,
    /// Msat
    Msat,
    /// Usd
    Usd,
    /// Euro
    Eur,
    /// Auth
    Auth,
    /// Custom currency unit
    Custom(String),
}

If we reserve a small range of hard coded derivation path values for the future it becomes trivial to add a new enum variant that is more ergonomic for developers to use. The downside is minor IMO: you get an infinitesimally larger chance of collision. We don't need to reserve 10,000 spaces but I think a small reserved range is a good idea.

[thesimplekid]

I think a small reserved range is a good idea.

for what? Even the current ones only need to stay fixed for backwards compatibility. The only point of the reserved is to map the unit to the derivation index, we can do that now by hashing.

[vnprc]

It makes the code uglier. That's all.

[vnprc]

I was about to suggest we take a page from the secp256k1 library and implement different hash functions but I just saw that apoelstra removed this functionality last week. rust-bitcoin/rust-secp256k1@54828ac

We could standardize on the rust default hash function for simplicity. Would this make derivation paths different in some library upgrade scenarios?

[vnprc]

Discussion points from the cdk meeting:

• we definitely want to use SHA256 to ensure consistency across architectures
• a reserved range is not necessary for code ergonomics

[vnprc]

We also determined this should be added to the NUT specs. Open question whether to add it to NUT-01 or as a new NUT.

[github-actions]

This PR is stale because it has been open for 60 days with no activity.

[vnprc]

cashubtc/nuts#292

[github-actions]

This PR is stale because it has been open for 60 days with no activity.