“I thought, ‘I’m going to pump it and dump it,’ because I was interested and taking the ideas and implementing them in bitcoin. The bitcoin code base was far more interesting to me than monero, and I thought, ‘I’m not going to work on this codebase, it’s terrible,'” he recalls - fluffypony in an interview about Monero

selsta, I have updated the documentation in 7387 and ran the Mac test. Unless you have nothing to add after your own Mac test, we're done on this one.

BBL. Lovely SCRUM meetings ahead.

froglet_xmr: try your question again

ack, luigi. hi folks, I am attempting to receive XMR on stagenet (connected to a remote node), the TX briefly shows up in monero wallet gui but then disappears. I can see from a blockchain explorer that the TX has been confirmed several times, but still no luck in seeing it in the GUI. any advice?

is your gui set to stagenet?

yes

I see stagenet in red text in the top left corner

ok

which stagenet node are you using?

I have tried both monero-stagenet.exan.tech and the xmr.to node (full address escapes me at the moment..)

stagenet.community.xmr.to

currently i am on exan.tech node, synchronized (792543)

port 38081

would try the xmr.to one

I get the same result

is your balance correct?

well, my balance is 0 XMR which would be correct if I have never received any XMR on stagenet (wallet was only created today)

however it would be incorrect if the faucet transactions have in fact been sent to me

briefly shows up then disappears seems weird

eg. community.xmr.to/explorer/stagenet/…6ad3156a2d0c5049bebe036387c9b70dc6f should have been sent to my wallet on stagenet

everything I see about the tx seems to suggest that it has been confirmed, several times, but my wallet still shows 0 XMR

can you try CLI wallet?

i'm not familiar with using the CLI but yes I can try..

CLI wallet I should say

did you change account inside GUI?

changed wallets, yes

created a new one on stagenet, i have a working wallet on mainnet

ok but you did not change anything on the "Accounts" tab

correct

i created a new receive address though, to verify it wasn't something wrong with my main address

using the wallet-cli (assuming I have done so correctly) still shows a balance of 0 XMR

however I do get a message saying "The wallet's refresh-from-block-height setting is higher than the daemon's height: this may mean your wallet will skip over transactions"

I ran "wallet_info" from the CLI and now it says my wallet is out of sync

ok so the restore height is the problem

you can enter "set refresh-from-blockheight 792400"

and then enter rescan_bc

i checked that, restore height is 2317388, is it possible there is some bug where creating a wallet from the gui would use the mainnet restore height perhaps..?

I get Error: set: unrecognized argument(s) from that command selsta

set refresh-from-block-height 792400

does that work?

yes it did

could be a GUI bug during stagenet wallet creation, though did not see it before

i am running a mainnet local node, maybe that has something to do with it

alright that worked! thanks so much for that, i was really scratching my head..

makes sense, so the laymans explanation is that my wallet thought it was from the future...

yep

it had the mainnet restore height

very strange that the TX would also appear in the GUI at 0/10 confirmations and then disappear after a while

I assume it saw it in the mempool but then skipped it

after it got in a block

I think everyone here knows that most Monero exchange withdrawals and desposits are traceable (Breaking Monero - poisoned outputs). How does it feel to go out and lie to people that they are private and then earn less than holding BTC on your bag?

Did you know one of the developers is working on integrating Triptych?!

Triptych is a zero-knowledge proving system for confidential transactions created by the Monero Research Lab!

Please don't spam.

Please 🙏

.merges

It's a good review, after which I facepalm after realizing that I'd unintentionally introduce a security breach.

(core_tests)

just in case people are unaware, github has a setting under which " Users that have recently created their account will be unable to interact with the repository," which also automatically expires after a specified length of time.

fluffypony: opinion? ^

Unrelated: does MTRACE create a backtrace?

sounds like the trace log level

MTRACE logs at trace level. For a trace, use: tools::log_stack_trace();

Thank y'all.

All you are 'fighting' for is e-penis of a guy you never met, that doesn't even have common decency to pay you for your time.

Do you think they care about Monero, or privacy or anything other than money?

selsta: I'd enable that, it would curb the spam and perhaps occasionally catch a false positive

yea, would set it to 1 week for now

I need stack trace in epee, but stack trace's common depends on epee. I have to decouple logging from epee.

I would like to help the guy with the log spam before I make these changes. What I could offer ad-hoc is compressing the rotated logs with XZ. If they contain spam, then the 100 MB log will reduce into 1-2 MB after compressing.

mj-xmr: it's seems to be a gui issue

yep

not showing up with start-low-graphics-mode.bat usually hints at a graphics drivers issue

not clear how graphics driver is related

But I feel somehow blind, not being able to trace the cause (or any other in epee without proper logging).

I think I will just do what I can do best and decouple logging from epee, similarly as epee_readline is decoupled.

Does compressing the rotated log sound like something you'd want to see regardless of the final solution?

Then: try { throw 0; } catch(...) {}

seeing that it only shows up at a single user and that graphics drivers seem to be related here I don't know if it's worth to spend much time on

usual solution is attempt to update drivers and check if issue reappears

You mean adding log compression to monero tools themselves ?

moneromooo, yes.

So there is already log rotation. Compressing the rotated logs seems like the natural next step.

does that work without extra library?

Boost has compression routines.

If you're happy with zip and gzip, you shouldn't need anything more.

I guess it can be useful when running log level 4

mj-xmr: mining test also passed on my mac

p2p functional tests fail somehow but seems unrelated

excellent!

selsta, if p2p was never being tested under Mac, one can expect such failures.

But it sure is something to add to the list.

it worked in the past

I can imagine this. But if it's mot in the CI, a regression can happen anytime.

But to remove my bias, I could run the full test on GitHub on Mac on Master.

Shall I?

didn’t you run functional tests yesterday?

or did you only run mining test

Only the mining test.

Because I have modified the functional_tests_rpc to just run the "mining" test, not "all"

Otherwise I'd spam the logs.