03:23:08 <Guest53> Hello so I'm porting RandomX to llvm - anyone have some idea what IADD_M does?
06:22:48 <xmrscott[m]> Thanks ErCiccione for taking on moderating the upcoming -dev meeting
06:27:14 <selsta> Guest53: try asking in #monero-pow
09:48:30 <ErCiccione> xmrscott: No problem, i'll create a dedicated issue for it today
10:13:32 <ErCiccione> jberman94: will you be able to participate to the dev meeting this saturday at 17:00? Would be good to have an overview of the status of the view tags PR
11:09:46 <ErCiccione> ping vtnerd as well
11:43:27 <Guest38> Anyone home?
11:51:43 <moneromooo> If you have a question about monero development, just ask and wait.
11:51:55 <RobertDiMonero> ok
11:52:10 <RobertDiMonero> Regarding the 'decoy selection bug' from 7  months ago:
11:52:11 <RobertDiMonero> Were the outputs of those transactions only vulnerable during that specific 20min time window, within the first 2 blocks?
11:52:11 <RobertDiMonero> In other words, if the same (7-month old) outputs were analysed 'today' would they still reveal any vulnerable info, or did the outputs become increasingly obfuscated (and improbable to analyse) as more time and blocks passed by?
11:54:28 <moneromooo> jberman[m] would know best but as a general rule, information is not lost on the blockchain. You can lose information that's not on the chain, such as exact timing of events, but that's it.
11:56:15 <RobertDiMonero> Ok. Should I wait for jberman[m] to respond, or can private msg him/her?
11:56:30 <moneromooo> Wait until they see that.
11:56:47 <RobertDiMonero> Ok.
13:26:03 <RobertDiMonero> I keep getting pinged out, and lose view of the chat log. is there a best time to catch jberman[m] or the other dev-mods online? e.g. after 8pm GMT?
13:26:33 <sethforprivacy> RobertDiMonero: You can also join via Matrix, and not have to worry about those issues.
13:27:00 <sethforprivacy> RobertDiMonero: https://forum.monero.space/d/79-how-to-join-the-monero-core-team-matrix-server-web
13:28:20 <RobertDiMonero> Ok, thanks. I was thinking about joining but I only had the one question so it seemed a little overkill (I probably won't be using it again)
15:54:32 <ErCiccione> New issue for the dev meeting: https://github.com/monero-project/meta/issues/655
18:30:23 <WillMorrison[m]> How fast is the wallet RPC for making a payment gateway? Do I need some custom solution or what is the best strategy to accept payments?
18:31:58 <moneromooo> The network code is not super fast. 
18:32:11 <moneromooo> Though it got better.
18:32:30 <moneromooo> That's something you can test fairly easily too.
18:33:04 <moneromooo> But if you don't get an order a second, it'll be fine I think.
18:33:29 <nikg83[m]> WillMorrison[m]: https://github.com/monero-integrations
18:33:45 <WillMorrison[m]> nikg83[m]: Yes, those use the JSON RPC. Is that fast enough for generating many addresses, polling for transactions, and sending transactions all the time?
18:34:07 <WillMorrison[m]> Not sure if it can handle concurrent requests. From what I have read it can't.
18:34:35 <hyc> prob no issue with read-only requests
18:35:51 <notmtth[m]> Hello, Im having a problem compiling my miner. How do I tell the compiler to use software based AES?
18:36:19 <moneromooo> Try -mno-aes maybe ?
18:36:42 <hyc> edhat's x86-specific
18:36:50 <hyc> *that's
18:41:12 <moneromooo> Is the latest person who said they'd add a rwlock to replace the blockchain lock here ?
18:41:21 <moneromooo> If so, did you get anywhere yet ?
18:43:50 <notmtth[m]> I tring to do it on a raspberry pi4. 
18:43:50 <notmtth[m]> Also found this online https://monero.stackexchange.com/questions/13268/how-to-resolve-the-illegal-instruction-core-dumped-error-on-raspberry-pi-4-u
18:43:54 <notmtth[m]> Thanks in advance 
18:45:10 <moneromooo> What's the problem compiling anyway ? You can paste on paste.debian.net and post the URL here.
19:11:20 <jberman[m]> that was @midnightmage, haven't heard from them since they first started looking into it
19:13:16 <jberman[m]> <RobertDiMonero> "Were the outputs of those..." <- First clarification: it actually turned out to be the case that newly spent transactions were not guaranteed identifiable as linkable (I.e. the published bug was not as severe as was first thought) because there was at least 1 implementation in the wild that didn't have the issue (MyMonero was using that). See this post explaining
19:13:16 <jberman[m]> (https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html)
19:14:47 <jberman[m]> Second: assume you receive a tx0, then a tx1 spending the Monero received from tx0. If tx1 was spent 10 blocks later, and the block it is spent in has >100 outputs in it (most tx's have 2 outputs, some have more, max is 16, and the avg around that time was ~63 outputs per block), then tx1 isn't as affected by the bug. If tx1 was spent 11 blocks later, and blocks 10 and 11 combined have >100 outputs, then tx1 isn't as affected, etc.
19:15:26 <jberman[m]> *wasn't as affected. it was patched
19:17:11 <jberman[m]> <RobertDiMonero> "In other words, if the same (7-..." <- As time goes on, more people have likely referenced tx0 as decoys in their own tx's. Like moneromoo said, you can't erase the above having happened from the chain (i.e. it's not as though that the above cannot be checked still), but I would say yes it is the case that this offers greater plausible deniability that necessarily does provide increased obfuscation in some capacity
19:18:23 <jberman[m]> <ErCiccione> "jberman94: will you be able to..." <- Yep I'll be there
19:18:59 <jberman[m]> not sure who jberman 94 is
19:22:07 <vtnerd> ErCiccione: yes, I should be able to make that meeting time
19:26:10 <gir> anyone seen this error before:
19:26:12 <gir> Permission denied (src/ip_resolver.cpp:520)
19:26:31 <gir> when launching daemon
19:32:38 <ErCiccione> <jberman[m]> "not sure who jberman 94 is" <- I thought that was your matrix account
19:36:09 * WillMorrison[m] uploaded an image: (14KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/MFiuPqlyIFrGOvFIVFtdwHxj/screenshot-2022-01-27-14-35-57.png >
19:36:17 <WillMorrison[m]> Is this where the wallet RPC server should stop or is it hung up?
19:44:09 <gir> it said core rpc server initialized ok
19:44:21 <gir> then permission denid -> aborted
19:52:00 <gir> i should mention this is on an android phone via userland
20:05:03 <Rucknium[m]1> <WillMorrison[m]> "Is this where the wallet RPC..." <- I believe that means that it is operating normally. It is waiting for commands.
20:08:02 <notmtth[m]> <moneromooo> "Try -mno-aes maybe ?" <- Im using Cmake. Actually im trying to compile wownero software. They told to come here to get some effective support 
20:08:57 <notmtth[m]> This is the error
20:08:57 <notmtth[m]> `Program received signal SIGILL, Illegal instruction.
20:08:57 <notmtth[m]> 0x0000aaaaab293524 in aes_expand_key ()`
20:09:18 <notmtth[m]> I tried switch to other arch versions but nothing works 
20:17:27 <wernervasquez[m]> notmtth: I had a similar issue with another open source project. How old is your processor? Your processor might not support the instruction and the code does not gracefully fall back to another implementation.
20:17:54 <moneromooo> You said you had trouble compiling. Your error sounds like you are running it.
20:18:03 <notmtth[m]> Its recent 
20:18:07 <notmtth[m]> Let me send the exact processor I have one second 
20:18:23 <moneromooo> If it's compiled, try running with MONERO_USE_SOFTWARE_AES-1, but that's more #monero now.
20:19:01 <wernervasquez[m]> Hmm. Well. What is the processor and are you sure it actually supports the instruction?
20:19:23 <notmtth[m]> moneromooo: Tried already
20:19:39 <notmtth[m]> wernervasquez[m]: Idk if it does, thats why Im here 
20:20:09 <notmtth[m]> The processor is a Cortex-A72 ARM v8 64 bit
20:20:24 <sech1> not all ARM cpus support AES
20:20:28 <sech1> even within the same model
20:20:46 <sech1> "cat /proc/cpuinfo | grep aes" will tell you more
20:21:47 <notmtth[m]> Thanks 
20:22:05 <notmtth[m]> No output 
20:24:05 <wernervasquez[m]> I assume that without the "| grep aes" it does return something, though?
20:24:37 <notmtth[m]> It does
20:24:53 <notmtth[m]> Thats the model Raspberry Pi 4 Model B Rev 1.2
20:24:54 <notmtth[m]> * the model: Raspberry
20:25:29 <sech1> Raspberry Pi doesn't have AES
20:25:39 <sech1> it would return something like "Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid" if it had AES
20:26:27 <sech1> RPi manufacturer saved money by using cheaper SOC's without AES support
20:29:09 <notmtth[m]> Oh
20:29:53 <notmtth[m]> Thank you answering 
20:29:54 <wernervasquez[m]> notmtth: can you run the armv7 version mentioned in the stackexchange you  referenced?
20:30:47 <notmtth[m]> Im actually trying to compile some wownero software
20:30:48 <notmtth[m]> There is now armv7 version 
20:48:00 <wernervasquez[m]> notmtth: Can you run the monero armv7 build? Can you compile and run the monero armv7 build? (That's what I would do at this point, then perhaps you may be able to tease out the difference between that and the wownero effort).
20:48:31 <notmtth[m]> I could yeah
22:49:59 <chaser[m]> could the Jamtis seed format be constructed such that the first 12 words are BIP-39 compliant, and the rest contain the  birth block or the birthday?
22:51:20 <UkoeHB> tevador ^
22:52:00 <UkoeHB> chaser[m]: https://github.com/tevador/polyseed maybe if you don't find the answer you want, you could add an Issue to that github
22:54:31 <chaser[m]> UkoeHB: thanks for the directions!
23:00:00 <chaser[m]> okay, there's no way polyseed could work with BIP-39, it uses a whole another take on almost every aspect