02:08:42 <noocsharp> i'm getting frequent memory allocation failure related crashes on openbsd in monerod. any clue why this could be happening?
03:09:16 <hyc> do you have any swap space?
03:12:15 <noocsharp> yes, 16G ram and 16G swap
03:15:52 <noocsharp> although i suppose it could be hitting the data area limit which is much lower
03:16:51 <noocsharp> ulimit that is
03:17:04 <hyc> certainly a possibility
03:17:44 <hyc> not a good idea to enforce a vmem ulimit on monerod
03:21:03 <noocsharp> not sure why i didn't think of that before especially after having to increase the ulimit on the build lol
03:26:42 <noocsharp> will monerod eat all my ram if given the chance?
03:31:02 <hyc> yes. but it will also give it back immediately if the OS needs it for something else.
03:52:05 <noocsharp> how? the only way i can think of is to wait for an allocation failure and free a bunch of memory when it happens
03:53:53 <noocsharp> also thanks, i bumped the data size limit and it seems to be working much more quickly and without crashing
07:51:51 <moneromooo> It should really not crash due to alloc failure in the first place. Can you share the crash stack trace from gdb ?
14:59:47 <hanshan[m]> Hello. Listen to my tale of woe.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/e13e9535918575a23b0371aea41ec34bce83f985>)
15:04:55 <hanshan[m]> Oh, I am aware of the ability to generate keys at
15:04:55 <hanshan[m]> https://xmr.llcoins.net/addresstests.html
15:04:55 <hanshan[m]> however, using that site, the generated main address and mistaken "Priv view key" combination is not accepted by --generate-from-keys
15:22:13 <moneromooo> I thought monero-wallet-cli was performing reduction on what you give it, but if not:
15:28:22 <moneromooo> https://paste.debian.net/hidden/10863164/
15:28:35 <moneromooo> Adapt paths to libs ofc.
15:29:04 <moneromooo> And just run it, input key when asked.
15:32:13 <hanshan[m]> Thank you.
15:32:13 <hanshan[m]> So to be clear I should be able to use the output as my private view key?
15:32:13 <hanshan[m]> Do i need to generate the corresponding main address? and then generate the wallet from that (plus original priv spend key)?
15:32:47 <moneromooo> Yes, assuming bisq did just a reduce32 on what you gave it and you give this program the same thing.
15:33:07 <moneromooo> If you restore with simplewallet, you'll get the address from it.
15:33:32 <moneromooo> Do this on both spend and view key if you gave public for both.
15:33:40 <moneromooo> If you gave just one, it's the spend key.
15:33:54 <moneromooo> Oh you said view. Then just view key
15:35:16 <moneromooo> Though from what you said, it's likely it won't work as is, since the wallet address doesn't correspond to that view key...
15:36:01 <moneromooo> If bisq sends to the address you gave, you should see your coins, regardless of the view key you gave.
15:36:13 <moneromooo> bisq would just not see coins going to that address.
15:36:27 <moneromooo> Again, from what you wrote. I dunno what bisq does.
15:37:13 <moneromooo> It's possible bisq would generate the public view key from the wrong secret view key and regen part of the address from that, but that'd be convoluted and thus unlikely.
15:39:50 <hanshan[m]> so it may not matter that i provided the incorrect view key? the main address is correct but the subaddress they came up with is clearly not owned by the wallet.
15:40:01 <hanshan[m]> * the incorrect private view key?
15:41:55 <moneromooo> Oh, subaddresses. Yeah, I skipped over that part. It does matter then.
15:51:10 <kayabanerve[m]> Morning. I already performed the scalar reduction with Python and it didn't work :/ I'm unsure why. My suggestion at this point was to try to extract the view key from Bisq.
15:52:23 <hanshan[m]> sent you a message.
15:52:23 <hanshan[m]> The view key checks out with the input we used :(
16:10:55 <selsta> should we also include the output selection PR in the next release UkoeHB?
16:11:36 <UkoeHB> 8794? seems like a good idea, not critical
17:14:42 <selsta> ok, we will do a release anyway to the tx_extra sizesize limit so we can include it
20:26:29 <rbrunner> selsta: jeffro256[m] re-formulated their stance regarding making a PR for #8076 towards the release branch as well: https://github.com/monero-project/monero/pull/8076#issuecomment-1478757395
20:26:53 <rbrunner> What would you say to this from a project management point of view?
21:47:37 <jeffro256[m]> I would  like to see 8076 in the new release since the speed up is so great
23:27:04 <selsta> jeffro256[m]: it's such a large change that i don't want to include it in the v0.18.2.0.1 last second, but i'm ok with including it in the next one
23:27:32 <selsta> v0.18.2.1
23:28:22 <jeffro256[m]> Fair enough