15:59:51 * r4v3r23[m] uploaded an image: (65KiB) < https://libera.ems.host/_matrix/media/v3/download/monero.social/hbSrCLLyfbYyKIVcvHFFngTD/Screenshot%20from%202023-08-03%2011-59-27.png >
16:28:10 <jeffro256[m]> Hey jberman , I released a PR for adding k-anonymity to txid fetching here: https://github.com/monero-project/monero/pull/8958. I was thinking that (if this PR gets merged) we apply this technique to `scan_tx` for untrusted daemons. B/c requesting a single txid at a time leaks information to the daemon, if we instead hide this request among, say 300 txids, we leak much less information and it could likely be safe enough to use this
16:28:10 <jeffro256[m]> feature w/ an untrusted daemon instead of blocking it altogether 
17:11:42 <selsta> +1 for using k-anonymity for scan_tx
17:25:08 <jeffro256[m]> Hey I might be tripping, but doesn't scan_tx already reveal which txs the user is requesting to rescan on an untrusted daemon anyways? The first line: tx_entry_data txs_to_scan = get_tx_entries(txids) requests tx entries over RPC about those txids the user provides before we guard against untrusted daemons a few lines below.
17:38:21 <Rucknium[m]> jeffro256: Could you explain the expected situation for using `scan_tx`? If it is a one-time scan for, e.g., a tx that a user knows they are supposed to receive, then you probably achieve something close to the intended k in the k-anonymity. If a user is sending multiple `scan_tx` requests to a single untrusted node, _especially if those txs are linked by ring signatures_, then you are probably not achieving the k.
17:45:08 <jeffro256[m]> Damnnit Ruck you stumped me 
17:45:17 <jeffro256[m]> ;) 
17:45:25 <jeffro256[m]> I'm going to have to think about that
17:49:30 <jeffro256[m]> This also applies if there's a heavier weight for if a user would request to rescan a tx within a certain time period (think confirming txs)
18:08:36 <jeffro256[m]> Oh that's right, thanks