tari Merge mining proxy sometimes create wrong XMR blocks

Describe the bug I get this error from monerod v0.18.3.4 via merge mining proxy: {"error":{"code":-7,"message":"Block not accepted"},"id":"0","jsonrpc":"2.0"}

What I see in ~/.bitmonero/bitmonero.log monerod (with --log-level=1):

2025-05-08 15:57:17.959 [RPC0]  ERROR   verify  src/cryptonote_core/blockchain.cpp:1436 coinbase transaction spend too much money (0.662061490373). Block reward is 0.662060531140(0.599971351140+0.062089180000), cumulative_block_weight 302073
2025-05-08 15:57:17.959 [RPC0]  ERROR   verify  src/cryptonote_core/blockchain.cpp:4430 Block with id: <022fc65d598a2c02af684d90a543211cdbbae60fbedd931b099f0623d1443394> has incorrect miner transaction

Here is merge mining block data being submitted:

1010d1a8f3c006b8a185e055dcd04828319d00a3dd9cb3f93da82b8cdafc0cf8d647bbb425547ae39a020002cffbcf0101ff93fbcf0101c5c1c2afa213037a948d998e4dd333e1e09d32304b9ea66a8867a677208ef3b1b033bfc457aeeadd57032100763e24f14419a0cb8c2ea9b4c17b4de1b3930526bb15f79fe4f1f428fe29d81b01ff8f6433b767f5d37e98d7f450a16100106036de3e3ca10239eb52899ce39df80211000001fac3b55d00000000000000000000008501cfb41b4e4dbbb1ff7df36fb282fb7b9056499ddb83987799f02e01ad843c21aea88434c49f00cce517b44f1196d6a09edaaaf71367a57c74a609eeb03c823037516cb1b26fcb3823bf0da8c5b8e47ede57f03f906112811fafdf1373b980052eca73ec002a2c97dbaf235956b27fbbbc294475852077e53de8a0f32e96d04becb47e16d7e68da11f039d989282c3cbf2ca72e3b928187c0a8c7a630b430c532a6e49e785480dce853132cae1c146d5b13fd88e0792a29865cde2e31cbd41b1a7d039cbd60875460300ed05bbb6abff104b10fbf43428b4c838a5cc2ff48c87597840f3ec7f5e10f721f49e5dee584ee2c76bccf981cacf0e34351d1a57377b5315c086e0b48983da8ded96104ca511b0eec95d69150ae40b99dc2a19138a74cfd1dd4c1926f13914eb71ec47dcf27730fac4cd216829d16184301e5fc1ddbbdb04cab39b5ebf83bddbb04bc6f7c61d63d22551d47d56d24e3400e5b196493eb713b77dc791726087c2fd04b749a7e4c68995c64c8d52d29a24df0e0852d54950ce29af5bbabcc048fd9709cd3df6fdf8ba8138cdcda4a3c5f90a8d13698892fe760d5ed5c567704d151d0ca7599dd577a3f6ce0a8169455c34cd2af8e524a87c481ac43629faa3af0dbf9784bb7f88eb236e7e1a30fd12a73d4441aaf5c2d321191fef6e644a3cb7fdcf17ce8f5f3edd9d27449814e68ab76e92495ce2968bc7a7f5e46e8c6915c308be831e93b889f3773db5fbc037c37d42f04b8e71b7a84106d84ff42c64b58f24c4263a4bb577a82dc3f5d74f5bdf8cb42129aa76accaf0f68b101fe993e14f725c1bead2cd1418f65feae818e02b9b1ee1b89f450861a5fdac2bcded236e335bfb8c07e53ebfd3e45beb8cd22c9eb48a14ee6c38d9761c28585f87dbff43d308983475d644984b9ed4148ddbc622f6d522e7cc2e58f4928cb0f03063ea016c017148424537365cca3d62e8ed4d65183b310d2563faa0bd698761c49032f772e8b260304316380232d53f844721642a1490dc8dc36d8a8a9288ddba20fc0469daf3cb4e9ce97c9f6eb4deed49536f4a52f7b4d02f4ca92bf9e29beec7de8c3b99e38146774516d64138895ff96b1b31351fa9ed25f4efe56b6b23513340d69e9208ed193cf9dfeb680c4c50296db9195527b67a6dcd021eb7dee28c35462b8fe157744d335c2ef8696a85e75db5d8634727813e2d86e6bca9f7afbdfcd469b3ee9b3403fba9f4ff0be009f50e71abbd8f6e2ef190c5bb5e6561c6c7d66abbcd4c0e17368d1415794cfe3e305f6767740f8c80714fc36dde65a465665759f945278ffa5989197d5b0e56c47733154287672d9746722791386eadc71c58cc73211d7fc29313236ddb4dbcfb3817c5ac028e2c410139111888fa49c0642ff00f34625f9e9f9b4e7bf07a5fc4fa63bd02500da1b1d42912bb12c5da2d96578d831ab804530184527ad400bb687c41082563c0fcb8f0a27fadd7afef42310c38e52df4769836282d94d55cb550577837be9f6381d7458f240d3fd6d13a60b1edde94cdb166b0be7d2aa15cf70e7579df2b175d81f589f731d1972ba043954756b83fc8a5eb5e5a4717a2260456e20c4e5eb4beeb2623d3f2a70f003c0118c5b5e97450a4473d9cf2dc61103af84b2af186ba8648648b4156cc05f4da1f74638c6c8ddc9509de07af0ca77bc654964fa0934af802a11afb62f3b5281c44078e20056f53ca815f1e71f0bff12fad5f4c2f9617c3e04012c77142895f5e4c42196ce95703a81a0cf5a0c734be8b89e265a0dacc8182ea47e0ca153934a5e1f2b77cedf3f648933d88aef5aebdda4d7efe15fe9a17f95a1a2a30f329fd689a3b65973a1ed3f2ffb304076055dd42fa8c09d8d1dc8ecf486fac9e77d41ad5e5d9f7356a0db741475e0e81c2fb9c0ac669a8ae2d5b251007eb1f360ff49034f5f05c663f629c9b20b79bb61c9a3e126b9f2847f3883055041588b108918aaced9b35103d2e125fca119865ea158a486cbcc49ccee782a3f761d4e1dd14bf2c362d9d1249475ea9d5d632a82fe0c53f68124757680cbd4e40e5c001459fbd825b7592dd38b027f063b84e396eb628e0f43076f2c41ed3670eb5f47ad26c59bc952609d2196401c320ca5cd312c66ffd610f8e832b54d1e52fbe8f33d6e1f5eff3d2f6c6cebf78b13f8ee09751ae9974800597a3023daf4a2f643aa26d591b6a665cfd37ff538f9cf86e57bcce596c205a8eb7525c233b55648819fcf9074fd4ae505a1c436d9c5d1b3cbd88dca8da593bad981e43c64db105858241bd08acd8ab21dd61903fab7e317d1b7c5ce3a6fb7aecc8b2dcd10892288dedc4aea927c2fdc8f5948b0ec1fbc6402e25094067d99f0210307f5d1dac95fee465540d587d1d47c33dda8c737697c1c50ed1d64d1496774339e6e516d6f147584bceff19a78d2839f9c792f46bc1766d1e2f7444200a81e7aa7786fcbbab00843477f8320b09e4227d06fb5a4c79d67ec396f368293a557a495b3d7cf7add9d24e416339b694b0499144da03accaa68dffbb11e7bf5ea19d8283624f93046f5d557dd9518376b28966cfdd60d0afa170d41500ea53f720cc11112b388346b9060cc45ac9edff8a9f7d0d6ed840c5d1fc587ef5ba89f04f04347bfd6ba82ccac64a2c50d52b7eead67ac64733f5c24f1546c53e74346207e0679903cd091156fd8e53c5eb2df002913af09e82be76ec7dfad8b4d2983e5ad3ac613746fb4df95f615288f7e8a5b38da529d28896ead4e07121d199bf006ad9490508f79395889fe1264301d3b203858ef6ba9fa2ab04714a64a17f3c18133be06f3535f79833b02e063832955ef7b08ffdba669849ebde6ef16599db91579c0385a276a721e420f3563f349f56f31d775d825ea23c699e4050bb0f9dae35f0dac4eb5c8774a748834dad4398920ada079ec7d41e2294f8a1cb4dfdd0608f749bdc785b7bc376daae68bf5192358819ffd8cf336493b273655c01266e06c2d1978cd3bdb4cd43f18c153264a58e47e3d98a580422361678d7c84374444d08df6c8496ef1e8a9da9409b0b85392231068237835961cb6766efd995c0d7b825223d97ddd7ae7508abf8ebe39d451ee49b1e33046670f4a5f83a8e5db477bac39e9bde1cef5ffc659ea4540b39ae98ef22039bdb7efdf70576b8413332ed61bbd14a98593178121e6e8fc908981d731587df815f957bd4825a0c265b299bfe5b332edbcedb1ef44d0fa9bb00ae6bdeb7a2bddb465622a90d8e008b2e1ebde0494b1c4fe952a54c7a7b7d7b2f51d09dbf6d8497948b64bc00aa4170ccdb1a601b18f9b5595ab38489dccd16589150a4e58caa90dab09d659ac0b7e6dfe277281aa4f9be79c21c04da420c49fa356861e14f397cd970bf3bb5d89965412683ede58eab6e14ad5aa2a38a07c2bdb0bbf79bb39596a14593b1755267b73066c47ec6724eb28659d93f26d059f0355fa51873778c224b12ff38226820598733226868fe22eb37e47fa5332366117b7288c6d363adf7c03aa44674f1a6b13efd9c12e26f744b4be740f8c08f0bcc1e66d1f9e987d503023f24522ebdfebd51cf01a87ea540051fceb36dcee5eef3cde5a332859b01a34a2b67b721968a6a3f9696c9be77a2ce8df0112bd4321e548a72a755143c9cf1c42263c2dddf40b85179d741b7d5ff56fc9d23fb0c4b3981632d22e06c7181309c5616c581de236ab31087d7d91c7ed7a4f87cad981c32603266e92f3152ff5f5eba150ba6a7704a0eeec4467d5322d0e5816c61fc8cd8e895737a8d9642d4af6c18509625c5161f0f70ed3d803f095c2fcb4423c055aedd3f1c47af4d69db9ad484eb806ef1cf97b91b72f9273542e536505ab94b3ea5ec9257a512a12c5a1a1b6846d05ed7eb39a0f569359567c3b0b8d72d40ca9eb49999abad44f1833864c7aadb57a2b6a0765651151f0fbfb0f3e5d5aac7f5c6d86e21f254fc9f005f6c455705bc8bb710c59f17517dce8849fe4a7fed98732b88ad09d5d24f31b31545c0ff6168ae063c01740ee78593bb22ae5994dc6bf4991cdefeded76edb8af979b024e018021df83fcdc0acbad384441423149259d3a2b0c92bc177f7ee8503161cbe7a3fd26ffaefd1dbccf1af7c7bd322481cc46da486278d394fb5215e7978e432ebe44dea6334946eb69d0b704db24d1182bcfbcc93b88986d94dd7b3761d9b5a4eb2f09146d734a93b17b46bd08090b7cd5cb45d4a8527c9c9e35d3d458ec7c97551fe9c73e9c47be668af12acc5465497d4571d4944f167db38774e71c9e9615302043ae3c636d802e70de36f0a5a7db8e26d5dfe1c5dc768c730e2a20c6ecd99d9dc719f9f2e51df6e2a85f85e709cffaa027bc0cbdc5f3b5290c2fe02e2dcda4195fa31d77e59fd46f37841fc437f8b7f797c572d87e8d0555d06ec95a0a4595e02eac4487de2e0ddeb24798b2bbf4f3501d46e8990aecbdfab3c03a75eb7c9384d5be3ad65858bfe81332dc49a42fb67005f581d8307043c04ef45c1746bec95a022c04083f68b14fb8275f68419a1ecb45822099e34fdd6cc05c7b7db5c4706538fbf47c004832d5b9f46e3fd2c1250b36e74fb1bccac251f438552ff3341b9c62093c656f989e09f75369464d948b1f3c5b61f6fca08c073e66d280bd4ecfe1c0f252222323bc21d5d2b860dc1d308a81fbf34395ca8375b656f16f9101c7645d6a54c109ff56b63d77d0f207cf8ad068837aadfabc28803509815017d093cbbdfe8f82c4c54bef43a6b798b0955874b0e99802708ce3e33acde009f39879dec6fd3ac880c7a040a3cbf68e36d89c6991b12aafd9a36c399c9179543b94fad3889605c986e2b5e527a9c548e3bd70c91a273b71411685bd165896c59bc8887e3904c4fea5d622c09047e517de8d6021707f18d175978588ad10649cb5b27c5efb001224227d0b9a8a74064beacdc3fb93613c251b5a3d0c3dcbeb72d7f0f43f1984292cdb77007aea5e2c3217f5166c37876eda968bed637024ff643e029c134a16266fd1021636c0664d4b90155485378d6a3554fad8c1448fd05e5625271d87a2375f4b5fb10b3dd44f9c0db0d15e12688e5992375570e657198e472dbcef5c99763879a1355e8364b454b5b0bfb38171d16cf1ec19cd89ba7426290ffd2c65bd2afce0e45dda553bcda4c114b359c3e89c013853b5ec0615ebf3b4b524c3b4dcf365234e92e14db04f2b6b9b7865fae5d457be3ec8a4b761440d3fbc8bb4b5d0028dc282f853b6a88524783895b80225e4067a76c7ea268793fd5e85d41674c21a8cb7f862773c224afde065830f397b54766f2c8006d18bb6b8f312a470dccee023c5c61aef4b6724c7ccece393744d18c1eb7f549fc73105a2cb1c6683b88c8d0cace38e87cadc1a576d880ff95304764ed04a0c666fd58d092d3eecfd433716e71ad1a7a1073a5a372d23a40181e6ebcc84340a5fc6b4a956e95146cbb6979506d2fb6da87cb06a9838307b01d1f5b6bf9fb61de3ff3cc345a00ed37f44a304ef777fddf8acaff9ce005e9fcf81fc6574ef47aefce0411e19791c1ba22af2c7afbcc35f1117d41348dcefb8e97da5b441b77ab82a693c351379c83d3ca16984298068874e8915de86c7fc0e11baf0ff5973c6bd1c40d13e01daa90eb7f6edbb1e0306378149cc6c2f560053eb68de2240b36c38bc0bc3dce77a933f496b7a589b9d5a385c7841527ed2973ce161bedb409142fae9ca834bc3c85349462e90596ba905ac22790950f1a4218c9859bc5edd4f5d19e050c90d4906abae9f5e9dfe9edc3ab866d9d8c1a97c7b38ff87ccb2cec24c25a20106430c846078ba6a9627fcf0e5956c27944ba637d8569e02a0a923ad39641d3772b64e83340a926e1eb1da489413e33488b85d8eeaefbd250f7bb6839a988a1f7dcbd70c4c2f6b2a407db43f58073a1131d493792ff62c71bba7dca7803f2307f65c6be41761ed58388fd06bca0b267795bf2d76299dd54634d5b50

Here are more example of this same issue for other blocks:

ERROR   verify  src/cryptonote_core/blockchain.cpp:1436 coinbase transaction spend too much money (0.634277661573). Block reward is 0.634277167140(0.599992267140+0.034284900000), cumulative_block_weight 301077
ERROR   verify  src/cryptonote_core/blockchain.cpp:1436 coinbase transaction spend too much money (0.648853395493). Block reward is 0.648852232793(0.599958032793+0.048894200000), cumulative_block_weight 302509

To Reproduce Do merge mining using minotari_merge_mining_proxy and monitor XMR block submission errors.

Expected behavior No failed monerod block submissions.

Desktop (please complete the following information):

Ubuntu 24.04

May 09 '25 17:05 MoneroOcean

Does this happen on every block or sporatically?

May 09 '25 18:05 stringhandler

Sporadically. I would say every 1/3 of the block sometimes. Sometimes less frequently (1/10 perhaps).

May 09 '25 18:05 MoneroOcean

I just updated monerod to the latest v.0.18.4.0 and using the latest tari suite v2.1. Will see if that continue to happen.

May 09 '25 18:05 MoneroOcean

Issue can be reproduced with the latest monerod v0.18.4.0 as well:

2025-05-11 18:25:08:033 +00:00: (Worker 3 - 2188973) Error submitting  (port 18081) block at height 3409500 (active block template height: 3409500) from LkDN2JU5yy:GIP (::ffff:85.25.43.196), isTrustedShare: true, valid: true, rpcStatus: 200, error: {"error":{"code":-7,"message":"Block not accepted"},"id":"0","jsonrpc":"2.0"}, block hex: 
2025-05-11 18:25:08:033 +00:00: 1010ecd683c106da00b12cc4ce8375c4eaf1f00928422011dcdb9bf99b86897247018d10dc50a9dd2b006a02988dd00101ffdc8cd001018586fdf88112035dc14a3a84ab20ae17cf3be294086ea09d2f5616462f305d30b7cc6a400dd4d4725703210022092f0dee057ad92852603f37b671d18ae7d659ca4e6e65f88a0d2d9f76d46c01153d094a0a549f203575b0b805476e3e09a650ecf55f920482c5ea44e27244f4021100000007ad66610000000000000000000000476c3b75a958ca28710275e4845126da40b1864c737129d895f43d7d550100d4466d1420a0f7678ef15245532b704c3e2f37d94aae143792b69b377c1b05fce3f2ac570b74d18a6df76f225dfe05c562d041e2c54b5e47b9cdadf8d74c86361b303c8ba8eefe21b242840edc3e927a9ac478e6318b01705f5bd5c5c3f9b9522a0c41ccf134e3c692fee0103b93d0e91643daf5c35eeb7246074916799628d7921fb21eaad000340f4bb6acdcc88dbac9d8db72b5eeb9f95370fd4cc2118e78cc452f29f6205ea0a1dc0078a2b8a881f7614be01f750b52142a6b9e4ec1b261678f86738b1e4fe0c54626f439767fc1def7655fa134f3f651c116e0596eb0baa9af7a32f38b41e245823d3b3eae8d55d0363631125ac760739952a08c220b4f27de731657f42832542d9d3e323e37b2e4480827e027d2e96f99f283f94863d78c43cfabccc46ab32baae06c4163456275696dbc441ec95f82e030fe5a602f0fefd93e0856ecd6494d9800c1abe33fd7f1f54978d6e7cb73c2ae9ee86cc4eb2f2354c0aa3304338ccca16d1a4579f9838eda486726dff0c7c424e113ee29ce16a449fa2353c1a2183f6e344fb98d1f4854a856eae6dda797ed7a92309cb2d1d90b3251352256bb04fe49f1ca30f7a4696e6a5e96ecb9a3810a6d18fd5d43b92ad766e44557622725be06fd7a3f079957b6b36a3caddceb43e6fa1beb0428e76a32928010fdb182ff5d8b141205aad8c9604068d4204b0a9976b00be259b01882145981733702fae17d80e8406bdeda9be0135f87032787bb52c1836599a766ee52c6c39f3c819f2ad0e88cf15579ff19c68847fa665d36af95274b71ad233ddb016a0a0972264e7e9f0028b9d4340e28a7c9c1bf86740e7674a60e207c4ecbe2c64672bef44973596b4100cc7b9754c0fa4887e45da17792e166786331838a3395eb023a8d99e44694caab31a8e9a37f7df4e331651c5e63d0218ed9e2c8924c59306e73f54ba811e379796f6c382e4fd868530ec4108012934cd9f7c5f9c8d1d9c6af7a9cbac7c9ad5354cab1e6d0d2c13511509bd15f669fc97d242c1533223ee74e89de31e608143141f61faf841202acf4c207146264631d5d077f5b16520113b51d2ea1b9b3d01400a9d0c22eafd46f002552ed7fc5073e72f628f09e59d7c7609e86c46b51aa711ceac441645805e173d2f0b02127862c17df0488326c29ba1201f0881a97681555f7068e0f705087af0193b56d33d56023c0ceaa188a67da346aa8c5c021058a4c9068074704f0ceff36b1c4d375e4832e363508ea834253d7032409d2223b69893add4aa192417d093bd245cf041b77cc4d6cbed92064ccbe7af23836520b6c7cbe2e9274a14fca25e2bf1fd5aa6e0395266e7af0ff5e57e446433841cdbc5c89fe07ab799cd11a1b7c10fb5ee87ac10c8c17a7cdc61313b4e410219976b2ff23b58b0fce2d6a0ec742a0b011204957f34eaed9b2fbb5ca416399ecf7b5161e9baf559982e65e1a5e92a75195480242dce8090ad9846106d5618ab450e5a221ffb37ebd0b54ba634440b951f92fcbe3c743cbc8cc78697a79beffca43e63323c7cb35c0de054715745d44e40d6ef427e655d677d340f17212f77a47180fdfc085771b2664106d3fcaf50524775b4d68ca712b900cc7e56377e0e0878a1605abbb93e4f58728efe2b8c844929e3f99e74703a527ec3af93ebc89b12ad223be051ad9f3913174196cc160d4f80b033cdf893d1a1214928f96ed73cbf4469262d3a64bdf2add5e93b7ac72a8931bed2a7de5b3817f4fff774efdc61609e7193bda6b2930f1303510776ee1d6ae19eecaf5c4464b42f944d4d943e5ab1d4657390ea649fd7b7aa1edf3b1b06cb58cdc4c729270c35133ab5f1e3a97f352ce3784555b294dc80841e4c14146318c5bf3d11b83c928e41b094a955b3bd0ccad3824a6c02aef40954b8cfd2fe05b098f799e1b908d992e9b366f4d96827cfad9a57112ffc6e19c579ab031ee7bb38fa06c528ccf0908441f949c073cc750f53175d295d11d6c6906ebe165defc3d3e2a0dca233a82e8fdcc54b193098a602b1b012b6b80af74849b0b20854a8c81671d2f8c1c1c34c359bcc3465d09e4173cf6c18a208309506bc5630dc54e8499c50179095bf42a54e0833d2737a4ab3e15727e9f20f0e99ff0757598a090f273734372f17a34314cc13d7347460f1c6a01b5714c77bc6c13443a1aa252561528bed7565e16f36e236e079948e7192768caaad071e3ef32771053362d7ffc67172e518aebb77b5e2ba62a567780c6a0c41fd87816dcfa541805912b495ac445635a765e02983c8dba8b0ee7780a8b869dfa3b319aedafeb5706ce5eda6b56d4d189eb58a3c42cf470d35dd3f2e1b82ac37cb3d603dc6ef661b44c4b0fbc27ed5c9fae414e6744ad659bca64f5134e025ae209fa4f586e82b5a2b35af26de04fac124d788507673fc51c330aaaf84d46a88023c9281fec896aee3d4984b0fb7e28ee1e32c3066404b22db16a23040480d8102c62c907b629bad4362d7dd01e5b01d17ada4aea12587efac3f01ca2e1b5c1c452a90f01f91a606c6cca190953752a9fcdb311e6a777f47f7b7eabcd75ec62cb599e368a046cee1d507d7989bc06df2018927ce7259a0a53438a2489b038006989b11ca40696965a37e7f6d66e7d264857ff79e9750fd65cda5939845e2a862a17e2ccec7b076332e17050c1a7f2d51950b065ddbceba820ae457330779af349e634c1cadd97fd5ed045b0c1fcfc67d6a9807e83262bd26d2db776ead0df911aba5ee124977b16f5a44829971f2681b5b92dac6a755d8a231ed0c49a0ab7fd3e3abc2af3423e0360674d71decdc8a501c284c7a89c7fcd083b5d7af11685fbf25790d1a5b1c1fa50d096f3e260cb37d9dcf8c071655ef1036cf4007dd6028f1de181d1de3ead6630611eeabc281b8195a8313cdafedca2cffa54d7ac084775d240e3f11f77bee98d46de5b2cca58d2e4c734dfdbe63c344214c9d89b5c91ee11e73fb962170e21366f05ebe0a20be180119296b28d0f6d7edf9e01fe8203e0befa24ca973e02532deb8f0297a147747ee3d4a6b17a3c9c286d1abf99c3a4e344578eaed456d1bccc96381d5d21e03440efb31e250530acfac853a761affe9590a83b879bb4afbb195521652a9767e7b8cc4a0d603c6167e0958a76b8

This is what I see in bitmonero.log

2025-05-11 18:25:07.000 [RPC1]  INFO    daemon.rpc      src/rpc/core_rpc_server.h:154   [127.0.0.1:44700 INC] Calling RPC method submitblock
...
2025-05-11 18:25:07.094 [RPC1]  ERROR   verify  src/cryptonote_core/blockchain.cpp:1367 coinbase transaction spend too much money (0.618997433093). Block reward is 0.618996955460(0.599992775460+0.019004180000), cumulative_block_weight 301041
2025-05-11 18:25:07.094 [RPC1]  ERROR   verify  src/cryptonote_core/blockchain.cpp:4434 Block with id: <cfb8bd7a4cdd7bd0727726f9c0ac15bf299e7e374a085ea74686b0a732b05dfe> has incorrect miner transaction

I also found that if I modify monerod to create block templates without any monero transaction it solves the issue. But of course it is not the best way to workaround it.

May 11 '25 18:05 MoneroOcean

This is occurring because the MM proxy does not properly update the reserved_offset, as we use this in nodejs-pool based pools, it's corrupting the coinbase tx_extra. You can patch this with a custom version w/ a fixed offset increase by the size of the merge-mining header.

May 11 '25 18:05 Snipa22

Hm, you might be right. I know about wrong reserved_offset returned by the merge mining proxy and use pattern search in the block template hex to find it. Perhaps some blocks have transactions that confuses this search. Will check it.

May 11 '25 19:05 MoneroOcean

Yeah, the quick and simple way if you're using a semi-stock nodejs is to just patch MM to properly increase the offset by a number of bytes, MM always inserts the 0x03 (merge-mine data) tx_extra into slot 0.

May 11 '25 19:05 Snipa22

I checked affected blocks and I think I still use correct 166 offset (not 131 reported by merge mining proxy, see "00000007ad66610000000000000000000000" reserved bytes in the latest block template correctly filled by pool nonces) so wrong reserved offset reported by merge mining proxy (but also a bug!) unfortunately can not explain this error.

May 11 '25 19:05 MoneroOcean

Weird! And yeah, that should be clear if you're in that space, I haven't seen that error in my testing. The offset bug was annoying, lost a couple of coinbase rewards to that because it corrupted the pubkeys.

May 11 '25 19:05 Snipa22

Weird! And yeah, that should be clear if you're in that space, I haven't seen that error in my testing. The offset bug was annoying, lost a couple of coinbase rewards to that because it corrupted the pubkeys.

What is good indication issue can be still on my side. Do you update monero block template every 15-20 seconds to include new transactions btw? Perhaps merge mining proxy does not like that and produce wrong results because of some caching.

May 11 '25 20:05 MoneroOcean

The issue likely arises from inserting Tari merge mining data into the generated Monero block template without accounting for the increased block size. This increase also raises the block weight, and if it exceeds the median, the block reward must be reduced by the appropriate penalty.

An alternative approach would be to request that monerod generate a sufficiently large tx_extra field and place the Tari merge mining coinbase data there instead.

May 16 '25 21:05 MoneroOcean

maybe the same issue here: https://github.com/tari-project/tari/issues/7068 It looks like forcing non-tx block template would solve the issue (just a hint for bug fixing)

May 20 '25 08:05 krypdkat

maybe the same issue here: #7068 It looks like forcing non-tx block template would solve the issue (just a hint for bug fixing)

how can i get a non-tx block template from monerod?

May 20 '25 13:05 peterpan0708

maybe the same issue here: #7068 It looks like forcing non-tx block template would solve the issue (just a hint for bug fixing)

how can i get a non-tx block template from monerod?

You have to rebuild monerod from sources with the following change:

--- a/src/cryptonote_core/tx_pool.cpp
+++ b/src/cryptonote_core/tx_pool.cpp
@@ -1572,7 +1572,7 @@ namespace cryptonote
     LockedTXN lock(m_blockchain.get_db());
 
     auto sorted_it = m_txs_by_fee_and_receive_time.begin();
-    for (; sorted_it != m_txs_by_fee_and_receive_time.end(); ++sorted_it)
+    for (; sorted_it != m_txs_by_fee_and_receive_time.begin(); ++sorted_it)
     {
       txpool_tx_meta_t meta;
       if (!m_blockchain.get_txpool_tx_meta(sorted_it->second, meta))

May 20 '25 15:05 MoneroOcean

maybe the same issue here: #7068 It looks like forcing non-tx block template would solve the issue (just a hint for bug fixing)

how can i get a non-tx block template from monerod?

You have to rebuild monerod from sources with the following change:
--- a/src/cryptonote_core/tx_pool.cpp
+++ b/src/cryptonote_core/tx_pool.cpp
@@ -1572,7 +1572,7 @@ namespace cryptonote
     LockedTXN lock(m_blockchain.get_db());
 
     auto sorted_it = m_txs_by_fee_and_receive_time.begin();
-    for (; sorted_it != m_txs_by_fee_and_receive_time.end(); ++sorted_it)
+    for (; sorted_it != m_txs_by_fee_and_receive_time.begin(); ++sorted_it)
     {
       txpool_tx_meta_t meta;
       if (!m_blockchain.get_txpool_tx_meta(sorted_it->second, meta))

thanks, you saved my day!!! do i also need to change the reserved_offset ?

May 20 '25 15:05 peterpan0708

No other changes are needed.

May 20 '25 15:05 MoneroOcean

No other changes are needed.

Sir, i still have the error. still mined wrong XMR block, this is the log in the mining_proxy

when i produce block, I will send the block to tari mining_proxy, and then i will send the block to my monerod daemon. I'm i doing right?

Or i need to set submit_to_origin = true, and just call submit_block to tari mining_proxy and let the proxy send to block to monerod?

my reserved_offse is set to 8.

this is the wrong block link: https://xmrchain.net/search?value=3416330 thanks for the help

May 21 '25 15:05 peterpan0708

I see. I did not realize you also rely on merge mining proxy reserve offset (which is wrong). Try to find 02090000000000000000 (9 is your reserve_offset 8 + 1) in you block template hex tari merge mining proxy reports to you. 0000000000000000 should be offset by 166 bytes (332 hex symbols) and not 131 bytes like tari merge mining proxy tells you. You need to change 131 to 166 to make it work (increase it by 35 bytes).

May 21 '25 15:05 MoneroOcean

I see. I did not realize you also rely on merge mining proxy reserve offset (which is wrong). Try to find 02090000000000000000 (9 is your reserve_offset 8 + 1) in you block template hex tari merge mining proxy reports to you. 0000000000000000 should be offset by 166 bytes (332 hex symbols) and not 131 bytes like tari merge mining proxy tells you. You need to change 131 to 166 to make it work (increase it by 35 bytes).

the blocktemplate_blob merge mining proxy return to me is: 1010f7e3b7c106471d1500a8ba35abd984419f1297b6677acf1f0f232addc86522e2ec773ffd4b0000000002d0c4d00101ff94c4d0010180e0a596bb11035c65680939229fb1d44f28ecb78aac6dbf3111935eb1b5482f852a2fe00f0352364e0321005013a5f7344a46a2602a50a6063deb6e45c18a04f71d1635fd7f17fe779a13a801432b14086eeb0895bc337ce79ba67988e251f6a10c84ca50b45ef3e6d3284e04020800000000000000000000

the 0000000000000000 is already offset by 166 bytes (1010f7e3b7c106471d1500a8ba35abd984419f1297b6677acf1f0f232addc86522e2ec773ffd4b0000000002d0c4d00101ff94c4d0010180e0a596bb11035c65680939229fb1d44f28ecb78aac6dbf3111935eb1b5482f852a2fe00f0352364e0321005013a5f7344a46a2602a50a6063deb6e45c18a04f71d1635fd7f17fe779a13a801432b14086eeb0895bc337ce79ba67988e251f6a10c84ca50b45ef3e6d3284e040208) . and the merge mining proxy also return 0208(8 is my reserve_offset). But i still got wrong xmr blocks

May 21 '25 15:05 peterpan0708

I see. I did not realize you also rely on merge mining proxy reserve offset (which is wrong). Try to find 02090000000000000000 (9 is your reserve_offset 8 + 1) in you block template hex tari merge mining proxy reports to you. 0000000000000000 should be offset by 166 bytes (332 hex symbols) and not 131 bytes like tari merge mining proxy tells you. You need to change 131 to 166 to make it work (increase it by 35 bytes).

the blocktemplate_blob merge mining proxy return to me is: 1010f7e3b7c106471d1500a8ba35abd984419f1297b6677acf1f0f232addc86522e2ec773ffd4b0000000002d0c4d00101ff94c4d0010180e0a596bb11035c65680939229fb1d44f28ecb78aac6dbf3111935eb1b5482f852a2fe00f0352364e0321005013a5f7344a46a2602a50a6063deb6e45c18a04f71d1635fd7f17fe779a13a801432b14086eeb0895bc337ce79ba67988e251f6a10c84ca50b45ef3e6d3284e04020800000000000000000000

the 0000000000000000 is already offset by 166 bytes (1010f7e3b7c106471d1500a8ba35abd984419f1297b6677acf1f0f232addc86522e2ec773ffd4b0000000002d0c4d00101ff94c4d0010180e0a596bb11035c65680939229fb1d44f28ecb78aac6dbf3111935eb1b5482f852a2fe00f0352364e0321005013a5f7344a46a2602a50a6063deb6e45c18a04f71d1635fd7f17fe779a13a801432b14086eeb0895bc337ce79ba67988e251f6a10c84ca50b45ef3e6d3284e040208) . and the merge mining proxy also return 0208(8 is my reserve_offset). But i still got wrong xmr blocks

oh I got it, the "reserved_offset":131, merge mining proxy returned to me is not suitable, it need change it to 161. I will try that

May 21 '25 15:05 peterpan0708

Change it to 166, not 161.

May 21 '25 15:05 MoneroOcean

Change it to 166, not 161.

Thanks a lot. It worked, i can produce valid blocks now. But now, it's not a good way (make empty block) to do the merge mining, do we have a good approach to that? Can we just construct blob without merge mining proxy? Also i found that the minotari_merge_mining_proxy has a memory leak...

May 23 '25 10:05 peterpan0708

Change it to 166, not 161.

Thanks a lot. It worked, i can produce valid blocks now. But now, it's not a good way (make empty block) to do the merge mining, do we have a good approach to that? Can we just construct blob without merge mining proxy? Also i found that the minotari_merge_mining_proxy has a memory leak...

You need to intercept the interceptor (mm proxy) to find out where does it insert tari special bytes, then check back and forth to validate the data, assuming you know the bytes order very well in block template.

May 23 '25 11:05 krypdkat

Change it to 166, not 161.

Thanks a lot. It worked, i can produce valid blocks now. But now, it's not a good way (make empty block) to do the merge mining, do we have a good approach to that? Can we just construct blob without merge mining proxy? Also i found that the minotari_merge_mining_proxy has a memory leak...

The following fix in monerod fixes it without producing empty blocks:

diff --git a/src/cryptonote_core/blockchain.cpp b/src/cryptonote_core/blockchain.cpp
index fb65b2b50..246b58a07 100644
--- a/src/cryptonote_core/blockchain.cpp
+++ b/src/cryptonote_core/blockchain.cpp
@@ -1686,7 +1686,8 @@ bool Blockchain::create_block_template(block& b, const crypto::hash *from_block,
   size_t max_outs = hf_version >= 4 ? 1 : 11;
   bool r = construct_miner_tx(height, median_weight, already_generated_coins, txs_weight, fee, miner_address, b.miner_tx, ex_nonce, max_outs, hf_version);
   CHECK_AND_ASSERT_MES(r, false, "Failed to construct miner tx, first chance");
-  size_t cumulative_weight = txs_weight + get_transaction_weight(b.miner_tx);
+#define get_transaction_weight35(miner_tx) (get_transaction_weight(miner_tx) + 35)
+  size_t cumulative_weight = txs_weight + get_transaction_weight35(b.miner_tx);
 #if defined(DEBUG_CREATE_BLOCK_TEMPLATE)
   MDEBUG("Creating block template: miner tx weight " << get_transaction_weight(b.miner_tx) <<
       ", cumulative weight " << cumulative_weight);
@@ -1696,7 +1697,7 @@ bool Blockchain::create_block_template(block& b, const crypto::hash *from_block,
     r = construct_miner_tx(height, median_weight, already_generated_coins, cumulative_weight, fee, miner_address, b.miner_tx, ex_nonce, max_outs, hf_version);
 
     CHECK_AND_ASSERT_MES(r, false, "Failed to construct miner tx, second chance");
-    size_t coinbase_weight = get_transaction_weight(b.miner_tx);
+    size_t coinbase_weight = get_transaction_weight35(b.miner_tx);
     if (coinbase_weight > cumulative_weight - txs_weight)
     {
       cumulative_weight = txs_weight + coinbase_weight;
@@ -1717,11 +1718,11 @@ bool Blockchain::create_block_template(block& b, const crypto::hash *from_block,
 #endif
       b.miner_tx.extra.insert(b.miner_tx.extra.end(), delta, 0);
       //here  could be 1 byte difference, because of extra field counter is varint, and it can become from 1-byte len to 2-bytes len.
-      if (cumulative_weight != txs_weight + get_transaction_weight(b.miner_tx))
+      if (cumulative_weight != txs_weight + get_transaction_weight35(b.miner_tx))
       {
-        CHECK_AND_ASSERT_MES(cumulative_weight + 1 == txs_weight + get_transaction_weight(b.miner_tx), false, "unexpected case: cumulative_weight=" << cumulative_weight << " + 1 is not equal txs_cumulative_weight=" << txs_weight << " + get_transaction_weight(b.miner_tx)=" << get_transaction_weight(b.miner_tx));
+        CHECK_AND_ASSERT_MES(cumulative_weight + 1 == txs_weight + get_transaction_weight35(b.miner_tx), false, "unexpected case: cumulative_weight=" << cumulative_weight << " + 1 is not equal txs_cumulative_weight=" << txs_weight << " + get_transaction_weight(b.miner_tx)=" << get_transaction_weight(b.miner_tx));
         b.miner_tx.extra.resize(b.miner_tx.extra.size() - 1);
-        if (cumulative_weight != txs_weight + get_transaction_weight(b.miner_tx))
+        if (cumulative_weight != txs_weight + get_transaction_weight35(b.miner_tx))
         {
           //fuck, not lucky, -1 makes varint-counter size smaller, in that case we continue to grow with cumulative_weight
           MDEBUG("Miner tx creation has no luck with delta_extra size = " << delta << " and " << delta - 1);
@@ -1731,7 +1732,7 @@ bool Blockchain::create_block_template(block& b, const crypto::hash *from_block,
         MDEBUG("Setting extra for block: " << b.miner_tx.extra.size() << ", try_count=" << try_count);
       }
     }
-    CHECK_AND_ASSERT_MES(cumulative_weight == txs_weight + get_transaction_weight(b.miner_tx), false, "unexpected case: cumulative_weight=" << cumulative_weight << " is not equal txs_cumulative_weight=" << txs_weight << " + get_transaction_weight(b.miner_tx)=" << get_transaction_weight(b.miner_tx));
+    CHECK_AND_ASSERT_MES(cumulative_weight == txs_weight + get_transaction_weight35(b.miner_tx), false, "unexpected case: cumulative_weight=" << cumulative_weight << " is not equal txs_cumulative_weight=" << txs_weight << " + get_transaction_weight(b.miner_tx)=" << get_transaction_weight(b.miner_tx));
 #if defined(DEBUG_CREATE_BLOCK_TEMPLATE)
     MDEBUG("Creating block template: miner tx weight " << coinbase_weight <<
         ", cumulative weight " << cumulative_weight << " is now good");

May 23 '25 14:05 MoneroOcean

Change it to 166, not 161.

Thanks a lot. It worked, i can produce valid blocks now. But now, it's not a good way (make empty block) to do the merge mining, do we have a good approach to that? Can we just construct blob without merge mining proxy? Also i found that the minotari_merge_mining_proxy has a memory leak...

The following fix in monerod fixes it without producing empty blocks:

@MoneroOcean Isn't it only adding 35 bytes to coinbase tx extra data field? I see that you add 35 bytes to all txs weights, or you just want to be safe?

May 24 '25 03:05 krypdkat

This code adds 35 weight only to coinbase transaction. Other transaction weights are added in the other place.

May 25 '25 00:05 MoneroOcean

Hi @MoneroOcean ,

Does your patch fix the issue you mentioned in the first message:

2025-05-08 15:57:17.959 [RPC0] ERROR verify src/cryptonote_core/blockchain.cpp:1436 coinbase transaction spends too much money (0.662061490373). Block reward is 0.662060531140 (0.599971351140 + 0.062089180000), cumulative_block_weight 302073

Or is it addressing a different issue described by @krypdkat:

May 20 04:53:55 qubic-monero minotari_merge_mining_proxy[683785]: 04:53 WARN Some sub-fields could not be parsed successfully from the Monero coinbase extra field and will be excluded

Thanks

Aug 04 '25 22:08 andrei-kondakov