00:01:12 <hinto[m]> where does monero-wallet-cli source entropy for keys? in the context of linux
00:42:59 <selsta> moneromooo: they replied https://github.com/monero-project/monero/issues/8478#issuecomment-1204555495
02:46:16 <Guest27> I wrote a code in curiosity from ztm2 for point addition in python and at the end for point compression i just simply saw the x is even or odd and thought to change the highest bit according ztm2 but leave it i was here to ask that answer I am getting is in float how could I get in hexadecimal
02:47:28 <Guest27> It would be greate help if you reply don't say it's not related to monero, it's the way i could understand it,i am by the way i am now part of this community.
09:13:05 <Guest57> Hi! After hardfork can i generate transactions without view tags (this feature https://github.com/monero-project/monero/pull/8061) or is it required?
09:13:27 <selsta> they are required
09:14:12 <Guest57> Ty
09:18:06 <Guest57> Can you point to changes in output scheme in PR? (I'm not familiar with C and monero repo) So i can add new field to transaction, when i send transaction via sendRawTransaction.
09:22:52 <selsta> how do you create transactions currently?
09:23:20 <sech1> he left
09:42:27 <jberman[m]> for when they come back: https://github.com/monero-project/monero/pull/8061/files#diff-de7d9f62b5fbb32234cfef41c3c08f1231bcdd846a3c20202ce23e77479add7fR77-R154
09:46:28 <jberman[m]> and a more pointed explanation on how to derive the view tag: https://github.com/monero-project/monero/issues/8406#issuecomment-1170110231
10:23:23 <afungible[m]1> <UkoeHB> "afungible: I see, yes that would..." <- I updated my findings here: https://github.com/monero-project/monero/issues/8480
10:23:23 <afungible[m]1> moneromooo so it indeed does look like a problem with the current wallet code.
10:43:05 <moneromooo> I didn't expect that. Thanks for the detailed report.
10:45:32 <moneromooo> Would you mind doing this with --log-level 2 in the wallet ? It logs a lot about what it's doing.
10:56:34 <SanadaYukimura[m> Hi team, there was a paper that was published in 2020 to reduce proof size - ‘Omniring: Scaling Private Payments Without Trusted Setup’
10:56:34 <SanadaYukimura[m> Was there any voting or feedback on this paper? 
10:56:34 <SanadaYukimura[m>  
10:57:45 <SanadaYukimura[m> https://eprint.iacr.org/2019/580
10:58:05 <moneromooo> IIRC it was looked at by either sarang or surae, and it was determined that triptych was better overall.
10:58:12 <sech1> Better ask it #monero-research-lab
10:58:19 <moneromooo> Since then, seraphis was determied to be even better.
12:03:47 <afungible[m]1> <moneromooo> "Would you mind doing this with -..." <- Sure, I just added the log as requested here (with --log-level 2):
12:03:47 <afungible[m]1> https://github.com/monero-project/monero/issues/8480#issuecomment-1205156941
12:13:07 <moneromooo> Thanks. If I get you a patch with extra logs, can you try again with it ?
12:13:54 <moneromooo> It's considering only two outputs, so I'll add logs to see why it's not considering the othe ones.
12:25:40 <moneromooo> I posted the patch on the bug.
13:19:08 <afungible[m]1> <moneromooo> "I posted the patch on the bug." <- Sure, saw it. Thanks. Let me add the patch, and get the detailed logs to you.
15:32:18 <moneromooo> When spending from an account, and minors aren't specified, is monero supposed to spend for only one minor ?
15:32:51 <moneromooo> I didn't think this was the case, but I see a "Spending from subaddress index X" when no minor is specified...
15:39:48 <moneromooo> afungible[m]1: it considers all 12 outputs, but they're not in the same minor subaddress, so picks a random minor, and only spends that one.
15:40:09 <moneromooo> I didn't think it was what it was meant to do, but I'm guessing it's for privacy.
15:41:05 <moneromooo> It should send everything if you add this after sweep_all: index=0,1,2,3,4,5,6,7,8
15:41:30 <moneromooo> I don't see a way to tell it "all". But assuming it's that way for privacy reasons, you mau not want to do that.
15:42:00 <afungible[m]1> Let me try this.
15:42:16 <moneromooo> Though the help says "indices" are chosen, not one index.
15:44:49 <moneromooo> So, sorry, I don't know *why* it is done that way. Let's wait for someone who does.
15:45:59 <afungible[m]1> Previously, I also tried what I did with GUI wallet providing (all) for amount. I reckon it uses sweep_all? I still had dust balance left. Let me try indices on console wallet & get back.  
15:46:08 <moneromooo> Spending from different addresses would probabilistically link them so it's a good reason not to, but for sweep_all, it seems counterintuituve.
15:46:28 <moneromooo> I believe it does.
15:52:13 <ofrnxmr[m]> moneromooo:  sorry to change topics, but was wondering:
15:52:13 <ofrnxmr[m]> Each time I open a wallet, It downloads 8.5mb from my node. While not "a lot", it does it everytime (even back to back).
15:52:13 <ofrnxmr[m]> Is there a way to cache/reduce this data/usage? (As an efficiency improvement) 
15:55:19 <ofrnxmr[m]> Over lan, implies ~ 1 second to show "synched", but a 600kbps down (poor connection speeds or using an onion, etc) results in > 10 seconds to load a wallet. (Again, it downloads the days each time the wallet is opened)
15:55:19 <ofrnxmr[m]> Tested using monerujo v18 and cake wallet v17 + my node v18
16:00:35 <moneromooo> Yes, set FIRST_REFRESH_GRANULARITY to 1 in wallet2.cpp
16:01:24 <moneromooo> Oh, or use --trusted-daemon.
16:11:49 <Guest49> https://paste.debian.net/hidden/8d20ce04
16:12:14 <Guest49> If anyone sees it and replies about it it would be great thing for me.
16:13:12 <UkoeHB> Convert to hex if you want to compare
16:16:24 <ofrnxmr[m]> moneromooo: thanks a million
16:34:32 <afungible[m]1> <moneromooo> "I don't see a way to tell it "..." <- Well 🙂
16:34:32 <afungible[m]1> https://github.com/monero-project/monero/issues/8480#issuecomment-1205491666 
16:38:19 <Guest38> UkobeHB: how could I? I tried to convert into hex in both py and c it's not happening. Do you have any method.
16:55:12 <Guest38> I could do it for 8 bytes but not know how to do for 32 bytes
16:56:51 <moneromooo> To convert N consecutive bytes from address A: epee::string_tools::buff_to_hex_nodelimer(std::string((const char*)A, N))
16:57:52 <UkoeHB> I am not a python programmer
16:58:00 <moneromooo> Or for (int i = 0; i < N; ++i) printf("%02x", A[i]); if non-epee code.
17:00:07 <moneromooo> (if A points to bytes, cast if not)
18:47:59 <sethforprivacy> binaryFate: Forgot to remind, please send monero-announce email ASAP!
18:48:50 <sethforprivacy> sethforprivacy: (In reference to the v0.18.0.0 binary releases)
20:29:02 <sech1> jberman[m] https://github.com/Snipa22/node-cryptonote-util/ doesn't have viewtags support and many pools use it, it's kind of urgent
20:33:40 <moneromooo> In a totally unrelated subject, I have found a good way to fight pools...
20:36:44 * netrik182 is curious
20:42:32 <selsta> sethforprivacy: we did already send out a mail for v0.18.0.0
20:43:24 <sethforprivacy> selsta: Hmm, must have missed it somehow then, sorry about that
20:44:17 <selsta> can you check your email if you received it? I personally received it but not sure if everyone did
20:44:25 <selsta> bF said the docker container crashed or so
20:45:44 <sech1> I received the announce email on July 25th
20:45:46 <sethforprivacy> I did not but looks like I might not be subscribed anymore with my current email addresses.
20:45:58 <sethforprivacy> I'm sure it's just me 🙂
20:46:08 <sethforprivacy> PEBCAK issue 😅
20:51:37 <netrik182> I got the mail on 24th 
20:51:50 <sech1> It probably depends on your timezone
20:52:30 <netrik182> Yes, it was 21:45 UTC
20:53:24 <sech1> jberman[m] regarding node-cryptonote-util, I'm going to look into it tomorrow unless you start working on it first
21:00:00 <jberman[m]> Will do it today
21:21:38 <sech1> bug report: https://github.com/Snipa22/nodejs-pool/issues/496
21:55:47 <ragn4> hello anyone know why can't compile monero in aws vps? (ubuntu 2 cpu 4gb ram)
22:02:46 <selsta> ragn4: what error do you get?
22:03:40 <ragn4> after 18% the cpu load average become 500%
22:04:23 <ragn4> and it crash, already tried on 3-4 different cpu type/config and same...
22:08:40 <moneromooo> Are you using any kind of -j make flag ?
22:09:06 <ragn4> yes
22:09:07 <ragn4> make -j2
22:10:01 <ragn4> ubuntu-jammy 22.04 x64
22:10:16 <moneromooo> Then don't.
22:11:06 <ragn4> ok i'll try without it
22:27:26 <ragn4> yep working good without the -j2
22:29:54 <hyc> 4GB RAM isn't enough for parallel compile
22:31:04 <hyc> it's about perfect for a serial compile tho. My laptop has 64GB RAM, make -j16 works fine here
22:31:16 <hyc> (16 thread / 8 core Ryzen)
22:32:22 <Epsilon> Powerful laptop.
22:33:07 <hyc> life's too short to be waiting for compiles to finish
22:38:58 <ofrnxmr[m]> 17hr gitian build 🥲
22:51:31 <hyc> core_rpc_server.cpp seems to be a long pole in the compile
22:52:04 <hyc> but from a fresh "make clean" it takes 1m55s to build the tree, no tests
22:53:53 <hyc> "time" claims max RSS was 2.5GB. so I guess make -j2 should work with at least 5GB of RAM
22:55:49 <ragn4> yea but to pay vps the next size is 8gb and it's expensive :X
22:56:33 <hyc> yeah, vps aren't really ideal for building
23:44:54 <woodser[m]> I'm able to segfault monero-wallet-rpc and corrupt the wallet files by calling export_outputs then import_outputs with the result. the calls succeed, indicating 0 outputs were imported. but then these errors start appearing when the next transaction is sent. my tests send funds back to the original wallet so it might... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8aa9b17827dbb6e76a1fde4194eb1612e03ad51c)
23:57:27 <selsta> woodser[m]: can you revert https://github.com/monero-project/monero/pull/8179 and check if you are still able to reproduce the issue?