fix: wrong XMR blocks#7688
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on improving the stability and correctness of the Monero merge mining proxy. It resolves issues related to block rejections, memory leaks, and coinbase transaction corruption by correctly handling Tari data injection and memory management. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request effectively addresses the Monero block rejection issues and the memory leak in the merge mining proxy. The approach of pre-reserving space in the Monero block template is a clever solution to ensure correct weight penalty calculations. Adjusting the reserved_offset is also a crucial fix to prevent coinbase corruption. Finally, moving the template cleanup to a dedicated background task is a solid architectural improvement for long-term stability. I have one suggestion to improve the robustness of the new background task.
Description
This PR addresses the sporadic Monero block rejections ("spend too much money" and "incorrect miner transaction") and resolves a memory leak in the merge mining proxy.
Intercepts block template requests from the miner and forces the upstream Monero node to pre-allocate the exact byte size required for the Tari merge mining data. This ensures the Monero node correctly calculates any block weight penalties and adjusts the block reward before the template is sent to the proxy.
Shifts the reserved space offset reported back to the miner by the exact size of the injected Tari data. This prevents the miner's software from overwriting the Tari payload or corrupting the coinbase transaction.
Detaches the block template memory cleanup process from the block submission workflow. Stale templates are now pruned via an independent background interval, preventing memory leaks when miners request templates but fail to submit solutions.
Closes #7045
Motivation and Context
When the proxy facilitates merge mining, it injects 35 bytes of Tari-specific data into the Monero block's coinbase
tx_extrafield.Historically, this injection happened after
monerodgenerated the template. As a result, the final mined block was physically heavier thanmonerodoriginally predicted. If the Monero network was under load and the block was near the median weight limit, this hidden extra weight would trigger Monero's native weight penalty. Because the block was claiming the original, un-penalized reward, the Monero network would reject it for spending too much money. By tricking the Monero node into pre-reserving this space, the node handles the complex penalty math natively.Additionally, because the proxy prepended the Tari data into the coinbase, the empty space reserved for the miner's nonce was physically shifted. Failing to report this shift to the miner resulted in corrupted miner transactions.
Finally, the proxy previously only cleared its internal memory of old block templates when a miner successfully submitted a block. If miners disconnected or simply couldn't find a solution, the stored templates would accumulate indefinitely, leading to a slow memory leak. Moving this to an automated background lifecycle ensures stable, long-term operation of the proxy.
How Has This Been Tested?
Run
monerod(regtest mode)Run
minotari_merge_mining_proxy$ cargo run --bin minotari_merge_mining_proxy 14:31 INFO Starting Minotari Merge Mining Proxy version: 5.3.0-pre.1-baa3f950cc89a4540aab858c196151a22bdb88a8-debug 14:31 INFO Configuration file loaded. 14:31 INFO Configuration: MergeMiningProxyConfig { override_from: Some("esmeralda"), use_dynamic_fail_data: true, monero_fail_url: "https://monero.fail/?chain=monero&network=mainnet&all=true", monerod_url: ConfigList(["http://127.0.0.1:28081"]), monerod_username: "", monerod_password: "", monerod_use_auth: false, base_node_grpc_address: Some("http://127.0.0.1:18142"), p2pool_node_grpc_address: None, base_node_grpc_authentication: None, base_node_grpc_tls_domain_name: None, base_node_grpc_ca_cert_filename: "node_ca.pem", listener_address: "/ip4/127.0.0.1/tcp/18081", submit_to_origin: true, wait_for_initial_sync_at_startup: true, check_tari_difficulty_before_submit: true, max_randomx_vms: 5, coinbase_extra: "tari_merge_mining_proxy", network: Esmeralda, config_dir: "/Users/martinserts/.tari/esmeralda/config/merge_mining_proxy", wallet_payment_address: "f411111111111111111111111111111111111111111111111111111111111111114K", range_proof_type: RevealedValue, p2pool_enabled: false, monerod_connection_timeout: 2s } Please enter 'wallet-payment-address' ('quit' or 'exit' to quit) : f411111111111111111111111111111111111111111111111111111111111111114K 14:32 INFO 👛 Connecting to base node at http://127.0.0.1:18142 14:32 INFO Listening on 127Run
xmrigNo errors in
monerodWhat process can a PR reviewer use to test or verify this change?
Breaking Changes