00:25:28 <flandre> hey im trying to (using the nixpkgs builder) cross compile monero-cli for s390x from x86_64
00:26:51 <flandre> 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
00:27:33 <flandre> i don't know a lot about cmake but i see there is a cross compilation flag in the CmakeList of the translations directory
00:28:40 <flandre> what environment variables should i set possiblyto get this to work?
00:30:24 <flandre> 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
00:30:42 <flandre> this would make my setup much less flexible
00:33:20 <flandre> 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 
00:33:34 <flandre> since usually thees process ordinary bank transfers 
00:39:48 <m-relay> <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
00:40:02 <m-relay> <m​cneb10:envs.net> and then copying the translation generator binary over the s390x build
04:28:23 <m-relay> <m​cneb10:envs.net> flandre: any progress?
10:00:04 <parazyd> Are there any Tari devs here in the channel?
10:00:39 <parazyd> 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?
10:03:54 <parazyd> Their Discord is just full of spam lmao
10:23:18 <m-relay> <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 :)
10:26:28 <parazyd> @rbrunner7: But the merge-mined chain still needs to verify that the XMR block was mined correctly
10:34:35 <sech1> 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)
10:36:29 <sech1> They don't need to run Monero node
10:37:08 <parazyd> 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?
10:37:16 <sech1> But Tari node needs to know how to calculate Monero PoW, and it needs to know the Monero block template format
10:37:54 <sech1> RandomX verification and Merkle tree proof check
10:38:27 <sech1> Because miner must prove that merge mined chain's hash was included in the Merkle tree
10:39:29 <parazyd> You're saying that knowledge of how a Monero block is built and verified is enough?
10:39:47 <sech1> Yes
10:40:32 <parazyd> I don't see how in this context the merge-mined chain can verify that the difficulty is the actual XMR mining difficulty
10:40:44 <parazyd> Or that doesn't matter and we should just accept the most work done
10:40:57 <sech1> 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
10:41:32 <sech1> It's miner's responsibility to also submit mined blocks to their Monero node
10:43:31 <parazyd> 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?
10:43:49 <parazyd> Assuming it is still enough work done for the merge-mined chain
10:45:23 <sech1> The same PoW hash can be used for both Tari and Monero, if it has enough difficulty
10:45:34 <parazyd> Understood, thanks
10:45:41 <sech1> Or only for Tari, if it's not enough for Monero
10:45:49 <parazyd> Yep
10:46:31 <parazyd> And practically, by using RandomX we achieve this?
10:46:49 <parazyd> It means that it has to have the exact same settings as Monero?
10:47:21 <parazyd> What about RANDOMX_ARGON_SALT?
11:30:47 <flandre> m-relay: i just woke up i posted thid begore sleep 5
11:30:59 <flandre> m-relay: i just woke up i posted thid before dleep so ppl could reply
11:49:24 <m-relay> <f​ede:xmr.mx> parazyd, RANDOMX_ARGON_SALT must not be changed for merge-mined chains
11:49:36 <m-relay> <f​ede:xmr.mx> it's used only for creating RandomX variants
11:49:40 <parazyd> Understood
11:49:59 <m-relay> <f​ede:xmr.mx> for example, RandomWOW has different ARGON_SALT, additionally to some other algo config changes
11:50:45 <parazyd> Yeah it makes sense. I now understand that with merge-mining, the algorithm/results should be the same for all chains involved
12:52:00 <m-relay> <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?
12:53:48 <m-relay> <s​trawberry:monero.social> Assuming Tari has a lower difficulty of course
12:59:31 <sech1> Yes, it's just a matter of which chain has higher difficulty
13:03:44 <m-relay> <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
13:05:51 <sech1> 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.
13:19:59 <m-relay> <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
13:27:55 <sech1> what's the point, it's just an unneeded extra step
13:28:30 <sech1> each chain can of course have their own definition of "meeting the difficulty"
13:28:36 <sech1> xor'ing a hash can be a part of it
13:29:05 <m-relay> <s​trawberry:monero.social> Hence it's possible to have a hash which is only a solution for Monero and not Tari
13:29:57 <sech1> Yes, but why. It only complicates things
13:30:45 <flandre> oh this is a brige i now realize
13:30:47 <flandre> d
13:30:59 <flandre> was sorta tired when i woke up
13:41:07 <m-relay> <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
13:41:21 <m-relay> <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
14:03:24 <sech1> That's how merge mining works, yes. It gives more financial incentives for miners of all involved chains.
14:04:33 <m-relay> <s​trawberry:monero.social> Yes, but the way it's currently implemented is a missed opportunity to increase payout frequency with no real downsides
14:13:38 <sech1> Payout frequency, yes, but not the overall amount paid.
14:13:47 <sech1> P2Pool increases payout frequency anyway
14:30:25 <m-relay> <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>
14:30:26 <m-relay> <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?
14:30:57 <sech1> This will be only a marginal increase
14:31:08 <sech1> Only when a Monero block is found
14:36:01 <m-relay> <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?
14:38:19 <sech1> That would be for merge mined chains to implement
14:40:28 <m-relay> <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
15:00:15 <m-relay> <f​ede:xmr.mx> i don't think this is a real issue
15:00:44 <m-relay> <f​ede:xmr.mx> solo miners are already a very VERY small chunk of the Monero network hashrate
15:01:15 <m-relay> <f​ede:xmr.mx> about 2.5% of the hashrate, currently
15:01:20 <m-relay> <s​trawberry:monero.social> Which is why I'm desperately suggesting anything which could help the size of that chunk increase
15:01:29 <m-relay> <f​ede:xmr.mx> P2Pool
15:01:47 <m-relay> <s​trawberry:monero.social> Read:
15:02:09 <m-relay> <f​ede:xmr.mx> there's no other solution
15:02:10 <m-relay> <s​trawberry:monero.social> And if we're counting P2Pool, solo miners are more like 10%
15:03:14 <m-relay> <s​trawberry:monero.social> Although some of that is pools which mine on top of P2Pool which could stop doing that at any moment
15:04:25 <sech1> Those pools are small
15:06:02 <m-relay> <f​ede:xmr.mx> a stronger against merge mining would be the hassle of setting up all the stuff
15:07:10 <m-relay> <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
15:07:59 <m-relay> <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
15:10:57 <m-relay> <s​trawberry:monero.social> It's not an issue, but a missed opportunity
15:14:45 <m-relay> <s​nowman:tetaneutral.net> Merge mining is awesome
22:23:53 <vthor> 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 
22:23:55 <vthor> 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 [
22:23:57 <vthor> import_key_images_binary, export_key_images_binary] (or blob instead of binary) to move that handling also back to monero-wallet-rpc.
22:26:09 <vthor> 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...