11:01:05 <dEBRUYNE> Any additional tips here? https://www.reddit.com/r/monerosupport/comments/j2hl1n/what_do_i_look_for_in_the_log_file_to_find_if_my/
11:21:25 <moneromooo> There's no check a tx relay was successful. But if you add net.p2p.msg to the log categories (log level 1 is enough to include it), you should see when a tx is relayed to a peer.
12:04:55 <dEBRUYNE> ty
14:23:08 <fluffypony> https://github.blog/2020-09-30-code-scanning-is-now-available/
14:45:28 <selsta> I tested this yesterday, only monero related warnings are `Multiplication result may overflow 'int' before it is converted to 'unsigned long'.` a couple times
14:49:00 <selsta> so most likely not worth it to activate for monero
14:49:39 <selsta> if anyone wants to test it, they have to push this file to the repo: https://github.com/selsta/monero/blob/master/.github/workflows/codeql-analysis.yml
14:49:40 <moneromooo> Where ?
14:49:59 <moneromooo> And if it is not spammy, it's probably worth having.
14:50:30 <selsta> src/wallet/wallet2.cpp#L852 src/wallet/wallet2.cpp#L850 src/wallet/wallet2.cpp#L824 src/wallet/wallet2.cpp#L875
14:50:38 <moneromooo> ty
14:51:47 <moneromooo> We don't care about those indeed.
14:52:25 <moneromooo> Would it spam about those for every PR ?
14:52:43 <selsta> I don’t know yet, I think it would only display warnings for new code
14:55:34 <selsta> we can enable it and disable it again if it is annoying
14:55:56 <xiphon> ^ or just fix three lines
14:56:42 <selsta> there are 30 results overall but most are in external libraries or it complains about "localtime" or "gmtime"
14:57:27 <xiphon> gotcha
14:59:00 <selsta> will have to read the docs a bit more, apparently you can customize what kind of warnings you want
14:59:35 <moneromooo> Would be nice to have a monero coverity account again. It found actual bugs, occasionally.
15:04:09 <selsta> I can create one, or should core team do this?
15:16:26 <moneromooo> Core team would be better. If you go bye bye, we'll still have it.
15:18:24 <selsta> I can create one and then give instructions to luigi :P
15:18:30 <selsta> for creating a core one
15:24:00 <gingeropolous> does the daemon challenge a potential peer? like, ask for some random old block?
15:24:19 <gingeropolous> im thinking of those nodes out there that just repeat the max height value
15:26:26 <moneromooo> No.
15:27:25 <gingeropolous> though i guess it eventually drops the peer if it doesn't prove any useful data
15:27:40 <moneromooo> That seems like a good idea offhand, but I don't recall why this wasn't done before.
15:28:07 <gingeropolous> i mean, its some bandwidth and processing overhead
15:28:17 <moneromooo> Ah, because it's mostly annoying for new people who want to sync, and those don't have history, I think.
15:28:23 <moneromooo> So still a good idea.
15:28:42 <gingeropolous> yeah, if your a fresh sync, its not gonna help yah
15:28:51 <moneromooo> Unless someone can think of a drawback (bandwidth/processing is really not much hre, we'd ask for a tx)
15:29:05 <xiphon> why not just drop a useless peer?
15:29:07 <gingeropolous> but there should be a way to tie in checkpoints? well an attacker could incorporate the checkpoints
15:29:20 <moneromooo> Because you might not be useless to it.
15:29:42 <moneromooo> You could drop on a timer if it's useless to you and hasn't requested some data in a couple minutes.
15:29:49 <moneromooo> I had a patch for this IIRC.
15:30:27 <xiphon> yep, that looks better than challenging it
15:30:38 <gingeropolous> i mean, so whats the flow. My node: "hi, what height are you, im looking to sync. I have x block height. What is your blockheight?"
15:31:05 <moneromooo> Except if it's not well tuned, you might end up dropping slow peers.
15:33:34 <xiphon> ^ yep, even if we'll use 30m timeout, we'll eventually drop the *bad guys*
15:34:35 <xiphon> huh and the next iteration will be like: bad guys periodically request some data from us
15:39:56 <gingeropolous> attacker peer: "i have x block height too! You should connect"
15:40:06 <gingeropolous> my peer connects, doesn't get any new data.
15:41:18 <gingeropolous> and now this attacker peer is effectively sybilling me cause it costs them nothing to prop up these mirrors
15:47:42 <xiphon> i see no way to completely mitigate sybilling atm
15:50:13 <xiphon> on the other hand some heuristic could definitely be added
15:50:53 <xiphon> for example, if the peer reports X height and requests block at < X height, that's is not okay
18:33:29 <gingeropolous> well the peer wouldn't request a block at x height.
18:34:38 <gingeropolous> xiphon, yeah, you can't completely mitigate sybilling with a permissionless network, but you can make it costly
18:37:02 <gingeropolous> i wonder if you could packet-ize data transfer between p2p. because evne if there's some heuristic or blockchain checking, a peer could just request that info from an honest peer
18:37:58 <gingeropolous> however, if you make it so the monero p2p protocol only sends data in chunks of n Mb, it will again make the bad peer use more resources... but also the resources of the honest peer its leeching from.... but still
23:33:59 <Snipa> .merges
23:33:59 <xmr-pr> Merge queue empty
23:37:28 <selsta> if you are bored gui always has merges :P
23:38:08 <Snipa> Yeah, I saw, that's why I was checking.