Hi, monero-cli not starting to sync. The last message: The daemon will start synchronizing with the network. This may take a long time to complete.

What can i try?

* working on stagenet. the starting command ./monerod --stagenet

const offlineWallet = await createWalletFull({... (full message at libera.ems.host/_matrix/media/r0/do…3e6216ab01246a6e7fa47540fa06aab6a56)

Why signing an unsignedHex offline will throw an error about `imported outputs omit more outputs that we know of`?

i think u need daemon to sign tx

I use a view-only wallet and an offline wallet

That probably means you exported outputs without importing them. By default, this is incremental. To fix it when it's gone out of sync, export everything once.

moneromooo: How would my offline wallet know that my view-only wallet has not imported all of them?

The view wallet does not import them.

moneromooo: So this is what my code should look like?

const offlineWallet = await createWalletFull({... (full message at libera.ems.host/_matrix/media/r0/do…2ddbddc6b36459066d80e73da6593a73efa)

Dunno. I don't know what the rest does, but one thing comes to mind: if this is a new wallet, it's not going to know about any outputs yet, so the outputsHex is going to need to be the full set.

I just finished synchronizing the Daemons on a new windows install of GUI but the Advanced feature for mining is not visible in the tab.

What can I do?

Non-dev questions -> #monero, please

Thank you

<willshu[m]> "So this is what my code should..." <- github.com/monero-project/monero/bl…unctional_tests/cold_signing.py#L98

not sure if this is the place, but ive noticed a bug where the wallet sometimes starts syncing from the start of the chain instead of the given restore height

Repro with log level 2, check logs to see what it's doing.

<moneromooo> "Repro with log level 2, check..." <- im on GUI and set it to 2. dont see logs

i set a restore date of 20210909 and it starts syncing at 2.6 million blocks

No file ending in .log where monreo-wallet-gui is ?

are you sure 20210909 was a date and not a block height?

sech1: sept 9 2021

It's 10x the current block height, so can't be a height

yes, so maybe this is why wallet decides to sync everything

Unless the code somehow mistakes it for one, figures out it's in the future, then starts from 0

merope: that looks like whats happening. im not including dashes

2021-09-09

just restored using the dashes and getting the same thing

redirect to monero-gui

ooo123ooo1234567: its happening on monerujo/shruum too

is it reproducible with cli ?

ill try

<moneromooo> "No file ending in .log where..." <- privatebin.net/?3431af1caf949725#Gf…cLzJdMuL17wWGmHudpqgQLeNfq6NN5Q84q5

is this not a gui / user input issue? where when using a date it needs dashes , and even still, the gui will choose an actual block height of a few weeks prior anyway

plowsof[m]: i used dashes and it still syncs from start of chain

<ooo123ooo1234567> "is it reproducible with cli ?" <- is there an option to restore from date? i also see height arg

s/also/only/

`monero-wallet-cli --help | grep restore`

It looks like you're using some daemon from the internet. Is it yours ?

moneromooo: no its a remote node

ive tried others and got same result

dont judge me plowsof ;)

You'd need to add logs in get_blckchain_complement (IIRC) to see where the connmction point lands.

Maybe the issue's in the wallet, maybe in the daemon.

Or, actually, as a first thing, dump the short chain the wallet sends to the daemon, check whether most early hashes are on the chain.

(parameter to fast_refresh, which is what's logging the "skpped" lines in your log)

It could plausibly be a bug with the hashchain code, which ends up sending bad data.

Or maybe if it's anew wallet it'll always get all hashes anyway. I forget.

It certanly needs the last N for non trivial N.

CLI also syncing from 2650577

moneromooo: you lost me here

your screenshot shows that you tried to sync a view wallet without a daemon address -> crash, then you open a view wallet without a restore height defaulting to 0

<r4v3r23[m]> "not sure if this is the place..." <- `the start of the chain` is it genesis or the last block ?

plowsof[m]: i generated the wallet with that restore date

then opened it

im not very familiar with cli im just trying to reproduce

I mean, (1) check the data the wallet sends is OK, and (2) it looks like those blocks go through the "just get hashes, don't scan" path AFAICT.

That path should be reaaaally fast. Is it not ?

Maybe it's because your daemon's not local...

if you listened to ooo123 you would have seen that `--restore-height arg (=0) Restore from specific blockchain height`

moneromooo: Ooo will cover for you :D

nvm you used date , good job

plowsof[m]: if you read above youd see we are talking about restoring from a specific date

plowsof[m]: same result tho

moneromooo: Are you sure this isnt whats going on?

ofrnxmr[m]1: not sure how to check :)

can you walk me through it?

just to be sure, expected behaviour is it should show : XXX/restore_date_block_height tight?

s/restore_date_block_height/restore\_date\_block\_height/, s/tight/right/

paste.debian.net/hidden/30290274, no problems with -cli

ooo123ooo1234567: you are also syncing the entire chain here

line 14 vs line 24 is the issue?

should it start syncing from block 2444801?

big 10_000 steps are related to fetching of block headers, it isn't full synchronization

<r4v3r23[m]> "image.png" <- ooo123ooo1234567: so nothing is wrong here?

in your cases you didn't specify correct daemon during generation and therefore restore height is zero

* correct daemon address during generation

--restore-date makes sense only during creation

youre pastebin still shows 2.6 mil blocks. is what im describing not an issue?

`Height 2458879 / 2642253` it's just current / final heights to track sync progress

ooo123ooo1234567: `Height 19997 / 2650587`

before restore height it should do 10_000 steps, after it will be slower

ooo123ooo1234567: ok

why did you post view key for real wallet ?

paste.debian.net/hidden/9fb4f56b, synced

ooo123ooo1234567: its a public project donation wallet

which one ?

* nvm, found the answer

ofrnxmr[m]1: sure that what is going on ?

<moneromooo> "You'd need to add logs in..." <- is it colemak ?

<moneromooo> "ofrnxmr: sure that what is going..." <- Apologies. I meant to quote you and tag r4v3r

<moneromooo> "You'd need to add logs in..." <- how do i do this?

it's patch for code in human friendly way, not need though since there is nothing to debug in your case

s/though/now/

* it's patch for code in human friendly way, but there is nothing to debug in your case now

Something like, for (const auto &h: short_chain) MGINFO("short_chain: " << h); or similar.

i dont know how to do that. ooo says there is no issue

As in, it's fast and just grabs the hashes as above ? If you're happy with that, fine. It should be very quick, at least if you use a local daemon :)

This part was quite fast even with remote node

In theory, one could ask for hashes only from the last checkpoint, but I dont' think it does that atm.

* This part (before restore height) was quite

You said... lemme check the backlog... "the wallet sometimes starts syncing from the start". Why "sometimes" if there is no problem ?

Assuming it's alway new wallets (or wallets with the cache removed, etc).

moneromooo: i only brought it up because restoring via restore height used to always start at that block height

even new wallets some times starts from start of chain

Several people have reported that even with a designated restore height wallet scanning starts from the beginning and is very fast scanning up until the restore height.

It has been recently discussed

so it means it doesn't actually scan transactions before restore height, it just checks all blocks quickly

This behavior has existed for years

ok so a non issue :)

just not sure why some wallets do it and others dont

which don't ?

i was trying multiple wallet creation/restores to try and pin point the issue

some wallets start at the right block heigh, others sync from the start

any open source wallet that is different ?

i noticed this on shruum/monerujo initially

How do you know they do ? Could it be they just pause while getting hashes without telling you thy're doing it ?

My experience is only with the CLI

newly created wallet will try to set restoreheight, but that's only possible if talking to a monerod at the time

<arnuschky[m]> "Yes, unfortunately. The auditors..." <- inference.ag/blog/2022-06-21-anoma, probably were busy

<hyc> "newly created wallet will try to..." <- We could time estimate block height from genesis with a one year grace period

Better than multiple years

we already estimate the restore height from date when there is no daemon connection

My only concern would be the fact certain test configs appear as mainnet and we wouldn't know if it's real mainnet or a test

selsta: Oh, great :D

I'll go back to my corner and stop trying to help :p

hmm, date in report - 20220602, uploaded - 20220610, blog post - 2020621

s/2020621/2022621/

s/2020621/20220621/

Does `get_tx_key` only work for broadcasted transactions? How can we get the tx key for a transaction that hasn't yet been broadcasted?

when will we get rid of epee and easylogging++ ?

spirobel: is that a yes to it must have been broadcast to get the tx_key?

sgp_[m]: I dont know. I can dig a bit to figure it out. But without looking I would assume yes. When I wanted to do get_tx_proof with a tx_hash I had to wait for the monerowalletlistener. Context: during the work on the browser wallet built on monero-javascript

It does not have to. The wallet keeps the tx key. It doesn't know when (or if) the daemon broadcasts it (and even whether any broadcast was succesful).

But there is no fundamental need for it. If there is this limitation it should be just the api

Our devs are having some difficulty testing the process; it's not returning data for them correctly and our first thought is that it could be since not broadcast yet due to how it's saved in history. But we are looking into further

sgp_[m]: I also tried to get a tx_proof (which is based on the tx_key) directly after creating/sending the transaction. That lead to an error. So I waited for on_output_spent and then it worked fine.

<spirobel[m]> "when will we get rid of epee and..." <- `rm -fr /`

> <@spirobel:matrix.org> when will we get rid of epee and easylogging++ ?

* `rm -ifr /`

ooo123ooo1234567: which version of easylogging are we using btw? it is a vendored lib, right?

github.com/monero-project/monero/tree/master/external/easylogging++ `Easylogging++ v9.96.7` but we have patches on top of it

I doubt we will get rid of it.

I don't see why (beyond "let's use my prefered lib now, until someone else comes along and switches to their prefered lib").

<sgp_[m]> "Does `get_tx_key` only work..." <- What's the source of that tx ?

selsta: are the patches in the file already or are they somewhere else?

It's unmaintained, but works fine AFAICT.

it's all in the file, it's a simple header and source file, it really isn't some annoying dependency that makes everything complicated

Like the stupid "let's not use epee" spiel. Replacing *parts* of epee might be good, but "replace it all because I don't like it" is just dumb.

If you have a patch that *improves* things, and is common sense compatible, then it could go in.

selsta: its annoying because it depends on signals for example. I try to compile to wasm. wasm does not have signals

I didn't realize it did. I didn't realize windows even *had* signals... /me goes look

From what I can tell, it merely hooks to signal to detect a crash to moan about it. We do not use that.

I grepped signam and signal. Did you find anthing else ?

moneromooo: can we get rid of the dependency on <signals> if it is unused anyway? it would help a lot

would be great to be able to target wasm without emscripten

`#define ELPP_FEATURE_CRASH_LOG` remove it from ea_config.h

s/signals/csignals/

If it's just that, it's likely you can #ifdef/#ifndef it based on what the code does.

spirobel[m]: indeed, reading code is more annoying than reading comments from those who didn't read it

ie, USE_SIGNALS or so.

moneromooo: hm...I think it is not possible because it wont compile with the <csignals> in there ``` error(compilation): clang failed with stderr: In file included from /home/test/Projects/zig/monero-zig/external/monero/external/easylogging++/easylogging++.cc:18:

In file included from /home/test/Projects/zig/monero-zig/external/monero/external/easylogging++/easylogging++.h:373:

In file included from /snap/zig/5341/lib/libcxx/include/csignal:43:

/snap/zig/5341/lib/libc/include/wasm-wasi-musl/signal.h:2:2: error: "wasm lacks signal support; to enable minimal signal emulation, compile with -D_WASI_EMULATED_SIGNAL and link with -lwasi-emulated-signal" ```

Well, you've got to #ifdef out the signal stuff in it of course :)

Otherwise you could just remove the include.

But there is very little AFAICT.

moneromooo: true. Maybe we can just get rid of it. Not good to depend on signals there.

<spirobel[m]> "would be great to be able to..." <- not a priority

<sgp_[m]> "Our devs are having some..." <- are these experiments publicly available ?

ooo123ooo1234567: you are the CEO here I guess...

fine...I will just patch it for myself

"#define ELPP_FEATURE_CRASH_LOG remove it from ea_config.h" did you try this ?

you likely still need to remove the csignal include, but it's not much work

two lines changed

probably just that include would be enough

don't know if __GLIBC__ or __GNUC__ is defined when compiling to wasm

github.com/monero-project/monero/bl…ging%2B%2B/easylogging%2B%2B.h#L373, comment this line

github.com/monero-project/monero/bl…l/easylogging%2B%2B/ea_config.h#L15, and optionally this

<spirobel[m]> "fine...I will just patch it..." <- those who are patching for themselves usually know how t read code too

s/t/to/

ok I will give it a try.

wow

can confirm get_tx_key does not work

for --do-not-relay

hint: raw_monero_tx has tx_key inside, but wallet doesn't

is there a tool to get the tx_key from the raw tx?

Well, that is what the do_not_relay RPC does.

It's "gimme the result, pretend it didn't happen".

You should get the tx key in the response.

I understand. I'm just trying to find a convenient way to get the tx_key of a non-relayed transaction, that is all

without RPC

github.com/monero-project/monero/bl…let_rpc_server_commands_defs.h#L568, "transfer" rpc method returns tx_key

sgp_[m]: not yet

There is a non RPC one ?

Ah, right, a command line flag. OK, that is unfortunate then,,,

I suppose it should print it in the console then.

yes that would work :)

is there a convenient way to either 1) get the tx_key from the raw transaction, or 2) some RPC call to show the tx_key when given only the raw transaction

not yet

Something like paste.debian.net/hidden/e4b7d1fe though it would likely keep the tx key in memory.

The tx key is definitely not in the raw tx. That'd defeat the point.

If you get a pending_tx blob though, it should be in.

How could I get it from pending_tx?

raw_monero_tx is a prefix for file which contains pending tx

monero-project/monero #380, something like this would solve the problem for cli and rpc

That's what I wrote just above in the patch.

Didn't compile though :)

monero-project/monero #2487/files, no, closer to this one

probably get_tx_key should support both txid and hex blob of pending txs

so `get_tx_key (<txid> | <raw_monero_tx blob>)` ?

yes, but it isn't implemented

understood. that would indeed be nice :)

repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/318, hopefully these charts will compensate lack of actually working code

made this for reference monero-project/monero #8398

No, the *secret* tx key is not present in a tx.

oh

monero-project/monero #2586/files, this patch should allow store full pending tx separately

not just raw tx blob

s/should/could/, s/allow//, s/separately/too/

<moneromooo> "No, the *secret* tx key is not..." <- indeed

how would I go about turning of easylogging completely? for my usecase I dont really need it. (logging to stdout/err is enough/ also not really necessary) I tried to comment out the stuff as recommended, but this is much harder than expected. This logging library is feature packed .

s/of/off/

read code -> edit code

ooo123ooo1234567: I thought maybe the CEO can give me some inspiration

spirobel[m]: just finish this part and submit a patch to relevant repo, would be helpful others too

> <@spirobel:matrix.org> how would I go about turning off easylogging completely? for my usecase I dont really need it. (logging to stdout/err is enough/ also not really necessary) I tried to comment out the stuff as recommended, but this is much harder than expected. This logging library is feature packed .

* just finish this part and submit a patch to relevant repo, would be helpful for others with the same problem

seems like this file is the only one consuming the easylogging header: github.com/monero-project/monero/bl…/contrib/epee/include/misc_log_ex.h and then these macros are used everywhere to log, right? so maybe I can just overwrite this to be null or just log to stdout/err

EDit misc_log_ex.h and change the defines to ((void)0) or so.

In the cpp version, gut all the function bodies. Should be most of it.

Okay thanks for the tip! I will give it a try! I wonder why there are so many different ones ... some are more semantic like MCDEBUG and others are just related to color like MCLOG_CYAN ...

Convenience.

the more the better 🙂👍️ ... I also saw many files include from the el:: namespace ... so I guess I also have to keep a minimal version of easylogging around so the statements still work ...

ooo123ooo1234567:

Ring member age distribution in that transaction is quite strange (see my comment in the thread). I assume it couldn't have been constructed with `wallet2` unless there is a serious bug in `wallet2` for txs with a large number of inputs.