06:44:08 <NakedKing> 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.
06:44:14 <NakedKing> What can i try?
06:44:35 <NakedKing> * working on stagenet. the starting command ./monerod --stagenet
09:44:27 <willshu[m]>     const offlineWallet = await createWalletFull({... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/384b63e6216ab01246a6e7fa47540fa06aab6a56)
09:45:03 * willshu[m] uploaded an image: (54KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/tnFDGWhcbioTCcQQrklinHTY/Screen%20Shot%202022-06-21%20at%2017.44.52.png >
09:45:31 <willshu[m]> Why signing an unsignedHex offline will throw an error about `imported outputs omit more outputs that we know of`?
09:46:37 <osho_xmr[m]> i think u need daemon to sign tx
09:47:37 <willshu[m]> https://github.com/monero-ecosystem/monero-javascript/blob/master/docs/developer_guide/view_only_offline.md
09:47:55 <willshu[m]> I use a view-only wallet and an offline wallet
09:51:13 <moneromooo> 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.
09:52:35 <willshu[m]> moneromooo: How would my offline wallet know that my view-only wallet has not imported all of them?
09:52:57 <moneromooo> The view wallet does not import them.
09:55:14 <willshu[m]> moneromooo: So this is what my code should look like?
09:55:16 <willshu[m]>     const offlineWallet = await createWalletFull({... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/efcbf2ddbddc6b36459066d80e73da6593a73efa)
09:57:31 <moneromooo> 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.
11:44:02 <stradi> 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.
11:44:12 <stradi> What can I do?
11:45:43 <sech1> Non-dev questions -> #monero, please
11:46:16 <stradi> Thank you
12:17:50 <ooo123ooo1234567> <willshu[m]> "So this is what my code should..." <- https://github.com/monero-project/monero/blob/master/tests/functional_tests/cold_signing.py#L98
12:40:47 <r4v3r23[m]> 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
12:41:39 <moneromooo> Repro with log level 2, check logs to see what it's doing.
12:49:43 <r4v3r23[m]> <moneromooo> "Repro with log level 2, check..." <- im on GUI and set it to 2. dont see logs
12:51:00 * r4v3r23[m] uploaded an image: (96KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/byjLdxgSFsFTuHewQELrdhkT/image.png >
12:51:08 <r4v3r23[m]> i set a restore date of 20210909 and it starts syncing at 2.6 million blocks
12:51:09 <moneromooo> No file ending in .log where monreo-wallet-gui is ?
12:51:54 <sech1> are you sure 20210909 was a date and not a block height?
12:52:29 <r4v3r23[m]> sech1: sept 9 2021
12:53:06 <merope> It's 10x the current block height, so can't be a height
12:53:25 <sech1> yes, so maybe this is why wallet decides to sync everything
12:53:31 <merope> Unless the code somehow mistakes it for one, figures out it's in the future, then starts from 0
12:53:48 <r4v3r23[m]> merope: that looks like whats happening. im not including dashes
12:53:51 <r4v3r23[m]> 2021-09-09
12:56:29 <r4v3r23[m]> just restored using the dashes and getting the same thing
12:56:46 * r4v3r23[m] uploaded an image: (143KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/DriHWfWiMtQTeukQQxDJgYoG/image.png >
12:57:50 <ooo123ooo1234567> redirect to monero-gui
12:58:42 <r4v3r23[m]> ooo123ooo1234567: its happening on monerujo/shruum too
12:58:49 <ooo123ooo1234567> is it reproducible with cli ?
12:58:56 <r4v3r23[m]> ill try
13:06:59 <r4v3r23[m]> <moneromooo> "No file ending in .log where..." <- https://privatebin.net/?3431af1caf949725#GfrGZ3AX1cLzJdMuL17wWGmHudpqgQLeNfq6NN5Q84q5
13:10:08 <plowsof[m]> 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
13:11:09 <r4v3r23[m]> plowsof[m]: i used dashes and it still syncs from start of chain
13:11:24 <r4v3r23[m]> <ooo123ooo1234567> "is it reproducible with cli ?" <- is there an option to restore from date? i also see height arg
13:11:39 <r4v3r23[m]> s/also/only/
13:12:04 <ooo123ooo1234567> `monero-wallet-cli --help | grep restore`
13:12:19 <moneromooo> It looks like you're using some daemon from the internet. Is it yours ?
13:12:34 <r4v3r23[m]> moneromooo: no its a remote node
13:12:43 <r4v3r23[m]> ive tried others and got same result
13:12:53 <r4v3r23[m]> dont judge me plowsof ;)
13:14:20 <moneromooo> You'd need to add logs in get_blckchain_complement (IIRC) to see where the connmction point lands.
13:14:34 <moneromooo> Maybe the issue's in the wallet, maybe in the daemon.
13:15:16 <moneromooo> 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.
13:15:51 <moneromooo> (parameter to fast_refresh, which is what's logging the "skpped" lines in your log)
13:16:25 <moneromooo> It could plausibly be a bug with the hashchain code, which ends up sending bad data.
13:17:27 * r4v3r23[m] uploaded an image: (155KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/GnkLVYQPYANDeXRUZBAHWsOt/image.png >
13:17:51 <moneromooo> Or maybe if it's anew wallet it'll always get all hashes anyway. I forget.
13:18:07 <moneromooo> It certanly needs the last N for non trivial N.
13:18:59 <r4v3r23[m]> CLI also syncing from 2650577
13:20:02 <r4v3r23[m]> moneromooo: you lost me here
13:20:15 <plowsof[m]> 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
13:20:18 <ooo123ooo1234567> <r4v3r23[m]> "not sure if this is the place..." <- `the start of the chain` is it genesis or the last block ?
13:20:34 <r4v3r23[m]> plowsof[m]: i generated the wallet with that restore date
13:20:39 <r4v3r23[m]> then opened it
13:20:58 <r4v3r23[m]> im not very familiar with cli im just trying to reproduce
13:22:30 * r4v3r23[m] uploaded an image: (88KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/ldSMLwSruAAcEZQSXGdqWdvY/image.png >
13:22:53 <moneromooo> 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.
13:23:11 <moneromooo> That path should be reaaaally fast. Is it not ?
13:23:27 <moneromooo> Maybe it's because your daemon's not local...
13:23:55 * moneromooo afk for a bit
13:23:57 <plowsof[m]> if you listened to ooo123 you would have seen that `--restore-height arg (=0)             Restore from specific blockchain height`
13:24:17 <ofrnxmr[m]1> moneromooo: Ooo will cover for you :D
13:24:27 <plowsof[m]> nvm you used date , good job
13:24:29 <r4v3r23[m]> plowsof[m]: if you read above youd see we are talking about restoring from a specific date
13:24:52 <r4v3r23[m]> plowsof[m]: same result tho
13:25:12 <ofrnxmr[m]1> moneromooo: Are you sure this isnt whats going on? 
13:26:14 <r4v3r23[m]> ofrnxmr[m]1: not sure how to check :) 
13:26:15 <r4v3r23[m]> can you walk me through it?
13:26:59 <r4v3r23[m]> just to be sure, expected behaviour is it should show : XXX/restore_date_block_height tight?
13:27:04 <r4v3r23[m]> s/restore_date_block_height/restore\_date\_block\_height/, s/tight/right/
13:29:09 <ooo123ooo1234567> https://paste.debian.net/hidden/30290274/, no problems with -cli 
13:30:51 <r4v3r23[m]> ooo123ooo1234567: you are also syncing the entire chain here
13:31:35 <plowsof[m]> line 14 vs line 24 is the issue?
13:32:50 <r4v3r23[m]> should it start syncing from block 2444801?
13:32:56 <ooo123ooo1234567> big 10_000 steps are related to fetching of block headers, it isn't full synchronization
13:34:15 <r4v3r23[m]> <r4v3r23[m]> "image.png" <- ooo123ooo1234567: so nothing is wrong here?
13:35:42 <ooo123ooo1234567> in your cases you didn't specify correct daemon during generation and therefore restore height is zero
13:36:16 <ooo123ooo1234567> * correct daemon address during generation
13:37:13 <ooo123ooo1234567> --restore-date makes sense only during creation
13:43:25 <r4v3r23[m]> youre pastebin still shows 2.6 mil blocks. is what im describing not an issue?
13:48:16 <ooo123ooo1234567> `Height 2458879 / 2642253` it's just current / final heights to track sync progress
13:49:47 <r4v3r23[m]> ooo123ooo1234567: `Height 19997 / 2650587`
13:49:49 <ooo123ooo1234567> before restore height it should do  10_000 steps, after it will be slower
13:50:01 <r4v3r23[m]> ooo123ooo1234567: ok
13:50:32 <ooo123ooo1234567> why did you post view key for real wallet ?
13:53:44 <ooo123ooo1234567> https://paste.debian.net/hidden/9fb4f56b/, synced
13:54:04 <r4v3r23[m]> ooo123ooo1234567: its a public project donation wallet
13:54:04 <ooo123ooo1234567> which one ?
13:56:05 <ooo123ooo1234567>  * nvm, found the answer
13:57:01 <moneromooo> ofrnxmr[m]1: sure that what is going on ?
14:20:24 <ooo123ooo1234567> <moneromooo> "You'd need to add logs in..." <- is it colemak ?
14:27:14 <ofrnxmr[m]1> <moneromooo> "ofrnxmr: sure that what is going..." <- Apologies. I meant to quote you and tag r4v3r
15:53:35 <r4v3r23[m]> <moneromooo> "You'd need to add logs in..." <- how do i do this?
15:54:24 <ooo123ooo1234567> it's patch for code in human friendly way, not need though since there is nothing to debug in your case
15:54:31 <ooo123ooo1234567> s/though/now/
15:54:45 <ooo123ooo1234567>  * it's patch for code in human friendly way, but there is nothing to debug in your case now
15:56:47 <moneromooo> Something like, for (const auto &h: short_chain) MGINFO("short_chain: " << h); or similar.
16:01:39 <r4v3r23[m]> i dont know how to do that. ooo says there is no issue
16:04:25 <moneromooo> 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 :)
16:05:12 <ooo123ooo1234567> This part was quite fast even with remote node
16:05:20 <moneromooo> In theory, one could ask for hashes only from the last checkpoint, but I dont' think it does that atm.
16:05:31 <ooo123ooo1234567> * This part (before restore height) was quite
16:06:18 <moneromooo> You said... lemme check the backlog... "the wallet sometimes starts syncing from the start". Why "sometimes" if there is no problem ?
16:06:53 <moneromooo> Assuming it's alway new wallets (or wallets with the cache removed, etc).
16:09:30 <r4v3r23[m]> moneromooo: i only brought it up because restoring via restore height used to always start at that block height
16:09:44 <r4v3r23[m]> even new wallets some times starts from start of chain
16:18:28 <nioc> 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. 
16:18:46 <nioc> It has been recently discussed 
16:19:47 <sech1> so it means it doesn't actually scan transactions before restore height, it just checks all blocks quickly
16:21:27 <nioc> This behavior has existed for years
16:21:53 <r4v3r23[m]> ok so a non issue :)
16:22:01 <r4v3r23[m]> just not sure why some wallets do it and others dont
16:22:12 <ooo123ooo1234567> which don't ?
16:22:40 <r4v3r23[m]> i was trying multiple wallet creation/restores to try and pin point the issue
16:23:04 <r4v3r23[m]> some wallets start at the right block heigh, others sync from the start
16:23:20 <ooo123ooo1234567> any open source wallet that is different ?
16:23:40 <r4v3r23[m]> i noticed this on shruum/monerujo initially
16:26:42 <moneromooo> How do you know they do ? Could it be they just pause while getting hashes without telling you thy're doing it ?
16:27:42 <nioc> My experience is only with the CLI 
16:31:52 <hyc> newly created wallet will try to set restoreheight, but that's only possible if talking to a monerod at the time
17:05:53 <ooo123ooo1234567> <arnuschky[m]> "Yes, unfortunately. The auditors..." <- https://inference.ag/blog/2022-06-21-anoma/, probably were busy
17:06:17 <kayabanerve[m]> <hyc> "newly created wallet will try to..." <- We could time estimate block height from genesis with a one year grace period
17:06:32 <kayabanerve[m]> Better than multiple years
17:07:16 <selsta> we already estimate the restore height from date when there is no daemon connection
17:07:27 <kayabanerve[m]> 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
17:07:40 <kayabanerve[m]> selsta: Oh, great :D
17:08:06 <kayabanerve[m]> I'll go back to my corner and stop trying to help :p
17:09:01 <ooo123ooo1234567> hmm, date in report - 20220602, uploaded - 20220610, blog post - 2020621
17:11:45 <ooo123ooo1234567> s/2020621/2022621/
17:11:47 <ooo123ooo1234567> s/2020621/20220621/
17:14:36 <sgp_[m]> 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?
17:17:37 <spirobel[m]> when will we get rid of epee and easylogging++ ?
17:18:01 <sgp_[m]> spirobel: is that a yes to it must have been broadcast to get the tx_key?
17:20:01 <spirobel[m]> 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
17:20:33 <moneromooo> 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).
17:20:53 <spirobel[m]> But there is no fundamental need for it. If there is this limitation it should be just the api
17:22:45 <sgp_[m]> 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
17:26:59 <spirobel[m]> 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.
17:28:14 <ooo123ooo1234567> <spirobel[m]> "when will we get rid of epee and..." <- `rm -fr /`
17:28:55 <ooo123ooo1234567> > <@spirobel:matrix.org> when will we get rid of epee and easylogging++ ?
17:28:55 <ooo123ooo1234567>  * `rm -ifr /`
17:32:46 <spirobel[m]> ooo123ooo1234567: which version of easylogging are we using btw? it is a vendored lib, right?
17:34:41 <selsta> https://github.com/monero-project/monero/tree/master/external/easylogging++ `Easylogging++ v9.96.7` but we have patches on top of it
17:35:05 <selsta> I doubt we will get rid of it.
17:35:41 <moneromooo> I don't see why (beyond "let's use my prefered lib now, until someone else comes along and switches to their prefered lib").
17:35:44 <ooo123ooo1234567> <sgp_[m]> "Does `get_tx_key` only work..." <- What's the source of that tx ?
17:35:47 <spirobel[m]> selsta: are the patches in the file already or are they somewhere else?
17:35:54 <moneromooo> It's unmaintained, but works fine AFAICT.
17:36:30 <selsta> 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
17:36:58 <moneromooo> 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.
17:37:31 <moneromooo> If you have a patch that *improves* things, and is common sense compatible, then it could go in.
17:37:32 <spirobel[m]> selsta: its annoying because it depends on signals for example. I try to compile to wasm. wasm does not have signals
17:38:09 <moneromooo> I didn't realize it did. I didn't realize windows even *had* signals... /me goes look
17:39:25 <moneromooo> From what I can tell, it merely hooks to signal to detect a crash to moan about it. We do not use that.
17:39:43 <moneromooo> I grepped signam and signal. Did you find anthing else ?
17:40:29 <spirobel[m]> moneromooo: can we get rid of the dependency on <signals> if it is unused anyway? it would help a lot
17:40:36 <spirobel[m]> would be great to be able to target wasm without emscripten
17:40:52 <ooo123ooo1234567> `#define ELPP_FEATURE_CRASH_LOG` remove it from ea_config.h
17:41:03 <spirobel[m]> s/signals/csignals/
17:41:33 <moneromooo> If it's just that, it's likely you can #ifdef/#ifndef it based on what the code does.
17:41:51 <ooo123ooo1234567> spirobel[m]: indeed, reading code is more annoying than reading comments from those who didn't read it
17:42:16 <moneromooo> ie, USE_SIGNALS or so.
17:42:26 <spirobel[m]> 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:
17:42:26 <spirobel[m]> In file included from /home/test/Projects/zig/monero-zig/external/monero/external/easylogging++/easylogging++.h:373:
17:42:26 <spirobel[m]> In file included from /snap/zig/5341/lib/libcxx/include/csignal:43:
17:42:27 <spirobel[m]> /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" ```
17:43:03 <moneromooo> Well, you've got to #ifdef out the signal stuff in it of course :)
17:43:12 <moneromooo> Otherwise you could just remove the include.
17:43:49 <moneromooo> But there is very little AFAICT.
17:45:01 <spirobel[m]> moneromooo: true. Maybe we can just get rid of it. Not good to depend on signals there. 
17:45:55 <ooo123ooo1234567> <spirobel[m]> "would be great to be able to..." <- not a priority
17:47:14 <ooo123ooo1234567> <sgp_[m]> "Our devs are having some..." <- are these experiments publicly available ?
17:47:25 <spirobel[m]> ooo123ooo1234567: you are the CEO here I guess... 
17:47:28 <spirobel[m]> fine...I will just patch it for myself
17:47:52 <ooo123ooo1234567> "#define ELPP_FEATURE_CRASH_LOG remove it from ea_config.h" did you try this ?
17:48:16 <selsta> you likely still need to remove the csignal include, but it's not much work
17:48:28 <selsta> two lines changed
17:49:16 <ooo123ooo1234567> probably just that include would be enough
17:50:26 <selsta> don't know if __GLIBC__ or __GNUC__ is defined when compiling to wasm
17:50:41 <ooo123ooo1234567> https://github.com/monero-project/monero/blob/master/external/easylogging%2B%2B/easylogging%2B%2B.h#L373, comment this line
17:51:29 <ooo123ooo1234567> https://github.com/monero-project/monero/blob/master/external/easylogging%2B%2B/ea_config.h#L15, and optionally this
17:53:53 <ooo123ooo1234567> <spirobel[m]> "fine...I will just patch it..." <- those who are patching for themselves usually know how t read code too
17:53:55 <ooo123ooo1234567> s/t/to/
17:54:11 <spirobel[m]> ok I will give it a try.  
17:54:17 <ooo123ooo1234567> wow 
17:54:56 * sgp_[m] uploaded an image: (37KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.optoutpod.com/NldpmdvxfoiDMuYpCjIkYQzi/image.png >
17:55:04 <sgp_[m]> can confirm get_tx_key does not work
17:55:15 <sgp_[m]> for --do-not-relay
17:56:40 <ooo123ooo1234567> hint: raw_monero_tx has tx_key inside, but wallet doesn't
17:57:33 <sgp_[m]> is there a tool to get the tx_key from the raw tx?
17:58:12 <moneromooo> Well, that is what the do_not_relay RPC does.
17:58:24 <moneromooo> It's "gimme the result, pretend it didn't happen".
17:58:38 <moneromooo> You should get the tx key in the response.
17:58:43 <sgp_[m]> I understand. I'm just trying to find a convenient way to get the tx_key of a non-relayed transaction, that is all
17:58:58 <sgp_[m]> without RPC
17:59:02 <ooo123ooo1234567> https://github.com/monero-project/monero/blob/master/src/wallet/wallet_rpc_server_commands_defs.h#L568, "transfer" rpc method returns tx_key 
17:59:11 <ooo123ooo1234567> sgp_[m]: not yet
17:59:15 <moneromooo> There is a non RPC one ? 
17:59:56 <moneromooo> Ah, right, a command line flag. OK, that is unfortunate then,,,
18:00:48 <moneromooo> I suppose it should print it in the console then.
18:01:58 <sgp_[m]> yes that would work :)
18:01:58 <sgp_[m]> 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
18:04:24 <ooo123ooo1234567> not yet
18:04:34 <moneromooo> Something like https://paste.debian.net/hidden/e4b7d1fe/ though it would likely keep the tx key in memory.
18:04:55 <moneromooo> The tx key is definitely not in the raw tx. That'd defeat the point.
18:05:25 <moneromooo> If you get a pending_tx blob though, it should be in.
18:06:40 <sgp_[m]> How could I get it from pending_tx?
18:06:50 <ooo123ooo1234567> raw_monero_tx is a prefix for file which contains pending tx
18:07:05 <ooo123ooo1234567> https://github.com/monero-project/monero/pull/380, something like this would solve the problem for cli and rpc
18:08:48 <moneromooo> That's what I wrote just above in the patch.
18:08:55 <moneromooo> Didn't compile though :)
18:09:42 <ooo123ooo1234567> https://github.com/monero-project/monero/pull/2487/files, no, closer to this one
18:10:09 <ooo123ooo1234567> probably get_tx_key should support both txid and hex blob of pending txs
18:13:49 <sgp_[m]> so `get_tx_key (<txid> | <raw_monero_tx blob>)` ?
18:13:57 <ooo123ooo1234567> yes, but it isn't implemented
18:14:14 <sgp_[m]> understood. that would indeed be nice :)
18:19:15 <ooo123ooo1234567> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/318, hopefully these charts will compensate lack of actually working code
18:22:13 <sgp_[m]> made this for reference https://github.com/monero-project/monero/issues/8398
18:27:41 <moneromooo> No, the *secret* tx key is not present in a tx.
18:29:18 <sgp_[m]> oh
18:47:59 <ooo123ooo1234567> https://github.com/monero-project/monero/pull/2586/files, this patch should allow store full pending tx separately
18:48:16 <ooo123ooo1234567> not just raw tx  blob
18:49:13 <ooo123ooo1234567> s/should/could/, s/allow//, s/separately/too/
18:49:59 <ooo123ooo1234567> <moneromooo> "No, the *secret* tx key is not..." <- indeed
19:13:26 <spirobel[m]> 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 .
19:13:46 <spirobel[m]> s/of/off/
19:14:23 <ooo123ooo1234567> read code -> edit code
19:14:46 <spirobel[m]> ooo123ooo1234567: I thought maybe the CEO can give me some inspiration
19:16:45 <ooo123ooo1234567> spirobel[m]: just finish this part and submit a patch to relevant repo, would be helpful others too
19:17:03 <ooo123ooo1234567> > <@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 .
19:17:03 <ooo123ooo1234567>  * just finish this part and submit a patch to relevant repo, would be helpful for others with the same problem
19:20:13 <spirobel[m]> seems like this file is the only one consuming the easylogging header: https://github.com/monero-project/monero/blob/master/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 
19:20:31 <moneromooo> EDit misc_log_ex.h and change the defines to ((void)0) or so.
19:20:50 <moneromooo> In the cpp version, gut all the function bodies. Should be most of it.
19:27:31 <spirobel[m]> 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 ... 
19:29:14 <moneromooo> Convenience.
19:31:18 <spirobel[m]> 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 ...
23:11:12 <ofrnxmr[m]1> ooo123ooo1234567: 
23:11:12 <ofrnxmr[m]1> https://www.reddit.com/r/Monero/comments/vhpc7p/something_weird_happening_on_the_blockchain/
23:22:26 <Rucknium[m]> 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.