07:34:51 <m-relay> <r​4v3r23:monero.social> yes but its consistent and ive never seen this before
14:25:59 <m-relay> <o​frnxmr:monero.social> Tried a different node?
16:16:44 <selsta> I have seen the same issue with lost connection to node when creating tx
16:27:35 <m-relay> <o​frnxmr:xmr.mx> I'm currently running spammer on a couple testnets and only see this issue if the node has >100 connections and has not modified their parameters
16:28:39 <m-relay> <o​frnxmr:xmr.mx> --rpc-max-connections 1000 --rpc-max-connections-per-{private|public}-ip 1000 = no problems. If using well known public nodes, they are often overloaded
16:29:04 <selsta> I saw it on a local node with 1 connection, had to retry tx creation sometimes
16:29:12 <selsta> only saw it with monero-wallet-cli
16:31:11 <m-relay> <o​frnxmr:xmr.mx> another situation where i can get wallet-cli to complain about no connection to daemon, is during sweeps etc that take too long
16:31:44 <m-relay> <o​frnxmr:xmr.mx> https://github.com/monero-project/monero/issues/10032
16:32:28 <m-relay> <o​frnxmr:xmr.mx> 10s of minutes might be more than necessary tk reproduce, but was what i was dealing with at the time
22:09:21 <m-relay> <r​4v3r23:monero.social> only on v0.18.4 or before?
22:29:18 <m-relay> <s​pirobel:kernal.eu> the decoy selection code goes like: 1.get output distribution. 2. sample possible outputs according to this distribution 3. check that that the outputs are unlocked by fetching them from the node. In step 2 it will oversample. one comment says 1.5x + 75 but the comment seems outdated. it seemed more like 1.5x + 1
22:29:38 <m-relay> <s​pirobel:kernal.eu> still if it has to do this sequentially for lots of outputs there will be a lot of back and forth
22:30:32 <m-relay> <s​pirobel:kernal.eu> would make sense to sample lots of decoys for all the outputs and then ask for them in one api call
22:31:25 <m-relay> <s​pirobel:kernal.eu> (rewriting the monero-oxide dsa currently to oversample as well so I am familiar with this code)
22:35:48 <m-relay> <s​pirobel:kernal.eu> there are sanity checks on the node response to detect it is not sending bogus data to obtain information about the real spend.
22:37:35 <m-relay> <s​pirobel:kernal.eu> retrying with a malicious node could lead to the real spend getting revealed. Thats why oversampling happens.
22:40:03 <m-relay> <s​pirobel:kernal.eu> question is if its worth it to adapt this as we move to fcmp. is it a problem or only an inconvenience?
23:59:45 <m-relay> <o​frnxmr:xmr.mx> My observations were using fcmp