06:22:20 blog post announcing the upcoming network upgrade: https://web.getmonero.org/2020/08/18/network-upgrade-october-2020.html 06:22:27 please spread it on social media 07:47:06 I guess this requires upgrafing HW wallets too, to support CLSAG? 07:48:06 Inge-: yep 08:16:29 http://27blltx6kt26k65umbs2tme6rhv4i7rhagnzzljp3bsoqfkj6w364sqd.onion/cake-wallet-more-suggestions.html 08:50:01 https://www.reddit.com/r/fightporn/comments/idu095/brutal_head_kick_during_a_traffic_altercation/ 08:50:04 wrong channel 08:58:17 nothing like some violence to kickstart the weekend 09:00:30 azy: How is that related to this chat? Let's remember this is not -pools 09:01:08 sorry it was meant for my JUST BLEED bros in #redditmma 09:01:52 usually its my default channel, but i guess i left this as my default channel when copypasting kayront's blog 09:02:09 Oh ok. Didn't see the "wrong channel" message right after :) 10:03:36 Hello all, anyone else having a weird bug in the new version of Monero wallet where there are duplicated incoming transfers of zero value? 10:04:29 As in, I have my real transfers with correct amounts, and there are also incoming transfers listed of 0.000000000000 amount with the same txid 10:04:53 Entering "incoming_transfers verbose" has them deduplicated, however 10:11:35 More info is needed. 10:11:52 I type in "show_transfers" 10:12:31 Correct transfers display. But transfers in the same block with zero value also display. 10:14:07 For example: 10:14:17 15449** in unlocked 2018-04-** 21:**:** *.**8289040000 3**************************************************************a 0000000000000000 0.000000000000 49****:*.**8289040000 0 - 10:14:18 15449** in unlocked 2018-04-** 21:**:** 0.000000000000 3**************************************************************a 0000000000000000 0.000000000000 49****:0.000000000000 0 - 10:14:58 It is a wallet file that was generated in a previous version. 10:15:33 It has never shown phantom transactions until I loaded it using the latest version of the CLI 10:16:08 Can you try without 096a9dbdf958d23f74d132247143b8b8d3cb6dcd ? 10:16:17 (rescan_bc would be needed) 10:16:35 Actually, first: 10:16:38 I recently made a new transaction to it (as in literally just now); this resulted in only a single output, as expected 10:16:54 Run with --log-level 2, rescan_bc, post the wallet log for that height. 10:17:08 Censoring of addresses is fine. 10:17:58 what parameters should be used for rescan_bc, a full/hard rescan? 10:18:20 No parameters should be fine. 10:20:26 Ok, it's going to take a while now 10:23:45 So, not every transaction has a duplication. Ones prior to 2020-07-04 do duplicate, but ones after 2020-07-13 do not. (I wouldn't know more specifically as I did not receive any outputs between those dates) 10:24:40 Is that when you updated monero-wallet-cli ? 10:27:26 I do not think so, but I couldn't tell you for sure. 10:28:03 Actually, I will try reopening the previous file I saved in a different folder for v0.16.0.1 10:32:43 Ok, so one of my older backup wallets is also showing this, which means I might have misrememebered and it isn't related to the update 10:34:33 This wallet is a view-only wallet if it would make a difference 10:36:18 ugh, when I try to rescan it keeps crashing 10:42:32 Run with gdb, and "bt" once crashed. 10:43:48 Also, do all the txes showing these 0 outputs come from the same person ? 10:43:49 It occurs to me that using my usual script that launches monerod as a solo-miner may have contributed to crashes during blockchain rescan. I've turned it off 10:44:32 They are show an identical transaction id that was a real output 10:44:36 *all 10:45:00 these transactions come from different parties and to different address types (main address and subaddress) 10:48:01 Well it crashed again without any mining. With regards to gdb/bt, I am using windows 10:48:27 It being monerod or monero-wallet-cli ? 10:48:44 monero-wallet-cli during blockchain rescan 10:49:18 Maybe the level 2 log shows something interesting just before the crash. 10:49:58 Is it the .log file, or the .log-part-10 file that is the latest? 10:50:04 .log 10:50:55 It wasn't up to a point where I had transactions, so I don't think it would be relevant to the duplication of transfers 10:51:28 The last few lines are: 10:51:42 2020-08-22 10:45:25.770 16968 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:2564 Processed block: <61378797e9b72d076d2c8367ea5cc1532b12ba393f1f0d65a8b5a833f1a68713>, height 271728, 1(0/1)ms 10:51:42 2020-08-22 10:45:25.773 18396 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:2620 Pulling blocks: start_height 0 10:51:42 2020-08-22 10:45:25.975 18396 DEBUG wallet.wallet2 src/wallet/wallet2.cpp:2644 Pulled blocks: blocks_start_height 272727, count 1000, height 273727, node height 2169909 10:52:15 What is the crash message ? 10:52:23 None, it just quit 10:53:26 Well, I guess I'll do a rescan_bc here to see if it crashes. 10:55:14 I think this would not be such a big deal to fix though, just suppress outputs displayed where the amount is exactly zero if the user requests a print via "show_transfers". Though why it's showing up in the first place is a mystery to me. 11:01:13 I opened a watch-only of the donation address that I definitely created using v0.16.0.1 of monero cli. And it does not show any transfers of 0.0000000, so I think if it was an issue with versions I think it may have been a prior version that introduced this error and later versions have not fixed it. 11:05:52 By "not fixed it" I mean that they won't create wallets with the issue, but they will also not rectify wallets with this issue if they're opened by them 23:57:35 Do you thin that having monero connected to a trezor is any advantage vs having a debian linux with fs encrypted running monero-wallet-cli with the local keys (adding paper wallet printed with some kind of my own encryption in the printed paper, and recovery tested) ? 23:59:00 Do not know if it brings any added value to my monero protection that I'm not comprehending... It seems one more technology to make me depending on it. Any opinion on this?