.merge+ 4502

Added

<s​pirobel:kernal.eu> what is the behavior of monero-gui / feather wallet when the remote daemon returns trash outputs when building a tx github.com/monero-project/monero/bl…cabbaa/src/wallet/wallet2.cpp#L9486 will it ever retry building with the same real output with the same daemon?

<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

<j​effro256:monero.social> The wallet will basically be stuck until one using the `unset_ring` command in the CLI

<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>

<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)

mentioned in breaking monero - remote nodes iirc

<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>

<j​effro256:monero.social> nstruct the transaction

<j​effro256:monero.social> This could be partially resolved by caching the selected decoy indices before the call to `get_outs`

<j​effro256:monero.social> Instead of after it

<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"

<s​pirobel:kernal.eu> plowsof youtube.com/watch?v=n6Bxp0k7Uqg&lis…=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 github.com/monero-project/monero/blob/8d4c<clipped message>

<s​pirobel:kernal.eu> 625713e3419573dfcc7119c8848f47cabbaa/src/wallet/wallet2.cpp#L9607C5-L9607C30

<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);

<s​pirobel:kernal.eu> looked at the feather wallet source: github.com/feather-wallet/feather/b…a0ecec895cc/src/MainWindow.cpp#L836

<s​pirobel:kernal.eu> catch (const tools::error::get_outs_error &e) {

<s​pirobel:kernal.eu> message.description = "Failed to get enough decoy outputs from node";

<s​pirobel:kernal.eu> message.helpItems = {"Your transaction has too many inputs. Try sending a lower amount."};

<s​pirobel:kernal.eu> is this the error message for this case ?

<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.

<o​frnxmr:monero.social> I think feather is different, because it doesnt do a `transfer_split`

<o​frnxmr:monero.social> actually, nevermind. Feathers limit would be based on tx size, not inputs