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?

Alex|LocalMonero: it is the post-kex verification round

docs might be out of date

UkoeHB: so it's essential?

yes

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

but you need to really understand your security model to use that, be careful

UkoeHB: Basically, if you don't do that round then a malicious actor might steal your coins?

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

with N-of-N it's less of a concern since there is no 'subset of honest users'

So what's the concern?

In the 2/2 case

hmm can't think of anything off the top, will think more and get back to you

<UkoeHB> "hmm can't think of anything..." <- Appreciated

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

UkoeHB: I see, so the step really isn't needed.

The cli wallet should remove that message if it detects a n/n wallet.

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

I disagree

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.

would be nice if more people could contribute to gitian builds github.com/monero-project/gitian.sigs/pulls

Sign me up. 🙂 Sounds like a weekend thing.

binaryFate github.com/monero-project/gitian.sigs/pulls?q=is%3Apr+is%3Aclosed - 6 people already have merged PRs there

2 of them with failing checks though, but it's probably something on their side

doh, thanks sech1, I missed the merged ones

is my node acting up, or is it some kind of attack? paste.debian.net/hidden/af9d8b36

all addresses belong to lionlink.net

the same IPs get blocked/unblocked on my second node too

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

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

no, load average: 0.02, 0.09, 0.09

162.218.65.0/24, 91.198.115.0/24, 209.222.252.0/24

I'll just block them in iptables

Fork Networking again

I have seen tons of nodes with their IP in the past, running sketchy nodes

e.g. sending too large peer list

sech1: monero-project/monero #8520#issuecomment-1303757193

same IP as here, they are doing some kind of network surveillance, if you block one IP they connect from the next one

seems they had something misconfigured which causes all their IPs to get exposed

(and blocked)

Something like badcaca attack? Time to update DNS blocklist?

I blocked them on my nodes but yes would make sense to also update the DNS blocklist

moneromooo has to decide if banning the whole /24 is too much, though it seems they own almost every IP in the subnet

if you check my paste, it's literally every IP in those three /24 ranges

I'm fine with the 24s. If anyone complains, we can see. And probably laugh at them since they'll likely be the assholes.

Ah. I found the script that updates the list.

hope there is enough space to add 162.218.65.0/24, 91.198.115.0/24, 209.222.252.0/24

Added.

Those ips are part of the weird ip ranges that I reported about a month ago