05:01:54 <joe-molested-hun> Hi all, I would like to make a bug report but HOLY SHIT it is difficult to sign up to GitHub anonymously
05:02:21 <joe-molested-hun> You should really really really consider a self-hosted GitLab instance; using GitHub is super antithetical to the whole ethos of the project IMO
05:02:25 <joe-molested-hun> Anyway, here is the bug:
05:04:53 <joe-molested-hun> Using monero-gui 0.17.2.3, when I do the following procedure, I am stuck with the decoys selected no matter what I do
05:04:53 <joe-molested-hun> 1. Go to "Send" tab and fill in an address and select "infinity" amount
05:04:53 <joe-molested-hun> 2. Click "Send" button
05:04:53 <joe-molested-hun> 3. *Either* click "Back" *or* just let the confirmation screen time out
05:05:26 <joe-molested-hun> When I do this, I see in the monero-gui console output the absolute offsets of all decoys (+ real output) chosen for the transaction
05:06:58 <joe-molested-hun> The problem is that whenever I try to make any new transaction using these outputs, it always selects the same decoys. Since decoy selection is highly time-sensitive, this leaks information about which output is real, and stands out as following a very different statistical distribution than other contemporary transactions
05:08:30 <joe-molested-hun> Is there a quick workaround I can use to e.g. discard the cache or whatever is storing these stale decoys for reuse?
05:12:05 <selsta> "it always selects the same decoys" <-- how long did you wait?
05:13:48 <selsta> matrix bridge being buggy again... joe-molested-hun: "it always selects the same decoys" <-- how long did you wait?
05:14:50 <joe-molested-hun> I tried multiple times, restarting the wallet, restarting monerod, over about 10 hours
05:16:02 <joe-molested-hun> Interestingly, if I try to send a smaller amount that consumes only one available output, the decoys for that output are the same stale decoys, even though the transaction is totally different (i.e. only spends that output instead of all outputs)
05:18:30 <selsta> will check if I can reproduce tomorrow
05:18:42 <joe-molested-hun> Great, thanks
05:20:24 <joe-molested-hun> Can you point me to the relevant section of code where decoys are selected? I navigated to src/libwalletqt/Wallet.cpp but didn't find an xref for Wallet::creatrTransactionMultDest()
05:20:38 <joe-molested-hun> createTransactionMultDest() *
05:21:54 <selsta> wallet2.cpp should have that code
05:22:45 <joe-molested-hun> `find src/ -type f | grep -i wallet2` shows nothing?
05:23:04 <joe-molested-hun> Is this in another project?
05:24:11 <selsta>  monero repo
05:24:26 <selsta> monero-gui/monero/src/wallet/wallet2.cpp
05:24:48 <joe-molested-hun> Oh
05:24:54 <joe-molested-hun> It's a submodule or something?
05:25:08 <selsta> yes
05:25:20 <joe-molested-hun> I guess I have to clone again with recurse-submodules or whatever
05:25:31 <joe-molested-hun> Such a git anti-feature...
05:55:31 <joe-molested-hun> Throughout `create_transactions_from()` in monero/src/wallet/wallet2.cpp:10520 a lot of references to `LOG_PRINT_L2()`
05:55:43 <joe-molested-hun> How can I configure monero-gui to show these messages?
05:55:56 <joe-molested-hun> Do I need to rebuild it with some flag?
06:00:53 <joe-molested-hun> Nevermind, I'm a moron
06:03:38 <louipc00D> same
06:16:15 <joe-molested-hun> So the problem appears to be that `wallet2::get_outs()` in monero/src/wallet/wallet2.cpp:8376, we check the ringdb and "if we have a known ring, use it", apparently unconditionally.
06:16:15 <joe-molested-hun> I guess the root cause is those rings being added to the ringdb before we actually spend them.
06:16:43 <joe-molested-hun> Is there any somewhat easy way to remove these entries from the ringdb?
06:17:06 <joe-molested-hun> s/spend them/spend the asociated outputs/
06:22:21 <joe-molested-hun> Or maybe the root cause is marking the transfers' `m_key_image_known` before the transaction is actually broadcast
06:24:57 <joe-molested-hun> How risky would it be to monkey patch monero/src/wallet/wallet2.cpp:8376 to `if (0)`, rebuild, and use that binary to spend these outputs with new decoys, then go back to using the "official" binary?
06:27:04 <wfaressuissia1> "Is there any somewhat easy way to remove these entries from the ringdb?" 
06:29:16 <wfaressuissia1> "https://github.com/monero-project/monero/pull/5388/files", "unset_ring <txid> | ( <key_image> [<key_image>...] )" did you try this cmd with monero-wallet-cli ?
06:29:59 <joe-molested-hun> I did not, thanks for the pointer
06:30:10 <joe-molested-hun> That's exactly the kind of thing I was looking for
06:30:54 <joe-molested-hun> Thanks a lot :)
07:18:15 <joe-molested-hun> Unfortunately that doesn't seem to work. I open the wallet in monero-wallet-cli, `unset_ring` my key images, `exit`, start monero-wallet-gui, attempt a spend as before, and I still get (log level 2) "Found ring for key image" and the same decoys selected
07:24:30 <joe-molested-hun> Oops, forgot to `save` before `exit`ing. But doing that doesn't change anything--the same decoys are still selected.
07:24:56 <wfaressuissia1> "https://github.com/monero-project/monero/blob/master/src/wallet/ringdb.cpp#L318" do you see any of this msgs in log of monero-wallet-cli ?
07:27:35 <joe-molested-hun> No, but I don't know where those logs are, and I surely don't have debug level logs enabled
07:28:12 <wfaressuissia1> `monero-wallet-cli ... --log-file some.file --log-level '*:TRACE'`
07:28:18 <joe-molested-hun> I can try again once I figure out how to enable debug level logs and where to find them (apparently they are not in ~/.bitmonero?)
07:28:24 <joe-molested-hun> OK thanks
07:31:03 <joe-molested-hun> No, I do not see that message!
07:31:12 <joe-molested-hun> wtf m8
07:31:20 <joe-molested-hun> The plot thickens
07:32:37 <joe-molested-hun> I see "Read command: unset ring ..."
07:32:50 <joe-molested-hun> and then "Read command: save"
07:33:04 <joe-molested-hun> then some cruft and "Wallet data saved"
07:33:19 <joe-molested-hun> i.e. it appears that issuing the `unset_ring` command does absolutely nothing at all
07:53:32 <wfaressuissia1> "https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L7731" do you see the same path for cli and gui wallets ?
07:57:45 <joe-molested-hun> Hang on, I need to restart gui in log level 2
07:59:37 <joe-molested-hun> Yes, they use the same path
08:01:11 <wfaressuissia1> There is a way to retrieve cached ring members for key image. gui: advanced -> shared ringdb -> get ring -> ...; cli: print_ring key_image_hex
08:01:33 <wfaressuissia1> Does gui show something and cli show nothing for the same key image ?
08:01:42 <joe-molested-hun> Let me check
08:03:38 <joe-molested-hun> Aha
08:03:56 <joe-molested-hun> There is a difference
08:04:20 <joe-molested-hun> GUI shows the ring as I keep seeing it
08:04:36 <joe-molested-hun> CLI shows "Error: Key image either not spent, or spent with ring size 1"
08:04:56 <joe-molested-hun> Which is correct, of course; it hasn't been spent
08:05:21 <wfaressuissia1> did you open monero-wallet-cli with the same seed/key file/.. ?
08:06:43 <joe-molested-hun> Yes of course lol
08:09:01 <joe-molested-hun> This begs the question: If I try to do my spend from wallet-cli, will it try to use those same rings/decoys? My guess is no
08:10:29 <joe-molested-hun> I will still have the opportunity to refuse to confirm the spend in wallet-cli, right? So I can attempt it to see which decoys it selects without being forced to spend it however it comes?
08:12:08 <wfaressuissia1> In the worst case compile debug build, attach gdb and check wtf is going on in both gui and cli, there must be some difference.
08:12:24 <wfaressuissia1> "https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L7755" maybe this key is different for some reason
08:12:42 <joe-molested-hun> > compile debug build
08:12:53 <joe-molested-hun> welp, guess I get to learn how to build Monero
08:13:17 <joe-molested-hun> maybe a project for tomorrow...
08:53:53 <wfaressuissia1> joe-molested-hunter[m]: how many kdf rounds did you set in gui ?
09:14:04 <joe-molested-hun> <wfaressuissia[m]> "joe-molested-hunter[m]: how many..." <- Not sure, where do I check?
09:18:16 <wfaressuissia1> it's failed speculative question too since the same key file can't be opened with different kdf rounds, therefore both gui and cli have the same value.
09:53:08 <jberman[m]> "So I can attempt it to see which decoys it selects without being forced to spend it however it comes?" -> set log level 1, construct the tx, then before confirming check the logs, grep for `key_offsets`
10:01:18 <joe-molested-hun> Great, will try it tomorrow
10:01:21 <joe-molested-hun> Thanks
15:35:21 <BigmenPixel[m]> Monero has an optional ldns dependency, but does monero-gui really need it?
15:36:44 <BigmenPixel[m]> That is, if it does not exist, then the functionality will not decrease because of this?
16:58:25 <fluffypony> BigmenPixel[m]: yes - it's used by OpenAlias, auto-updates, etc.
18:31:08 <nero-cultist[m]> Okay but monero should have 
18:31:18 <nero-cultist[m]> The among us impostor added into the source code 
18:31:28 <nero-cultist[m]> Because anonymous pow transactions are sus 
21:44:50 <Rucknium[m]> luigi1111w: It seems to me that my CCS proposal has attained loose consensus within the community to move to Funding Required. What do you think?
21:46:49 <luigi1111w> did that include post recent updates?
22:00:29 <Rucknium[m]> luigi1111w: Here's the most recent Reddit discussion of it:
22:00:29 <Rucknium[m]> https://www.reddit.com/r/Monero/comments/qne00d/monero_observer_articmine_and_isthmus_weigh_in_on/
22:00:29 <Rucknium[m]> #monero-community:libera.chat  meeting that discussed it on Sunday:
22:00:30 <Rucknium[m]> https://github.com/monero-project/meta/issues/625#issuecomment-962678243
22:00:30 <Rucknium[m]> And it seems wherever I pop up in Moneroland people want the proposal to move forward, e.g.
22:00:30 <Rucknium[m]> https://www.reddit.com/r/xmrtrader/comments/qrgaks/daily_discussion_thursday_november_11/hk7ig1l/
22:04:47 <luigi1111w> done
22:05:30 <Rucknium[m]> My latest edits to the proposal are fairly minor. Incorporated isthmus 's suggestion that I spend some time searching the literature for possibly better solutions, stated that disclosure of the statistical vulnerability could be done once a solution is found, some wording changes.
22:14:00 <luigi1111w> https://ccs.getmonero.org/proposals/Rucknium-OSPEAD-Fortifying-Monero-Against-Statistical-Attack.html
22:15:09 <Rucknium[m]> Fantastic. Thank you for managing the process.
22:16:45 <luigi1111w> glhf :)