00:08:32 KnifeOfPi: I just tested the branch with `./monero-wallet-cli --log-level 0 --restore-deterministic-wallet --daemon-address node.xmr.to:18081` 00:09:12 and my logs are correct, so they are doing something wrong at some point (sends wrong logs maybe) 00:09:19 can you ask them to use a different file hoster? 00:14:08 he’s sent the file like 3 different ways 00:14:14 every time 73kb 00:14:44 Maybe his disk is shot ^_^ 00:15:05 That wouldn't explain the seemingly nice extra logs though. Shrug. 00:15:05 Or RAM. 00:20:20 The log timestamp seems to be earlier than the binary timestamp, assuming it's not a locale display thing. 00:20:53 timestamp seem to match, the wallet got created at minute 56 and the logs also begin at 56 00:21:11 the binary timestamp are the same as mine 00:22:36 nvm, I misread 8/6. 00:22:57 did you see this wallet2.cpp:2501 logging line before? 00:23:46 I don't remember. 00:25:14 KnifeOfPi: can the person move out his coins? 00:26:10 i will ask 00:33:54 no he can not move out his coins. 00:34:04 his wallet shows only 0.084 XMR balance. 00:34:42 Which makes sense if you count the digits 84.,201,250,000 00:36:03 The std::to_string probably butchers the number (there's a broken patch on github to deal with that). 00:36:32 So the code to insert . sees , as another character. 00:37:48 KnifeOfPi: and what is his balance supposed to be? 00:39:04 src/wallet/wallet2.cpp:2625Received money: 0.084201250000, 00:39:19 it should be 128 XMR I believe 00:39:32 none of the transactions he sent ever actually showed up on the chain 00:39:44 but they were still deducted from his balance 00:40:40 I think someone is pulling your leg with fake txids. 00:40:46 I guess you could ask to run with windows' equivalent of all the LC_* unset. 00:41:55 this guy seems very non technical 00:42:11 Enough to add new logs :) 00:42:12 well something is weird here, the logs even say that he is running the correct commit according to the version number 00:43:34 moneromooo: would the logs show up if --log-level 0 is missing? 00:44:45 Only the first line showing log levels. 00:46:21 e.g. the logs say 2020-08-07 22:13:03.603 16984 ERROR wallet.wallet2 src/wallet/wallet2.cpp:1889 00:46:26 1889 is a line we added 00:46:40 but the logs don’t match what it is supposed to say 00:47:13 selsta: what platform are you running on ? 00:47:28 Mac, I was going by the logs the KnifeOfPi sent 00:47:34 that* 00:48:04 when I run the branch it looks correct on my mac, it says the `process_new_transaction: money received in` line 00:48:24 iDunk: if we can get the locale settings that person runs with, could you try running with those to see if you get weird things ? 00:48:35 he is from pakistan 00:48:37 (on windows) 00:49:27 (or anyone else who runs windows) 00:49:33 Sure (but I still think someone in Pakistan is trying to get something for nothing). 00:50:36 Hmm. The code printing txids doesn't use std::to_string, it indexes direcrtly into a hex char string, so unlikely to be a locale thing. 00:51:43 is that enough info (from pakistan) for windows ? 00:52:56 They've got at least two languages there IIRC, pashtun and.. arabic I think ? 00:54:41 Wikipedia gives a few more. 00:57:58 US English numbers and currency formats https://i.imgur.com/7kgRZHK.png https://i.imgur.com/Hq3b5Qi.png 00:58:24 Pashto (Pakistan) numbers and currency formats https://i.imgur.com/8VQpPBh.png https://i.imgur.com/qeaFP4N.png 00:58:37 ^ default settings. 01:00:57 The , matches what we see. So, are txid mangled ? :) 01:22:22 the line numbers seem totally wrong in the logs 01:24:35 even for known things like the "Received money with tx" line 01:30:36 L473 looks like an editing fail. 01:32:56 Heh, odd one indeed. 01:33:54 Could be two threads logging at once maybe. 01:34:48 Though I don't see a partial remainder of such a line. 01:35:35 iDunk: btw does the binary produce expected logs on your system? 01:36:24 I might as well run it... 01:45:48 (Not to mention that block heights in the last four lines are ~10 days into the future) 01:52:07 lol what the hell 01:52:33 why would he go through effort of faking logs 01:52:50 Social atomic swaps :) 01:56:14 I don’t understand what’s going on lol 01:56:22 but the weird logs + changing file size is suspicious 01:56:28 though not sure what he is trying to achieve 01:57:20 could it be caused by a localization issue...? 02:03:30 Here's what line numbers belong to what category and what they log https://paste.debian.net/hidden/b7971390/ 02:04:10 iDunk: that’s what it looks like on my system too 02:04:14 this was with my bin? 02:04:21 With mine. 02:05:21 KnifeOfPi: one thing he can try is to restore a non broken wallet and then post the logs 02:05:34 if the resulting logs are also broken then I would guess some localization issue 02:05:58 Or an attempted scam. 02:06:21 also possible :D 02:19:32 http://explorer.monero-classic.org/search?value=d24ba2ba4d45b967b0b65d5c6fbab8faec13055c8474f95cfaf3b6cec9718d43 02:20:44 XMC->XMR swap :D 02:22:26 Block heights in the future make sense now. 02:23:04 still don’t fully get it 02:23:13 tried to scam? 02:23:23 Someone is trying to pass his XMC for XMR. 02:23:38 you think the logs are faked? 02:23:45 Yes. 02:23:59 the whole story was suspicious anyway lol 02:24:04 I linked the 128 XMR txid to Monero Classic. 02:24:12 yea I saw it 02:24:36 soo they used XMC to create the screenshot? 02:24:49 and then merged the logs 02:24:59 Probably. 02:25:46 doctored logs would explain why they went from 100KB -> 70KB lol 02:29:02 iDunk: log line numbers match XMC https://github.com/monero-classic/monero/blob/master/src/wallet/wallet2.cpp#L2501 02:29:59 Mystery solved :) 02:31:27 w a t 02:31:29 XMC??? 02:31:52 its fucking monero classic 02:38:33 is there any way it could have been done by mistake? 02:41:27 KnifeOfPi: no 02:41:34 No, the logs were doctored. You only need to take a look at other lines in the wallet2.cpp selsta linked. 02:41:41 fucking hell man 02:43:06 "FUCKXMR" wallet name made me look at other forks' explorers :) 02:43:26 i had expected he would just be mad 02:43:38 because we had him use cli and he was acting like a very non technical user 02:43:45 this idiot wasted many hours of our time 02:44:47 I think he was trying to get a "refund". That's why I keep calling it a swap. 02:46:05 yeah, that's what I expected 02:46:27 he seemed suspicious from the beginning because he complained of 128xmr being 1 year of his income 02:46:36 so how the hell did he buy it in the first place 02:53:20 hey, iDunk, did he just use straight up XMC logs, or did he try to splice in some stuff from the proper wallet log? 02:54:08 he mixed them 02:54:43 Wow 02:55:01 So someone who knows how monero works well 02:55:04 i almost want to make a post on /r/monero to expose this guy 02:56:34 he wasted so many hours of time of everybody on the cake wallet team, and you guys as well 02:56:56 > ok i wont be able to do it again please... i have tried thousand times and then my seed works 02:57:08 he would usually take 30 minutes to one hour to respond with stuff 02:57:11 guess because he was faking shit 02:57:29 welcome to my world 02:58:15 endogenic: this happened to u before? 03:00:14 running a high traffic wallet and having to support lots of different user cases? being asked to do things for people on occasionally bad info who didnt want to contribute back? lol welcome to cryptocurrency 03:00:19 risk 03:00:21 finance 03:01:29 Yeah 14:45:32 -xmr-pr- moneromooo-monero opened pull request #6752: wallet2: fix setting tx keys when another is already set 14:45:32 -xmr-pr- > https://github.com/monero-project/monero/pull/6752 17:24:37 moneromooo: I can't sync monerod from scratch. Using recent master build. I's beind stuck with calculating tx weight. 2020-08-08 17:23:16.881 E get_pruned_transaction_weight does not support older range proof types 17:24:54 Is it interesting bug or something trivial to avoid? 17:30:29 If you're going to release soon then this bug will pop up later. it's likely unexpected regression. 17:31:07 I thought I'd fixed that. Let me check github... 17:32:28 What height block is it breaking on ? 17:33:13 2020-08-08 17:32:03.354 I transaction is too heavy: 18446744073709551615 bytes, maximum weight: 149400 17:33:16 2020-08-08 17:32:03.354 E Transaction verification failed: 17:35:26 Thas' from block 1685619 17:36:32 I can locally dig into it if it's important and not trivial problem. 17:36:51 I'd like to know where it's coming from (call stack). 17:41:20 Ok. I'll try to debug it personally since it require this level of details. 17:43:45 I think https://paste.debian.net/hidden/f12b5837/ will fix it. 17:44:04 I was asking for prunable from when BPs started, but should do so only when they become mandatory. 17:44:40 Alternatively, making get_pruned_transaction_weight support Borromean proofs would be better. 17:48:16 Why this error didn't pop up earlier during your own testing? 17:48:32 I doubt I made a full sync. 17:49:19 Are there no any relevant regression tests in monero codebase? 17:49:27 Not for this. 17:50:07 More tests are welcome if you feel like adding some. Though tests syncing through actual live data... not sure. 17:50:41 Patch works: it's syncing. Hope my report was useful. 17:50:47 Thanks for fast response. 17:50:48 It was. Thanks. 17:52:32 UkoeHB_: Thanks, I may have conflated two different proofs 18:00:32 -xmr-pr- moneromooo-monero opened pull request #6753: cryptonote_protocol: don't synced pruned blocks before v9 18:00:32 -xmr-pr- > https://github.com/monero-project/monero/pull/6753