00:03:21 <ndorf> am i alone in the opinion that there should be some easy daemon command that includes the age of the top block in its output?
00:03:38 <ndorf> i'd suggest `diff`, since that one already includes the top block hash
00:10:48 <luigi1111w> status ?
00:13:00 <ndorf> it seems that it goes hand in hand with the top hash, which is not in `status` already, and adding both might be too much?
00:13:39 <ndorf> `diff`, while perhaps unfortunately named, includes the top hash already
00:14:26 <luigi1111w> why is hash better matched than height?
00:17:47 <moneromooo> Age is not always super useful since depending on when you start your daemon, it might be either "when you received it" or "whatever timestamp the miner put".
00:18:14 <moneromooo> The "jitter" will be large compared to block time.
00:19:26 <moneromooo> It might be useful if it's really old, like 20 minutes ago, so that the jitter decreases relatively. But then you have a notifier for that IIRC.
00:19:52 <moneromooo> That said, if you want to add "time of last block" in get_info, I'm fine with that.
00:22:42 <moneromooo> Oh, in the console, not RPC. Then I guess you'll know when you started, so the difference between received and timestamp doesn't matter that much. The diff command seems fine.
00:23:07 <moneromooo> Oh, I might have that already actually, I made a patch to display recent block rate probabilities.
00:24:32 <ndorf> luigi1111w: `diff` includes both, height and hash
00:24:40 <moneromooo> Ah, not quite. You ask "how many blocks did I get in the last N seconds"...
00:24:48 <luigi1111w> ok. fine by me
00:25:21 <ndorf> moneromooo: is that going to be a new command or also a `diff` change?
00:25:56 <moneromooo> It is a separate command. Not sure why I didn't PR it. Maybe it doesn't work...
00:26:08 <moneromooo> Or maybe it wasn't useful enough.
00:26:43 <ndorf> ah. ok, thanks
00:27:05 <ndorf> FWIW it seems a pretty compact thing compared to add to `diff` relative to what's there already, e.g. 'AGE: 1m30s'
01:35:31 <vtnerd> iDunk the ASM cannot work in windows, they have to be re-written to support the windows call convention. every other OS uses the same call convention / ABI
01:36:24 <vtnerd> the `if (UNIX && ..` might pass for true within a cygwin environment, I was testing via linux cross-compile
09:26:59 <hyc> reverse the test, do if (_WIN32 ... )
10:02:18 <iDunk> With that test, supercop code is not selected in neither MSYS2 nor Ubuntu (mingw cross-compiler).
10:03:35 <iDunk> If I remove UNIX from the test, amd64-64-24k is selected, but results in non-working code for reasons mentioned earlier by vtnerd.
13:31:05 <hyc> well yeah, you still need ABI-compliant function prologues and epilogues
16:45:37 -xmr-pr- Mladia opened issue #6748: Cannot sync up with blockchain
16:45:37 -xmr-pr- > https://github.com/monero-project/monero/issues/6748
19:17:05 <KnifeOfPi> hello
19:17:14 <KnifeOfPi> we have a user with some very strange issues
19:17:27 <KnifeOfPi> everywhere he's loaded his wallet - including the CLI - it's shown transactions that don't actually exist
19:17:43 <KnifeOfPi> https://usercontent.irccloud-cdn.com/file/fiW64IG6/IMAGE%202020-08-06%2015%3A17%3A40.jpg
19:17:52 <KnifeOfPi> 56db0b493add26a1130be63a27c7da085070dcf38ba2582e37e669da0eba9214
19:18:46 <KnifeOfPi> he did not ever use his own node
19:18:51 <KnifeOfPi> moneromooo, are you able to help?
19:22:39 <KnifeOfPi> https://usercontent.irccloud-cdn.com/file/Tb9gIek1/IMAGE%202020-08-06%2015%3A22%3A36.jpg
19:25:21 <moneromooo> So.. a stranger's node ?
19:25:51 <moneromooo> Maybe the node lied. Put dummy data as txids.
19:26:31 <moneromooo> Or maybe there is a bug.
19:26:36 <KnifeOfPi> it's moneroworld node, and he's used multiple different nodes
19:26:47 <KnifeOfPi> cake wallet official node reported the same results from his cake wallet
19:27:39 <moneromooo> Is that user willing to apply log patches and rescan ?
19:28:03 <KnifeOfPi> i doubt it, he is really not a technical user, and i obviously can not ask for his seed and do it myself
19:28:13 <moneromooo> Well, dunno then.
19:28:46 <KnifeOfPi> if you would explain to me how to do that, i can possibly try, but it's gonna end up being a game of telephone
19:29:05 <moneromooo> Once I give the patch:
19:29:11 <moneromooo> - save it to /tmp/patch
19:29:17 <moneromooo> - cd /path/to/monero/tree
19:29:23 <moneromooo> - patch -p1 < /tmp/patch
19:29:24 <moneromooo> - make
19:29:42 <KnifeOfPi> he is running windows and there is really no way i can instruct him on how to do something like that.
19:30:01 <selsta> we can apply the patch and create bins
19:30:10 <selsta> but then he has to trust our binaries
19:30:25 <moneromooo> Oh good point, github makes test binaries.
19:30:45 <selsta> github does not currently, but I can make them or someone else can
19:31:26 <moneromooo> I'll make a patch then.
19:31:45 <moneromooo> I assume this is deterministic, right ? Always the same txid at the same hieght ?
19:31:53 <moneromooo> Or at least same height ?
19:32:16 <KnifeOfPi> Yes, it's a few different txid's. He sent these transactions and none of them were received but they show up whenever he restores; they still don't appear on the blockchain.
19:33:00 <moneromooo> Do you know the daemon url that got used ?
19:33:28 <KnifeOfPi>  node.moneroworld.com:18089
19:33:32 <KnifeOfPi> that is the one used with his CLI
19:33:56 <selsta> moneroworld is a node aggregator, so it could be any node
19:34:11 <selsta> but cake wallet node had the same issue so most likely not a lying node?
19:36:21 <moneromooo> Are the amounts as expected ?
19:36:52 <KnifeOfPi> the amounts are what he sent, yes
19:37:52 <moneromooo> Including the incoming one ? Check the ts of that block (which isn't the one on the chain for the same height).
19:38:36 <KnifeOfPi> the heck
19:38:43 <KnifeOfPi> maybe it's caused by a restore from wrong height????
19:39:12 <moneromooo> That would caused missed txes, and change being seen as receive. Not bad txids.
19:41:24 <KnifeOfPi> what could be causing it to restore the same bad txids every time?
19:41:36 <moneromooo> The daemon being malicious.
19:41:59 <moneromooo> gingeropolous: how many daemons in your aggregator ?
19:42:11 <moneromooo> And did that number go up a lot recently ? :)
19:42:31 <KnifeOfPi> it would require for every node there to be malicious, run the same malicious code, and also for our cake node to be affected
19:42:49 <moneromooo> Oh, your node was used, so likelyknow good ?
19:43:37 <iDunk> Have him check currency format in regional settings. Idk if Monero CLI uses it, but balance looks weird there.
19:43:57 <moneromooo> You think that could alter printing txids ?
19:44:32 <iDunk> I've seen weird shit in Windows caused by things I would never have guessed.
19:46:07 <vikrants> If our node was bad, we’d see 100s or thousands of these cases no?
19:46:48 <moneromooo> Are you guys the same team ?
19:47:05 <moneromooo> I mean, one case of bug, or two ? :)
19:47:24 <vikrants> One guy .. multiple transactions
19:47:35 <vikrants> Knife and i talking about the same thing
19:47:35 <moneromooo> Do you have the daemon that got used ready ?
19:48:46 <KnifeOfPi> what do you mean?
19:49:12 <moneromooo> Can you run console or RPC commands on that particular daemon ?
19:49:39 <moneromooo> (the one you're sure got used)
19:49:46 <vikrants> I’ve asked Mykola to come on
19:49:54 <vikrants> He’s getting on here
19:49:59 <moneromooo> Already there.
19:50:04 <caralho> My does the car think it gets to eat just because somebody else eats?
19:50:08 <caralho> Cat*
19:50:15 <KnifeOfPi> w a t
19:50:34 <moneromooo> Well, why would it be any different ? Might as well try, righ t?
19:50:46 <mordsid> what exactly to do ?
19:51:12 <moneromooo> I'm not sure how complex cat thought processes are, but "food is here" and "I'm hungry" definitely trigger "let's eat!".
19:51:29 <moneromooo> mordsid: Can you run console or RPC commands on that particular daemon (the one you're sure got used) ?
19:51:30 <KnifeOfPi> lol
19:52:37 <mordsid> yeah i can run
19:52:52 <moneromooo> print_block 2139310
19:53:36 <moneromooo> The log patch, to apply to the wallet rescanning: https://paste.debian.net/hidden/efe50762/
19:53:50 <moneromooo> simplewallet must then be run with --log-level 0.
19:54:47 <selsta> is this on top of master or release branch? or should it not matter?
19:55:07 <moneromooo> Hmm. It's on top of some random branch, let's check...
19:55:15 <selsta> I will add it on top of release
19:55:25 <selsta> manually worst case :P
19:55:34 <moneromooo> 19th of july, pretty recent.
19:55:50 <moneromooo> Is it known what version the buggy wallet was running ?
19:56:22 <KnifeOfPi> 0.16.0.1
19:56:31 <moneromooo> Then apply on top of that please.
19:57:36 <KnifeOfPi> We will need a compiled version if that is ok.
19:58:02 <moneromooo> If someone's feeling nice.
19:58:07 <selsta> yes, I will do it
19:58:14 <moneromooo> ^ someone nice
19:58:26 <mordsid> https://paste.debian.net/1159408/
19:59:23 <moneromooo> Looks like mine. Thanks.
20:00:01 <moneromooo> Running a scan with the patch above against that daemon would be nice, whether the original reporter or not. Can be Linux too.
20:00:24 <moneromooo> If it reports the right txid, then it must be run by the reporter to. But maybe it'll show a bad txid already.
20:01:02 <moneromooo> Rescanning for ~2k blocks before 2139310 is ok.
20:01:10 <moneromooo> (ie, not from genesis)
20:01:28 <moneromooo> I just want to see the logs from that patch. Remember --log-level 0.
20:02:17 <selsta> windows binary will probably take half an hour KnifeOfPi
20:02:53 <KnifeOfPi> this is fine, i have an exam in 2 hours so as long as its before then we are probably good
20:03:32 <selsta> mordsid: what is the cake node url?
20:04:38 <mordsid> exactly this one is xmr-node-uk.cakewallet.com:18081
20:04:42 <KnifeOfPi> yes
20:07:33 <KnifeOfPi> so - will the user have to use a different wallet-cli or is everything done on the daemon side?
20:08:34 <selsta> yes
20:08:37 <selsta> a different wallet-cli
20:08:43 <selsta> with the patch applied
20:08:58 <KnifeOfPi> ok
20:09:23 <iDunk> (The first patch)
20:09:27 * iDunk hides
20:09:57 <KnifeOfPi> lol
20:14:46 <moneromooo> Actually, I'll add some more logs if that's no bother...
20:14:52 <KnifeOfPi> ok
20:15:01 <moneromooo> (I've run the patch here and I get the expected data)
20:15:13 <selsta> didn’t start the build yet anyway
20:15:15 <KnifeOfPi> just to be clear, does the node also require a patch?
20:15:21 <selsta> no
20:15:24 <KnifeOfPi> ok
20:22:00 <moneromooo> selsta: https://paste.debian.net/hidden/7a12f102/ if you don't mind :) Thanks
20:27:50 <moneromooo> Hmm. monero-wallet-cli links against libpython for some reason :S
20:27:56 <moneromooo> Not emacs yet I think...
20:29:07 <iDunk> Not here
20:32:02 <selsta> hmm can I select a branch with gitian-build.py?
20:32:23 <selsta> I thought this was possible by simply specifying it instead of version number
20:32:34 <iDunk> Yes, it's the last item
20:33:03 <iDunk> But it's the remote branch, IIRC.
20:33:47 <iDunk> I can fire up a depends build quickly, all my deps are already built.
20:34:21 <selsta> https://github.com/selsta/monero/commit/079a14dfa1d566a6742d06d40a6605706d35612f
20:34:24 <selsta> this would be the commit
20:34:40 <selsta> I did this before but I can’t get it to work now... hmm
20:34:46 <selsta> ./gitian-build.py --setup --docker --url https://github.com/selsta/monero selsta cake
20:35:31 <moneromooo> I've tried a restore with the patch and the daemon above, and I get correct results. So it'll have to be run by the reporter.
20:38:31 <selsta> ok solved it, looks like gitian-build.py does not like a different URL after already setting up a different one
21:33:12 <selsta> KnifeOfPi: uploaded the monero-wallet-cli here (with signed hash) https://gui.xmr.pm/files/cli/cake-issue-tmp/
21:34:02 <selsta> they have to run the cli with --log-level 0
21:34:21 <selsta> and also make sure to use the xmr-node-uk.cakewallet.com:18081 node
21:35:34 <KnifeOfPi> thank you selsta, very cool
21:35:55 <KnifeOfPi> i will let you know what happens
21:35:58 <selsta> and then please send the logs to mooo
21:48:15 <moneromooo> ty selsta
22:26:48 <dEBRUYNE> Anyone an idea here? If I recall correctly, the spend proof should still be available even without the private transaction key, as it basically simply proves you signed the rign
22:26:51 <dEBRUYNE> https://www.reddit.com/r/Monero/comments/i0zcv9/if_i_use_online_wallet_like_xmrwalletcom_there_is/