16:32:18 <selsta> .merge+ 4502
16:32:18 <xmr-pr> Added
19:05:55 <m-relay> <s​pirobel:kernal.eu> what is the behavior of monero-gui / feather wallet when the remote daemon returns trash outputs when building a tx https://github.com/monero-project/monero/blob/8d4c625713e3419573dfcc7119c8848f47cabbaa/src/wallet/wallet2.cpp#L9486 will it ever retry building with the same real output with the same daemon?
19:09:26 <m-relay> <j​effro256:monero.social> It does if the ring signatures are constructed without error and verify locally. The wallet doesn't check if the outputs are actually in the chain at those positions, so the daemon could give "real" outputs but the wrong indicies for those outputs and the wallet will verify but any honest daemon will not
19:10:39 <m-relay> <j​effro256:monero.social> The wallet will basically be stuck until one using the `unset_ring` command in the CLI
19:30:20 <m-relay> <s​pirobel:kernal.eu> that wouldnt tell the daemon the real output though ... how about when the daemon sends a response so not enough decoys can be picked. I recon in this case continuing to communicate with this node would inevitably result in revealing the real output. (on the first try the real output will be included, now we make the wallet try again and again, the real output is not included in s<clipped message>
19:30:21 <m-relay> <s​pirobel:kernal.eu> ubsequent trys, after a while we respond such that there are enough outputs that can be used in decoys, we see a transaction appear with those decoys + the real output that we got from the first attempt)
19:36:48 <plowsof> mentioned in breaking monero - remote nodes iirc  
19:38:37 <m-relay> <j​effro256:monero.social> Sorry, I was incorrect about when the rings are set. There are set at the end of `get_outs()` after all calls to `get_output_distribution`, `get_output_histogram, and `get_outs` . But yes, this may an issue if the daemon returns a bad response to the actual `get_outs.bin` RPC call after the wallet receives the output distribution, and the wallet continues to try repeatedly to reco<clipped message>
19:38:39 <m-relay> <j​effro256:monero.social> nstruct the transaction
19:40:16 <m-relay> <j​effro256:monero.social> This could be partially resolved by caching the selected decoy indices before the call to `get_outs`
19:41:46 <m-relay> <j​effro256:monero.social> Instead of after it
19:43:07 <m-relay> <j​effro256:monero.social> The RingDB would have to be modified to be able to differentiate between "requested indices over RPC" and "indices actually used in the constructed ring signature"
20:14:11 <m-relay> <s​pirobel:kernal.eu> plowsof https://www.youtube.com/watch?v=n6Bxp0k7Uqg&list=PLsSYUeVwrHBnAUre2G_LYDsdo-tD0ov-y you mean this right? the case that corrupted outputs are fed is mentioned. my focus was the case that not enough outputs are returned which is a slight difference, but it seems like the wallet would through an exception in this case as well https://github.com/monero-project/monero/blob/8d4c<clipped message>
20:14:13 <m-relay> <s​pirobel:kernal.eu> 625713e3419573dfcc7119c8848f47cabbaa/src/wallet/wallet2.cpp#L9607C5-L9607C30
20:15:28 <m-relay> <s​pirobel:kernal.eu> am I at the right spot here in line 9607 or is this the wrong codepath?     THROW_WALLET_EXCEPTION_IF(!scanty_outs.empty(), error::not_enough_outs_to_mix, scanty_outs, fake_outputs_count);
20:32:53 <m-relay> <s​pirobel:kernal.eu> looked at the feather wallet source: https://github.com/feather-wallet/feather/blob/bb7715fdde7a162bf180dfefafe6ba0ecec895cc/src/MainWindow.cpp#L836
20:33:21 <m-relay> <s​pirobel:kernal.eu> catch (const tools::error::get_outs_error &e) {
20:33:23 <m-relay> <s​pirobel:kernal.eu>                 message.description = "Failed to get enough decoy outputs from node";
20:33:25 <m-relay> <s​pirobel:kernal.eu>                 message.helpItems = {"Your transaction has too many inputs. Try sending a lower amount."};
20:33:48 <m-relay> <s​pirobel:kernal.eu> is this the error message for this case ?
20:35:42 <m-relay> <s​pirobel:kernal.eu> if that is the case I would recommend using a different message because it does not communicate the security implications clearly. would be best to not retry and switch nodes immediately.
20:49:16 <m-relay> <o​frnxmr:monero.social> I think feather is different, because it doesnt do a `transfer_split`
20:50:14 <m-relay> <o​frnxmr:monero.social> actually, nevermind. Feathers limit would be based on tx size, not inputs