Reject Ironwood commitments for v5 transactions#513
Conversation
Previously `commitment_format` ignored `tx_version` for the Ironwood pool, silently committing an Ironwood bundle under v6 personalization even when the caller requested `TxVersion::V5`. Add a `CommitmentError::InvalidTransactionVersion` variant and return it from the commitment APIs instead. This makes `authorizing_commitment` and the `hash_bundle_*_empty` helpers fallible, mirroring `commitment`, and threads `CommitmentError` through the internal `hash_bundle_*_data` helpers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
This isn't a big deal, it's just something I wish we would have done in #510 in retrospect. I also expect it to be identified in audits; it was identified by Technically, this is fixing a case where we actually return an incorrect value for an unrepresentable input. The cases you mention are all possible mistakes the caller can make, but at least the library cannot produce completely invalid results in those cases. Probably the weirder examples are ones like @TalDerei suggested to me, such as |
forgot to mention, v12 didn't surface anything new (only some duplicative informational findings that are outside our threat model). |
3 participants
Previously
commitment_formatignoredtx_versionfor the Ironwood pool, silently committing an Ironwood bundle under v6 personalization even when the caller requestedTxVersion::V5. That should instead fail because it's unrepresentable.This makes
authorizing_commitmentand thehash_bundle_*_emptyhelpers fallible, mirroringcommitment, and threadsCommitmentErrorthrough the internalhash_bundle_*_datahelpers. We add aCommitmentError::InvalidTransactionVersionvariant and return it from the commitment APIs.