00:44:48 <Alex|LocalMonero> Is it a bug that when setting up a 2/2 multisig wallet after doing `make_multisig 2 <the other guy's prepare_multisig output>` monero-wallet-cli says "Another step is needed" and tells you to also do a round of exchange_multisig_keys, despite the documentation says that this step is only necessary for M/N (not N/N) wallets?
00:50:28 <UkoeHB> Alex|LocalMonero: it is the post-kex verification round
00:50:33 <UkoeHB> docs might be out of date
00:51:15 <Alex|LocalMonero> UkoeHB: so it's essential?
00:51:32 <UkoeHB> yes
00:52:16 <UkoeHB> essential to the baseline security model, there are cases where it's fine to skip the post-kex round by using the force update option
00:52:40 <UkoeHB> but you need to really understand your security model to use that, be careful
00:54:15 <Alex|LocalMonero> UkoeHB: Basically, if you don't do that round then a malicious actor might steal your coins?
00:55:39 <UkoeHB> no, the most that can happen is there isn't a full set of N honest participants with completed multisig accounts, so funds sent to your local completed account are effectively inaccessible
00:56:00 <UkoeHB> with N-of-N it's less of a concern since there is no 'subset of honest users'
00:56:23 <Alex|LocalMonero> So what's the concern?
00:56:47 <Alex|LocalMonero> In the 2/2 case
00:58:08 <UkoeHB> hmm can't think of anything off the top, will think more and get back to you
01:04:37 <Alex|LocalMonero> <UkoeHB> "hmm can't think of anything..." <- Appreciated
01:56:30 <UkoeHB> Alex|LocalMonero: all I could think of was the post-kex round could act as a heartbeat test on the other party in a 2-of-2 if you obtained a potentially very old pubkey from them
01:57:00 <Alex|LocalMonero> UkoeHB: I see, so the step really isn't needed.
01:58:32 <Alex|LocalMonero> The cli wallet should remove that message if it detects a n/n wallet.
01:59:09 <UkoeHB> if you need a heartbeat test (a test that A) the other party is alive, B) they still have the privkey of their published multisig starter key), then you need it
01:59:21 <UkoeHB> I disagree
02:01:17 <UkoeHB> Including the post-kex round ensures the setup ceremony is an interactive protocol even in a 2-of-2. It's a property that may be important for some users.
09:13:30 <binaryFate> would be nice if more people could contribute to gitian builds https://github.com/monero-project/gitian.sigs/pulls
09:16:53 <kgsphinx[m]> Sign me up.  🙂 Sounds like a weekend thing.
09:18:17 <sech1> binaryFate https://github.com/monero-project/gitian.sigs/pulls?q=is%3Apr+is%3Aclosed - 6 people already have merged PRs there
09:18:28 <sech1> 2 of them with failing checks though, but it's probably something on their side
09:20:58 <binaryFate> doh, thanks sech1, I missed the merged ones
15:37:08 <sech1> is my node acting up, or is it some kind of attack? https://paste.debian.net/hidden/af9d8b36/
15:39:04 <sech1> all addresses belong to lionlink.net
15:40:06 <sech1> the same IPs get blocked/unblocked on my second node too
15:40:10 <moneromooo> Seems like an asshole trying to do things and probably failing. Is your CPU or I/O going through the roof while banning them (if you still are) ?
15:40:52 <moneromooo> If yes, it might be the intent. You can manually man a subnet for longer than 24 hours (might take honest nodes with it though).
15:40:57 <sech1> no, load average: 0.02, 0.09, 0.09
15:41:39 <sech1> 162.218.65.0/24, 91.198.115.0/24, 209.222.252.0/24
15:41:45 <sech1> I'll just block them in iptables
17:14:06 <selsta> Fork Networking again
17:14:24 <selsta> I have seen tons of nodes with their IP in the past, running sketchy nodes
17:15:20 <selsta> e.g. sending too large peer list
17:31:51 <selsta> sech1: https://github.com/monero-project/monero/issues/8520#issuecomment-1303757193
17:32:14 <selsta> same IP as here, they are doing some kind of network surveillance, if you block one IP they connect from the next one
17:32:23 <selsta> seems they had something misconfigured which causes all their IPs to get exposed
17:32:29 <selsta> (and blocked)
17:36:30 <sech1> Something like badcaca attack? Time to update DNS blocklist?
17:44:35 <selsta> I blocked them on my nodes but yes would make sense to also update the DNS blocklist
17:45:26 <selsta> moneromooo has to decide if banning the whole /24 is too much, though it seems they own almost every IP in the subnet
17:49:14 * moneromooo feels pinged
17:49:46 <sech1> if you check my paste, it's literally every IP in those three /24 ranges
17:49:47 <moneromooo> I'm fine with the 24s. If anyone complains, we can see. And probably laugh at them since they'll likely be the assholes.
17:55:23 <moneromooo> Ah. I found the script that updates the list.
17:56:22 <selsta> hope there is enough space to add 162.218.65.0/24, 91.198.115.0/24, 209.222.252.0/24
18:06:40 <moneromooo> Added.
19:46:47 <merope> Those ips are part of the weird ip ranges that I reported about a month ago