-
noocsharp
i'm getting frequent memory allocation failure related crashes on openbsd in monerod. any clue why this could be happening?
-
hyc
do you have any swap space?
-
noocsharp
yes, 16G ram and 16G swap
-
noocsharp
although i suppose it could be hitting the data area limit which is much lower
-
noocsharp
ulimit that is
-
hyc
certainly a possibility
-
hyc
not a good idea to enforce a vmem ulimit on monerod
-
noocsharp
not sure why i didn't think of that before especially after having to increase the ulimit on the build lol
-
noocsharp
will monerod eat all my ram if given the chance?
-
hyc
yes. but it will also give it back immediately if the OS needs it for something else.
-
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
-
noocsharp
also thanks, i bumped the data size limit and it seems to be working much more quickly and without crashing
-
moneromooo
It should really not crash due to alloc failure in the first place. Can you share the crash stack trace from gdb ?
-
hanshan[m]
-
hanshan[m]
Oh, I am aware of the ability to generate keys at
-
hanshan[m]
-
hanshan[m]
however, using that site, the generated main address and mistaken "Priv view key" combination is not accepted by --generate-from-keys
-
moneromooo
I thought monero-wallet-cli was performing reduction on what you give it, but if not:
-
moneromooo
-
moneromooo
Adapt paths to libs ofc.
-
moneromooo
And just run it, input key when asked.
-
hanshan[m]
Thank you.
-
hanshan[m]
So to be clear I should be able to use the output as my private view key?
-
hanshan[m]
Do i need to generate the corresponding main address? and then generate the wallet from that (plus original priv spend key)?
-
moneromooo
Yes, assuming bisq did just a reduce32 on what you gave it and you give this program the same thing.
-
moneromooo
If you restore with simplewallet, you'll get the address from it.
-
moneromooo
Do this on both spend and view key if you gave public for both.
-
moneromooo
If you gave just one, it's the spend key.
-
moneromooo
Oh you said view. Then just view key
-
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...
-
moneromooo
If bisq sends to the address you gave, you should see your coins, regardless of the view key you gave.
-
moneromooo
bisq would just not see coins going to that address.
-
moneromooo
Again, from what you wrote. I dunno what bisq does.
-
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.
-
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.
-
hanshan[m]
* the incorrect private view key?
-
moneromooo
Oh, subaddresses. Yeah, I skipped over that part. It does matter then.
-
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.
-
hanshan[m]
sent you a message.
-
hanshan[m]
The view key checks out with the input we used :(
-
selsta
should we also include the output selection PR in the next release UkoeHB?
-
UkoeHB
8794? seems like a good idea, not critical
-
selsta
ok, we will do a release anyway to the tx_extra sizesize limit so we can include it
-
rbrunner
selsta: jeffro256[m] re-formulated their stance regarding making a PR for #8076 towards the release branch as well:
monero-project/monero #8076#issuecomment-1478757395
-
rbrunner
What would you say to this from a project management point of view?
-
jeffro256[m]
I would like to see 8076 in the new release since the speed up is so great
-
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
-
selsta
v0.18.2.1
-
jeffro256[m]
Fair enough