feat: update tari core libs - #142
Merged
SWvheerden merged 2 commits intoSep 17, 2026
Merged
Conversation
Bumps tari_common, tari_common_types, tari_script, tari_sidechain, tari_transaction_components, tari_node_components and minotari_app_grpc from 5.6.0-pre.1 to 5.7.0-pre.8. tari_crypto and tari_utilities already resolved to the newest release inside their existing ranges. Two API changes needed work. `prepare_one_sided_transaction_for_signing` now takes the key manager as an explicit argument rather than reaching into the builder for it, so the three prepare call sites pass one in. `prepare_transaction_builder` hands its key manager back alongside the builder, because the payload the builder is handed to has to be signed with the same one. The builder also grew an explicit reservation phase. `reserve_sender_offset_keys` is now the single point where the input script keys are folded into the script offset and where the fee and change decision are made; `build` refuses a builder that never reserved, and `add_recipient` takes a key that must have come from that reservation. The burn flow was deriving its own sender offset key with `get_random_key`, which under 5.7 leaves the key unsubtracted from the script offset and the transaction unspendable. It now adds its inputs first, declares the hand-built burn output as a `PendingOutput::measured` so the binding fee and change decision accounts for an output that does not exist yet, then reserves and builds the output — and the recovery key derived from it — around the key it gets back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…t keys Two issues found reviewing the 5.7 upgrade. `get_default_features_and_scripts_size` summed an output's features, an *empty* script and its covenant, and stopped there. The builder charges for a fourth term - the memo carried in the output's encrypted data - and emits a `PushPubKey` script rather than an empty one, so the estimate came out at 64 bytes against the 192 a real one-sided output costs. UTXO selection charges that number once per output and once for change, so it locked inputs that could not cover the fee the builder went on to compute: with no change output to absorb the difference the send then failed at `reserve_sender_offset_keys` with the funds already reserved, leaving the user to wait out the lock. The estimate now goes through upstream's own `recipient_output_features_and_scripts_size`, measured on the largest shape the builder emits unbidden - a change output, whose `TransactionInfo` memo is padded to a 130 byte floor. Since a payment id widens that memo, the three call sites that know theirs now pass it instead of taking the floor, and the burn measures its actual output: burn features carry the claim key and the sidechain key, so a burn output is larger again than the generic estimate. Separately, 5.7's key manager rejects a script offset over any `TariKeyId::Zero` input script key, where 5.6 folded it in as the zero scalar. `"zero"` parses cleanly to `TariKeyId::Zero`, so a migrated row carrying one would import as an ordinary spendable UTXO and then fail every transaction that selected it - permanently, and only once coin selection happened to pick it. The migration now refuses such a row up front with a message saying what it is, while still migrating spent ones, which are never selected and so remain harmless. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
update tari core deps