13:36:36 <gingeropolous> so all of these "back ping connect failed to xxx.xxx.xxx.xxx" are indicative of other peers not being updated to new release? or swaths of malicious nodes?
13:39:19 <gingeropolous> well, "unhealthy nodes"
13:41:04 <moneromooo> Typically it means those do not accept incoming connections.
13:42:27 <gingeropolous> ah. thank you
19:12:29 <Alex|LocalMonero> Do multisig wallets check the key images that are exported from other members to ensure that they're legit? Could a malicious actor send you junk key images that would lead your multisig wallet to have improper state? Would a malicious attacker be able to keep sending you junk key images to bloat your wallet with bad data?
19:24:31 <moneromooo> If another multisig participant sends you data that causes you to generate wrong key images, your tx will be rejected.
19:24:47 <moneromooo> If they do, what difference does it make compared to someone not sending you data anyway?
19:25:18 <moneromooo> Extra time importing I guess. But worry not, you will not pay epsilon extra in fees.
19:26:03 <moneromooo> I am not sure whether you can tell *who* sent you bad data however, if you're in a N/M with M >= 3.
19:27:05 <UkoeHB> Alex|LocalMonero: the current impl cannot detect bad key images until you make an invalid tx
19:29:01 <UkoeHB> the seraphis lib has robust legacy multisig key image recovery that could theoretically be used in wallet2 https://github.com/UkoeHB/monero/blob/675435314eb21a677e720c8fddd4681a20f6c408/tests/unit_tests/multisig.cpp#L305
19:29:45 <Alex|LocalMonero> moneromooo: UkoeHB the multisig wallet that RINO.io sets up for you where they hold one key and you hold the other key requires key images to be synced between the client and backend server. I'm thinking of a theoretical DoS vector where a malicious actor would spam the export/import key images API endpoint of the service with junk outputs to bloat the backend wallet to terabytes. Is this a realistic vector?
19:30:25 <UkoeHB> hm I'm not actually sure
19:30:34 <UkoeHB> possibly
19:33:42 <moneromooo> What kind of spam do you have in mind ?
19:33:54 <moneromooo> If it's wallet cache space, old data gets replaced.
19:34:15 <moneromooo> If it's bandwidth, it's not the wallet's purview really.
19:34:17 <Alex|LocalMonero> Just keep posting bad key images over and over.
19:35:12 <moneromooo> If you post bad key images over and over, the other side will never be able to send txes. But it's kinda "duh, of course", no ?
19:35:34 <Alex|LocalMonero> If the backend has no way to tell if the key images are bad or not then it's forced to store them regardless, and an attacker can bloat the backend database with terabytes of junk over time.
19:36:06 <Alex|LocalMonero> So, a counter to that vector would be to try to generate a tx for the full wallet balance without broadcasting, right?
19:36:06 <moneromooo> <+moneromooo> If it's wallet cache space, old data gets replaced.
19:36:23 <moneromooo> You'd have to double check to be 100% sure though. Just in case.
19:36:47 <moneromooo> You'd have to broadcast, unless you wnat to add tx verification ability to the wallet.
19:36:50 <UkoeHB> Alex|LocalMonero: looking at the import_multisig() function it looks like it clamps the input data to the number of outputs your multisig owns. Then it just overwrites any preexisting data
19:36:54 <Alex|LocalMonero> Are unspent key images considered old data that gets replaced?
19:37:11 <Alex|LocalMonero> UkoeHB: Ah, that's great. That would prevent this vector.
19:37:46 <UkoeHB> however the endpoint itself may be overloaded to cause memory access error idk
19:38:07 <UkoeHB> does RPC restrict max payload size?
19:40:04 <UkoeHB> Alex|LocalMonero: Are unspent key images considered old data that gets replaced? -> yes it seems to overwrite everything