Refuse the generator-point pool_pubkey placeholder at mint startup #35

New issue

Closed

opened 2026-10-09 13:24:45 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-09 13:24:45 +01:00

Collaborator

Refuse the placeholder pool_pubkey at mint startup, so shipping prod config unedited fails loudly instead of naming real epochs after a well-known constant.

Primary goals:

The placeholder is rejected — a mint configured with it refuses to start and says which setting to change.
Real misconfiguration stays distinguishable from a real key — validation rejects this specific value, not valid pubkeys in general.

Current state and specifics

config/prod/mint.config.toml ships a pool_pubkey placeholder which is the secp256k1 generator point. Because that is a structurally valid compressed pubkey, naming::validate_pool_pubkey accepts it, and the mint proceeds to namespace every epoch unit with it: units become hash_0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_<height>, and each gets a keyset derived under that identity.

This is not hypothetical. A dev-stack run produced exactly those unit names, so the placeholder path is the one that actually executes when nobody edits the config. The failure is silent: nothing in the logs distinguishes "the operator set a real pool key" from "the operator shipped the example file", and the mistake is baked into the currency unit identifiers and keyset identities, which are the things ecash is denominated in. Discovering it later means the units already issued carry a meaningless pool identity.

The generator point is a good placeholder precisely because it is recognisable, so rejecting that one value costs nothing and catches the whole class.

Scope

In scope: reject the generator point as a pool_pubkey during the existing startup validation, with a message naming the config key and the file. Consider whether the prod config should instead ship no value at all, so the mint fails on a missing key rather than a sentinel one, and say which you chose.

Out of scope: broader pool_pubkey validation, which already rejects malformed and uncompressed keys.

Validation

Start the mint against the unedited config/prod/mint.config.toml and confirm it refuses to start, naming pool_pubkey. Start it with a different valid compressed pubkey and confirm it starts and names epoch units with that key. Confirm the dev config path is unaffected.

Refuse the placeholder `pool_pubkey` at mint startup, so shipping prod config unedited fails loudly instead of naming real epochs after a well-known constant. Primary goals: - **The placeholder is rejected** — a mint configured with it refuses to start and says which setting to change. - **Real misconfiguration stays distinguishable from a real key** — validation rejects this specific value, not valid pubkeys in general. ### Current state and specifics `config/prod/mint.config.toml` ships a `pool_pubkey` placeholder which is the secp256k1 generator point. Because that is a structurally valid compressed pubkey, `naming::validate_pool_pubkey` accepts it, and the mint proceeds to namespace every epoch unit with it: units become `hash_0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_<height>`, and each gets a keyset derived under that identity. This is not hypothetical. A dev-stack run produced exactly those unit names, so the placeholder path is the one that actually executes when nobody edits the config. The failure is silent: nothing in the logs distinguishes "the operator set a real pool key" from "the operator shipped the example file", and the mistake is baked into the currency unit identifiers and keyset identities, which are the things ecash is denominated in. Discovering it later means the units already issued carry a meaningless pool identity. The generator point is a good placeholder precisely because it is recognisable, so rejecting that one value costs nothing and catches the whole class. ### Scope In scope: reject the generator point as a `pool_pubkey` during the existing startup validation, with a message naming the config key and the file. Consider whether the prod config should instead ship no value at all, so the mint fails on a missing key rather than a sentinel one, and say which you chose. Out of scope: broader `pool_pubkey` validation, which already rejects malformed and uncompressed keys. ### Validation Start the mint against the unedited `config/prod/mint.config.toml` and confirm it refuses to start, naming `pool_pubkey`. Start it with a different valid compressed pubkey and confirm it starts and names epoch units with that key. Confirm the dev config path is unaffected.

vnprc-agent referenced this issue

2026-10-09 13:27:05 +01:00

Mint epoch mechanics: height-named units, records, manual rotation lever #16

vnprc-agent referenced this issue from a commit

2026-10-09 15:49:30 +01:00

mint: refuse the secp256k1 generator point as pool_pubkey

vnprc-agent referenced this issue from a commit

2026-10-09 23:11:37 +01:00

mint: refuse the secp256k1 generator point as pool_pubkey

vnprc-agent referenced this issue from a commit

2026-10-11 15:29:24 +01:00

mint: refuse the generator point as pool_pubkey; prod ships no key