Conversation
…ring data, this becomes model specific. Could consider for future though
…rger source in smaller batches, perfect for our system
Dev fix transaction types
Added account generation from random mnemonic if no previous address was
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f19e71ec59
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for ( std::uint32_t i = 0; i < outputs.size(); ++i ) | ||
| { | ||
| GeniusUTXO new_utxo( hash, i, outputs[i].encrypted_amount, outputs[i].token_id ); | ||
| utxo_manager_.PutUTXO( new_utxo, outputs[i].dest_address ); |
There was a problem hiding this comment.
The mint-v2 parse path drops the UTXOManager return values and always reports success. PutUTXO/ConsumeUTXOs now return outcome::result because persistence can fail (StoreUTXOs), but this branch ignores those errors; if the backing store write fails (e.g., I/O error), the transaction is treated as parsed while the UTXO state is not durably updated, which can desynchronize balances after restart.
Useful? React with 👍 / 👎.
| if ( !dag.previous_hash().empty() ) | ||
| { | ||
| auto maybe_hash = base::Hash256::fromReadableString( dag.previous_hash() ); | ||
| if ( maybe_hash ) | ||
| { | ||
| mint_inputs.push_back( { maybe_hash.value(), 0, {} } ); |
There was a problem hiding this comment.
MintTransactionV2::New treats dag.previous_hash() as a spend input (output_idx = 0), but mint requests pass external transaction references through previous_hash. This makes minting unexpectedly mutate UTXO spend state: a parseable hash can consume a local UTXO if it matches an existing tx hash, even though minting should be creation-only. At minimum this couples mint validity to an unrelated DAG field and can lead to accidental fund consumption/state corruption.
Useful? React with 👍 / 👎.
Dev proc data types
…stalled to the correct location
Dev mergeandroid
4 participants
No description provided.