hey im trying to (using the nixpkgs builder) cross compile monero-cli for s390x from x86_64

and while getting quite far i have the issue that the translations generator binary thats build is being build for s390x not x86 thus when cross compiling and running it it will fail as the binary is build for s390x not x86_64

i don't know a lot about cmake but i see there is a cross compilation flag in the CmakeList of the translations directory

what environment variables should i set possiblyto get this to work?

i could probably get away with using binfmt or running it on the ibm Z10 mainframe directly but like if I can already cross coompile 99% of my nixos system configuration from x86 why would I then force native s390x building in my builder

this would make my setup much less flexible

note: <im aware that there is no real point to running the monero-cli on a 1200 kg mainframe> rather its just that I think it would make for a cool PR gag since 45/50 of the biggest banks own such Z series mainframes and they have a very long history of being used in the finance sector so running monero stuff on it would be sorta funny

since usually thees process ordinary bank transfers

<m​cneb10:envs.net> while i personally have no idea how to cross compile with cmake, have you tried compiling monero from src on x86_64 first

<m​cneb10:envs.net> and then copying the translation generator binary over the s390x build

<m​cneb10:envs.net> flandre: any progress?

Are there any Tari devs here in the channel?

I'm wondering how merge-mined blocks are verified. Are operators of Tari nodes also required to run a Monero node in order to verify the Monero PoW data?

Their Discord is just full of spam lmao

<r​brunner7:monero.social> parazyd: All that is needed is that your hash fulfills the difficulty requirements on the chain(s) that interest you. No need to "verify", and even less need to verify for another chain. With every hash, you can get entitled to mine two blocks, i.e. one on each chain, only one block on either one of the two chains, or none at all. Mostly none at all, of course :)

@rbrunner7: But the merge-mined chain still needs to verify that the XMR block was mined correctly

No, merge mined chain verifies Monero block syntax, extracts the merge mined hash from tx_extra, checks thr merge mining Merkle tree proof, and checks PoW (PoW is calculated by Monero rules)

They don't need to run Monero node

sech1: So it runs the RandomX verification only? Then the only assumption is that more work was performed than needed on the merge-mined chain to accept it, right?

But Tari node needs to know how to calculate Monero PoW, and it needs to know the Monero block template format

RandomX verification and Merkle tree proof check

Because miner must prove that merge mined chain's hash was included in the Merkle tree

You're saying that knowledge of how a Monero block is built and verified is enough?

Yes

I don't see how in this context the merge-mined chain can verify that the difficulty is the actual XMR mining difficulty

Or that doesn't matter and we should just accept the most work done

From Tari node point of view, it's just a very specific way to calculate PoW, which happens to also produce valid Monero blocks sometimes

It's miner's responsibility to also submit mined blocks to their Monero node

I understand. So choosing the same algorithm in the merge-mined chain as it is in Monero would mean we can accept the PoW with the highest difficulty, no matter if it's actually enough work to be included in the Monero chain?

Assuming it is still enough work done for the merge-mined chain

The same PoW hash can be used for both Tari and Monero, if it has enough difficulty

Understood, thanks

Or only for Tari, if it's not enough for Monero

Yep

And practically, by using RandomX we achieve this?

It means that it has to have the exact same settings as Monero?

What about RANDOMX_ARGON_SALT?

m-relay: i just woke up i posted thid begore sleep 5

m-relay: i just woke up i posted thid before dleep so ppl could reply

<f​ede:xmr.mx> parazyd, RANDOMX_ARGON_SALT must not be changed for merge-mined chains

<f​ede:xmr.mx> it's used only for creating RandomX variants

Understood

<f​ede:xmr.mx> for example, RandomWOW has different ARGON_SALT, additionally to some other algo config changes

Yeah it makes sense. I now understand that with merge-mining, the algorithm/results should be the same for all chains involved

<s​trawberry:monero.social> Maybe this is a question for monero-pow, but assuming I'm merged mining, are all Monero solutions also Tari solutions, but not vice versa?

<s​trawberry:monero.social> Assuming Tari has a lower difficulty of course

Yes, it's just a matter of which chain has higher difficulty

<s​trawberry:monero.social> I've been thinking about ways to increase payout frequency for miners and thus reduce dependency on pools, and one way to do that could be to make Monero solutions not necessarily Tari solutions

That's not how merge mining works. All merge mined chains work on the same block template every time. All solutions are sent to appropriate chains if they meet their difficulty.

<s​trawberry:monero.social> Why not xor the hash with some Tari-specific constant before checking if it meets their difficulty? I don't see why the block template would need to change

what's the point, it's just an unneeded extra step

each chain can of course have their own definition of "meeting the difficulty"

xor'ing a hash can be a part of it

<s​trawberry:monero.social> Hence it's possible to have a hash which is only a solution for Monero and not Tari

Yes, but why. It only complicates things

oh this is a brige i now realize

d

was sorta tired when i woke up

<s​trawberry:monero.social> Currently if someone gets the Monero solution, they get all the merge mined coins too, which makes mining more of a lottery and raises the level at which solo mining becomes practical

<s​trawberry:monero.social> It might not seem like a big deal when we're only merged mining 1 or 2 small projects, but it's better than nothing and scales with the number of coins involved

That's how merge mining works, yes. It gives more financial incentives for miners of all involved chains.

<s​trawberry:monero.social> Yes, but the way it's currently implemented is a missed opportunity to increase payout frequency with no real downsides

Payout frequency, yes, but not the overall amount paid.

P2Pool increases payout frequency anyway

<s​trawberry:monero.social> I never claimed it would increase the overall amount paid. Yes, P2Pool increases the frequency, but at the cost of block space used by big consolidations of small outputs. Assuming miners only want XMR, merged mining also uses block space when swapping the other coins to XMR, but the difference is that unlike with P2Pool, this downside is inherent to merged mining and isn't option<clipped message>

<s​trawberry:monero.social> al. If we've already accepted that tradeoff for other benefits of merged mining, why not take increased frequency for free?

This will be only a marginal increase

Only when a Monero block is found

<s​trawberry:monero.social> I accept it'll be marginal for now, but it'd matter a lot more in a LTC+DOGE situation. Is that not the plan? If not, why not?

That would be for merge mined chains to implement

<s​trawberry:monero.social> True, I should really be pitching this to someone from Tari instead as redefining what it means to meet the Tari difficulty can only be done on their end

<f​ede:xmr.mx> i don't think this is a real issue

<f​ede:xmr.mx> solo miners are already a very VERY small chunk of the Monero network hashrate

<f​ede:xmr.mx> about 2.5% of the hashrate, currently

<s​trawberry:monero.social> Which is why I'm desperately suggesting anything which could help the size of that chunk increase

<f​ede:xmr.mx> P2Pool

<s​trawberry:monero.social> Read:

<f​ede:xmr.mx> there's no other solution

<s​trawberry:monero.social> And if we're counting P2Pool, solo miners are more like 10%

<s​trawberry:monero.social> Although some of that is pools which mine on top of P2Pool which could stop doing that at any moment

Those pools are small

<f​ede:xmr.mx> a stronger against merge mining would be the hassle of setting up all the stuff

<f​ede:xmr.mx> some miners that currently mine on P2Pool or solo might prefer to start mining on a pool with merge mining support rather than setting everything up

<s​trawberry:monero.social> Sure, there are arguments against merge mining, but it's already happening and not something I think we can even stop

<s​trawberry:monero.social> It's not an issue, but a missed opportunity

<s​nowman:tetaneutral.net> Merge mining is awesome

How probable is it that if I add two endpoints to monero-wallet-rpc and make a PR it will get added? The two endpoint would be export_key_images and import_key_images in the binary format monero-wallet-cli uses. Reasoning behind, I use on both ends monero-wallet-rpc and would be just fine with the json, but to be compatible sending it over UR it needs to be the binary format, I startet to write methods to convert from json to binary and encrypt, and decrypt

and convert back to json, but it is an endless rabbit hole. I got so fare everything together and I have not chcked in the begining `generate_chacha_key` because idiotically I assumed that it is a chacha relatd implementation, what of course it isn't, but uses again cn_slow_hash, what then is trying to eat a sole spaghetti out of the plate. So, as a quick fix I see the best option to extend monero-wallet-rpc with that two endpoints, probably with the names [

import_key_images_binary, export_key_images_binary] (or blob instead of binary) to move that handling also back to monero-wallet-rpc.

I will probably only start to hate myself every time I need to compile monero-wallet-rpc for linux/win32/macOS (probably will hate the most) and RPi. So if I would implement it and get it inside the source with a PR I have this frog only until the next version to swallow...