03:49:38 <hyc> is someone already looking into the windows build failures on CI? like this? https://github.com/LMDB/bitmonero/runs/4056976328?check_suite_focus=true#step:4:789
03:50:34 <selsta> hyc: yes, it's included here https://github.com/monero-project/monero/pull/7997
03:50:42 <hyc> ok cool
03:55:00 <hyc> then as usual, I'll continue ignoring the CI failure emails
03:55:48 <selsta> not aware that github sends mail about it
03:55:58 <selsta> it never did for me lol
03:56:22 <hyc> maybe they're in your spam folder
06:15:41 <mj-xmr[m]> hyc: could you explain this one?
06:15:41 <mj-xmr[m]> https://en.wikichip.org/wiki/arm/armv8#Crypto_Extension
06:15:46 <mj-xmr[m]> "Crypto Extension
06:15:46 <mj-xmr[m]> ARMv8 introduced hardware acceleration for cryptography. Those operations were added to complement, but not replace, traditional crypto accelerators. Geared for small instruction-level crypto support, two main algorithms were supported: AES and SHA (SHA-1 and SHA-256). "
06:23:07 <mj-xmr[m]> https://paste.debian.net/1217430/
06:50:12 <mj-xmr[m]> ^ That's during building your branch on a 64-bit OS of RPi4.
07:23:16 <aberdeenik[m]> How can we reward existing vendors who accept btc to also accept xmr? Can monero fund be used for business development activities? Say like hiring a sales manager responsible for converting high value btc vendors to switch to xmr?
08:45:18 <rbrunner> I just compiled master. Seems to me that automatic background syncing in the CLI wallet is broken. Only visible symptom, with "set_log 2", are error messages as such: "Invalid hashing blob:"
08:45:32 <rbrunner> They seem to appear with the background sync thread frequency.
08:45:43 <rbrunner> Checked with testnet as well as mainnet
08:45:54 <rbrunner> Is something known in this direction?
08:46:40 <sech1> does the CLI wallet show "out of sync" until you run "refresh" manually?
08:46:48 <rbrunner> Yes.
08:46:58 <sech1> hmm, I have the same on release branch
08:48:29 <sech1> I'll double check now
08:48:32 <rbrunner> I did not yet debug, but it does seem not to call refresh internally, because I log that in particular, with set_log +wallet.wallet2:DEBUG
08:49:30 <rbrunner> Or at least does not get far enough because of that "Invalid hashing blob" error
08:50:29 <rbrunner> (By coincidence, I am working on improving refresh, but branched about 6 weeks ago.)
08:51:36 <sech1> nope, my wallet is fine: https://paste.debian.net/hidden/f205dc95/
08:52:01 <sech1> this is built from commit https://github.com/monero-project/monero/commit/61e16307c
08:53:02 <sech1> both CLI wallet and monerod
08:53:10 <rbrunner> Alright, so you are on the release branch, I am on very latest master. If something went wrong, it probably did in the last 6 weeks or so
08:55:19 <ErCiccione> Please CORE take a look at: https://github.com/monero-project/meta/issues/575#issuecomment-955661405
08:56:27 <ErCiccione> it's really time to change things when it comes to maintain Monero's infrastructure. The situation is far from good and i'm tired of pinging people continuously
08:57:07 <ErCiccione> I'm proposing again: Please hire somebody to take care of Monero's infrastructure.
08:57:16 <ErCiccione> luigi1111 binaryFate fluffypony ^^
09:14:32 <rbrunner> It seems to fail in 'NodeRPCProxy::get_rpc_payment_info' after the daemon somehow did not return expected values from a 'rpc_access_info' call. Strange.
11:51:49 <hyc> mj-xmr[m]: what do you need explained?
11:52:08 <hyc> those are testing whether the compiler supports crypto instructions
11:52:54 <hyc> since the code is doing runtime selection, the AES code is always generated.
11:52:57 <mj-xmr[m]> hyc: Aren't these clues, that the Arm8 CPU on a 64-bit OS supports hardware AES?
11:53:14 <hyc> oh come on, we've been through all of this many times already
11:53:29 <hyc> they are an optional instruction set extension, and Broadcom chose not to implement them
11:53:29 <mj-xmr[m]> Yeah but this is a mixed signal here.
11:53:44 <mj-xmr[m]> And I realize that the compilation only worked with AES=OFF
11:54:04 <mj-xmr[m]> hyc: Understood.
11:56:03 <hyc> *compilation* works either way. *execution* only worked before with AeS=OFF but it will work now wih AES=ON because at runtime we will detect its usability and leave it on or off accordingly
11:58:15 <aberdeenik[m]> How do devs get paid for monero development?
11:58:41 <moneromooo> ccs.getmonero.org is the main one, someone also created a bounties website recently.
12:01:01 <atomfried[m]> <moneromooo> "Maybe a common file in blockchai..." <- there does not seem to be such a common file in blockchain_utilities, i guess i will just create a header in blockchain_utilities for this
12:02:14 <moneromooo> OK, or cryptonote_core.h would seem ok too if you need to use it in other places.
12:02:36 <atomfried[m]> ok i will have a look
12:15:46 <luigi1111> ErCiccione: thanks
12:18:33 <mj-xmr[m]> <hyc> "*compilation* works either way...." <- Yep. Thanks. 
15:01:32 <binaryFate> ErCiccione: We're about to move the matrix infra to a new server soon (probably this week). After that we can look at fixing bridges.
15:03:10 <ErCiccione> binaryFate: my main concern is not the bridge. Please see https://github.com/monero-project/meta/issues/575#issuecomment-955661405
15:03:26 <ErCiccione> but i'm happy to hear something is moving
15:06:49 <binaryFate> it's moving specifically for matrix right now. Generally it's not an easy issue to just get a random paid person to help, as some part of the infrastructure are critical. But I hear your frustration, we'll push the matomo thing next
15:09:35 <ErCiccione> thanks binaryFate
15:17:28 <ErCiccione> binaryFate: i suggest to use version not newer v1.43.0. They are having a regression in >1.44.0. They found the issue but it's not out in a release yet. Is pigeon taking care of the migration? I can talk directly to him in case
15:19:04 <sethsimmons> <ErCiccione> "binaryFate: my main concern is..." <- AFAIK everything possible has been done by the mod team and those with admin privs possible to help the bridge but obviously it has not resolved issues. We have tried many things, and the still missing bridging of #monero is pending Matrix teams involvement still, as they have not removed their user limit and have to manually connect bridges in large rooms like that.
15:19:04 <sethsimmons> I wonder if its tied to load on the Matrix server or some misconfig there, but as mentioned none of us have access to that infra so we can't even dig in there.
15:19:13 <ErCiccione> well =<1.44.0
15:19:42 <ErCiccione> > <@sethsimmons:monero.social> AFAIK everything possible has been done by the mod team and those with admin privs possible to help the bridge but obviously it has not resolved issues. We have tried many things, and the still missing bridging of #monero is pending Matrix teams involvement still, as they have not removed their user limit and have to manually connect bridges in large rooms like that.
15:19:42 <ErCiccione> > 
15:19:42 <ErCiccione> > I wonder if its tied to load on the Matrix server or some misconfig there, but as mentioned none of us have access to that infra so we can't even dig in there.
15:19:42 <ErCiccione> Yeah i think the problem is on the backend side. I don't think admincan do anything about it
15:19:48 <ErCiccione> *admins
15:19:52 <sethsimmons> * AFAIK everything possible has been done by the mod team and those with admin privs possible to help the bridge but obviously it has not resolved issues. We have tried many things, and the still missing bridging of #monero is pending Matrix teams involvement still, as they have not removed their user limit and have to manually connect bridges in large rooms like that.
15:19:52 <sethsimmons> As for the persistent bridge issues, I wonder if its tied to load on the Matrix server or some misconfig there, but as mentioned none of us have access to that infra so we can't even dig in there.
15:20:14 <sethsimmons> ErCiccione: Yeah, seems like it.
15:20:25 <binaryFate> Yes pigeons will help me with migration, ErCiccione good catch on version, please let him know.
15:21:06 <binaryFate> After migration to new server, I might reach out to you sethsimmons if we still have matrix-specific issues that are not obvious, if that's ok
15:21:32 <ErCiccione> sure np
15:22:46 <sethsimmons> binaryFate: Always game to help out where I can 🙂
15:36:13 <atomfried[m]> is there a clang-format file or something for monero?
16:18:40 <atomfried[m]> i created a PR for the `BlockchainAndPool`struct:
16:18:40 <atomfried[m]> https://github.com/monero-project/monero/pull/8033
16:20:31 <atomfried[m]> pls dont be to harsh its my first PR hahaha
17:34:58 <just_looking_0xb> Hello, just for confirmation, randomX never uses blake2{b,s} with a secret key ? 
17:34:58 <just_looking_0xb> Key as defined in RFC 7693, Blake2's norm 
17:34:58 <just_looking_0xb>  
17:34:58 <just_looking_0xb> > If a secret key is used (kk > 0), it is padded with zero bytes and set as d[0].  Otherwise, d[0] is the first data block.  The final data block d[dd-1] is also padded with zero to "bb" bytes (16 words).
18:51:46 <mj-xmr[m]> hyc & selsta , my Rpi4 test logs are attached in 8031
18:52:31 <selsta> might have to start it in gdb
18:52:43 <selsta> otherwise we don't know where it segfaults
18:53:33 <selsta> mj-xmr[m]: and without the patch all tests pass 100%?
18:55:40 <mj-xmr[m]> selsta: https://github.com/monero-project/monero/pull/8001#issuecomment-940684588 
18:55:40 <mj-xmr[m]> This was the last one which I checked and it passed 100%
18:55:58 <mj-xmr[m]> But I can try master just to be sure.
18:56:22 <mj-xmr[m]> and if it's OK, I will gdb the patch, ok.
18:57:02 <selsta> rbrunner: can you confirm if you see this issue in release too?
18:57:10 <selsta> mj-xmr[m]: thanks
19:22:44 <rbrunner> selsta: Sorry, false alarm. It was my mistake after all. I had messed up the timer in simplewallet.cpp that drives the refresh thread
19:23:21 <rbrunner> And the error that I reported has nothing to do with my problems. Not sure whether that one is harmless or not, per se.
19:25:48 <rbrunner> It must be new however. With my six-weeks old branch I don't get any ""Invalid hashing blob:" reported, with master I do.
19:33:17 <rbrunner> That error is probably very easy to overlook because simplewallet causes it, and that usually logs into a file where few people may check, or does not log at all