Merge mining proxy creates strange XMR block

[krypdkat]

Describe the bug I solo mined block 3415599 on monero and 10344 on tari. Block reward was received normally on tari side. But on monero side, no reward for my address. The coinbase has very strange field Tx public key as below: link: https://monerohash.com/explorer/tx/c4aa0da271dfb227a15c25908cd17fbbbeaf1d4b774649e60f24b07a5b74bd48 It's guaranteed that I used correct address when requested with get_block_template. I only "plug" minotari_merge_mining_proxy in the middle of the pipeline.

To Reproduce Steps to reproduce the behavior: Do merge mining using minotari_merge_mining_proxy and monitor XMR block submission errors.

Expected behavior Block submission working correctly

Screenshots block 3415599 submission on monerod:

Desktop (please complete the following information):

• OS & Version: ubuntu 22.04]

Additional context log on minotari_merge_mining_proxy at the time it submitted block

May 20 04:53:55 qubic-monero minotari_merge_mining_proxy[683785]: 04:53 INFO  Block submit request #{"id":"0","jsonrpc":"2.0","method":"submit_block","params":["1010d695b0c106a309bd80a48e08b2303f6935f372ef72c37fb79ecafbdca8f66c8b46cbd87fe0cdd5040d02ebbcd00101ffafbcd00101a0fea9b7d0110380ea9793f36c217d34a71c5359b3088f4a8cf950910e8624fe2fbf933b4dc2ebb15703210020a00c0e71a36a3a92288d85c253bfbabd5a730d1ea9901dc4ead6fb69419094fb050000fea0f245f0798bd55813c55196808a8fde1df0741cbd8f34e60242864102110000000000000000000000000000000000002526211bcd581bfb13348aabdb588fd959e7722dfebaa999c9e77ba7302950e907b774064726f272b082135681fbf208e2e20e615591b53276f0c9c6a22747b2cada41272f16442132f6fd69350d2b2ffdf029422ef7132a2904c01a01c07d0606858a8e74b1934e70914945446ee14cfa7a75303fea93d8bba79e4f76105ad2fdeab70023c4db8db6552ffec3cdb110d0bf9aec8d194f2a5885a8d55b7d6ab13fb38f330a42c4f33303d9cd76ac858a27fd1e05dca8445a550266151fa6a5f93b02e72d05c78299f135f3959e298c7a0300957c59daa681c9b6ab4cc28f91f9b51c41eea9da6ebaa996b6cc05aaf32ac5394419d6bf60312db62f58b17da9ac183a2c5bebbbbc8ef45bde4c7718ae41e4c1ec121ecbc44766e971b5b640e1781f59d671aafb34188af0cebba06f72e36f6082b1fb145f00d03b22e9987c7c9c88b9815c03c90da8d25a5b6802be3c3ab126cb1469f7ce6bc30f5bcc698a9964fa6fd235de76c49b3b7d951226d93e89553afabc9af2ef85eecb76fea856c3fa59e3307faa21e5ef41d3712a594480a9a86f6e573680445c9b95e2e44fd1e96565a7db8d517df10e7659996e3bdaaebd6faa2ea0a3559f979fa66be5e1f043d34ef5f259226d779881e0646aab0bbf35977696cd653604812ee375d27e30066c4ef2ee6d83854c9f894007c2cc1586fd6341cc65fd9943b80a033b71ebf0dc9ca61add8887bca2c796ef46a2bf64ba9712a698bb69bcdad429b3e786112ac552fcb76628040cd19aeb75097820269093d6dbb7789e35de63f2dc63086abb26fb2da9ccc7dc59c4a2c9656ccf6127d07096879a70c567268035260f82f8594b309275475e93a8e9e7fd566240bb09cf760bfcf8a00436e4c415249fe1dad6d5e27cbb9e35350655cd9b36ea5928f37e306874723ac8bccd5d0c9394fd4053b4aa94c398962735b42aa5606547ea443e49dfbb06c63449032bb73e8c5bcae7111480cb3431766194692b96b449d8a71792e218d444ee5e3f2e6392c60499a1111f9a4331471d1a42789f7eb29ef9bd0c4bbf67ef6c90031ce77fae4f15feeadc1bb303cc445bcf2433943978858a640451a32f6cd2c5a42bfefeeebf1528f43f3f387461e359e095130f7403b178b34c36985b4d1cfcc7a7ff510a148786429c0c4b27a2f7fd8f896473d8568da5cb83b8228b75ab0035919be9c614068740326bf61dcc2d72b031eae2d97973462c523b7b758d3b5f7bc23a1ce6df44f9556008372bf4c6a004127c5fa773f924c8f8707df13c6a841955d6181ee62ff911199515ae62e0febc8d2d49ba4a897dfc1fe648d216118c39a4d3729bb11fb4f7252d08da37fea8a1f72bea12e66023c1c8afb4e2c5763dba982759a911ec55e28d2d25231a5500f7311007668fdc64c3e8e4d97beda37df010f2d600b74127dce15f5727d39f59dabea8cdcb0c41c3a62e3b9cd539fd529c16457bd782cdb6a0ea57efeb59c6114dd4d59d4f95572f91b12c903c8297bb0c1e3e8002e563c1bc1a621383f162dc1bff1105e7d9099d490111b5feec000e6cbafa87ca0c6692923732499aeb24f5dbd33f1a0e3afd96dd2de786ec9e080f7049a12dd5b5bd914a5b4f21c994e0dbe15fd4540e2e830a80badeaebf70e9d027336dea38f1445dbd9f4835"]}
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
May 20 04:53:55 qubic-monero minotari_merge_mining_proxy[683785]: 04:53 INFO  Checking if we must submit block #10344 to Minotari node with achieved target 649760743797 and expected target: 649760743797

[Snipa22]

Are you using reserve_offset? if so, it's incorrect, add 35 to account for the MM hash they add into the tx_extra, we had the same thing happen to us and lost several rewards to this bug.

[krypdkat]

I'm using reserve_offset yes. Also confirm the same bug as you mentioned. I have to modify reserve_offset on my end, very ugly patch.

To anyone that has the same issue and reads this thread: the issue is caused by wrong reserve_offset ( the proxy adds some extra data but forgets to increase reserve_offset )

[peterpan0708]

I'm using reserve_offset yes. Also confirm the same bug as you mentioned. I have to modify reserve_offset on my end, very ugly patch.

To anyone that has the same issue and reads this thread: the issue is caused by wrong reserve_offset ( the proxy adds some extra data but forgets to increase reserve_offset )

after change the reserve_offset, do we still need to build empty block(0 transactions) to produce blocks?

[krypdkat]

@peterpan0708 yes.

I tried again today, the issue still persists when including txs to the block:

tari block `#13454` and monero block `#3418720`:
Block submit request #{"id":"0","jsonrpc":"2.0","method":"submit_block","params":["10108a81c7c106ce99a1ad090ceae3c3f44254a84ddb033252c3f4cdc9af001dc9d8a84abb6889de8c4a28029cd5d00101ffe0d4d00101c093c2cacc1103c4e2c791110876b51bd9ce90d9cce8def1abd658e3e58022b6e99f8daccc2873965703210048ff21c8dfb345b9c14fb6b4f894d4db071400402ecef73a38d6fbb1b9a33153ceba0000332d05ed1eafa5bd54d9d5ce5f6a246cea68f0d913b378ab97c497cb1102110000000000000000000000000000000000000e0978dc344af6a7830d20ed732fce0e9b9561bec3b95cb57d827bdfa3fe186297f454973fe7e9881753e8c389cee66efd54c16ded4f9eeccd716de674d97847e44899b54aeec711dca4a544a5093d4b98749344c5c1505caf988f2f70523f3e21071e0e07415e60e1817eb7d3a9d32bd42f7e14ac644fa8d0ffd22ef3b83e83b1b02bad072de187e568f0b6c774597e9ead2c7ec73935bfad361c6c7b1f2cefed80d4f45eecc471b299b89279112513e06a74ef572f0b1a93a3b8a8030121a9b2bc045e013c596fc1b1d364ff605314d73db7b9e6a4d78008e32bf6d387d8a540712b7061fe5dcffd45fe183bc453f69cae72032a599ade2f1498f3a84dea276083e722a956cf41d156cfa7ba891cb1a2ebf145da914337d599c996439bbdd541120b7ac7fd7201cdde0de75b85e43a52271022bc454f284d980b0074e83f0b239387ec96b3a285aa5fd9a92d5e9ff51db44b893075d8aebca672607518e7e895e87eb199e60c67b5b19c9d8e051cd375ee1ea46a77fe0b130c8aa72ecae36ef942106555292530e0c607d5805b5db845ad4536f92c3c6a1b785549fb492bcc5aa2cae6a9cf9418b4476ebbcdab215496f1badb19801b6d986c58425b0a56c170"]}

I see a warning from MM Some sub-fields could not be parsed successfully from the Monero coinbase extra field and will be excluded. I already changed reserve_offset to 166. At the moment I'm clueless and don't have much time to debug the tari MM.

[peterpan0708]

@peterpan0708 yes.

I tried again today, the issue still persists when including txs to the block:

tari block `#13454` and monero block `#3418720`:
Block submit request #{"id":"0","jsonrpc":"2.0","method":"submit_block","params":["10108a81c7c106ce99a1ad090ceae3c3f44254a84ddb033252c3f4cdc9af001dc9d8a84abb6889de8c4a28029cd5d00101ffe0d4d00101c093c2cacc1103c4e2c791110876b51bd9ce90d9cce8def1abd658e3e58022b6e99f8daccc2873965703210048ff21c8dfb345b9c14fb6b4f894d4db071400402ecef73a38d6fbb1b9a33153ceba0000332d05ed1eafa5bd54d9d5ce5f6a246cea68f0d913b378ab97c497cb1102110000000000000000000000000000000000000e0978dc344af6a7830d20ed732fce0e9b9561bec3b95cb57d827bdfa3fe186297f454973fe7e9881753e8c389cee66efd54c16ded4f9eeccd716de674d97847e44899b54aeec711dca4a544a5093d4b98749344c5c1505caf988f2f70523f3e21071e0e07415e60e1817eb7d3a9d32bd42f7e14ac644fa8d0ffd22ef3b83e83b1b02bad072de187e568f0b6c774597e9ead2c7ec73935bfad361c6c7b1f2cefed80d4f45eecc471b299b89279112513e06a74ef572f0b1a93a3b8a8030121a9b2bc045e013c596fc1b1d364ff605314d73db7b9e6a4d78008e32bf6d387d8a540712b7061fe5dcffd45fe183bc453f69cae72032a599ade2f1498f3a84dea276083e722a956cf41d156cfa7ba891cb1a2ebf145da914337d599c996439bbdd541120b7ac7fd7201cdde0de75b85e43a52271022bc454f284d980b0074e83f0b239387ec96b3a285aa5fd9a92d5e9ff51db44b893075d8aebca672607518e7e895e87eb199e60c67b5b19c9d8e051cd375ee1ea46a77fe0b130c8aa72ecae36ef942106555292530e0c607d5805b5db845ad4536f92c3c6a1b785549fb492bcc5aa2cae6a9cf9418b4476ebbcdab215496f1badb19801b6d986c58425b0a56c170"]}

I see a warning from MM Some sub-fields could not be parsed successfully from the Monero coinbase extra field and will be excluded. I already changed reserve_offset to 166. At the moment I'm clueless and don't have much time to debug the tari MM.

thanky for the information, maybe we have to debug this on the monero stagenet. I think use MM is not a good way, in the end we must build the blob without merge mining proxy(image another merge mining coin comes out, then we can no longer use minotari_merge_mining_proxy). Also, the minotari_merge_mining_proxy has a memory leak bug.

[krypdkat]

@peterpan0708

I can mine block with txs now, after applying this patch from monero ocean and modifying the reserved_offset to 166