07:58:41 <0xfffc> https://www.modular.com/blog/how-to-beat-unsloth-s-cuda-kernel-using-mojo-with-zero-gpu-experience 16:56:18 can someone explain the best way to prevent this attack on monero multisig? what i'm thinking of is since the multisig tx can fail according to the docs https://docs.getmonero.org/multisignature/, it's possible for 2 users to collude to duplicate a transaction without the consent of the others. assume we have a 4/5 multisig, a [... too long, see https://mrelay.p2pool.observer/e/tZ_V4NwKQ0dHWUha ] 16:56:18 * the first signer crafts a tx sending coins out to a recipient 16:56:18 * signers 2 and 3 sign 16:56:18 * signer 4 signs but doesn't broadcast[... more lines follow, see https://mrelay.p2pool.observer/e/tZ_V4NwKQ0dHWUha ] 17:26:39 @kiersten5821:matrix.org: You can't really prevent this cryptographically, just like you can't prevent someone with a normal wallet from signing an input twice. Bitcoin still has this problem, but if the wallet uses OP_CHECKMULTISIG and if the 2nd tx is revealed, you can see which signers double signed 17:27:09 If the Bitcoin multisig wallet uses a Schorr key splitting scheme like Monero (e.g. OP_CHECKSIGADD), then that wallet has the same issue 17:27:47 The best you can do is in your multisig protocol, make signers commit to signing and returning a message within a specified timeframe, then punish them if they don't 17:28:05 @jeffro256: yes, i mean, for me it's acceptable if the multisig participants can just inspect the inputs, and avoid the second tx because it's spending different inputs. but i can't figure out how to do that. i'm pretty sure bitcoin wallet software allows you to inspect the inputs very easily 17:28:14 There's isn't a wallet2-native way to do this 17:29:24 @kiersten5821:matrix.org: But that opens up a new vector where the malicious signer says that they're gonna sign an input each time, then don't, but everyone else marks it as spent, so all the funds become unaccessible 17:29:30 really? there's no way to check what inputs are being spent? how can that be, shouldn't the information be there? 17:30:51 @kiersten5821:matrix.org: You can always check which inputs are being spent using the key image. You can check which multisig signers are signing during the construction of the tx. But after the tx is fully signed, you can't tell which signers signed to construct thattx 17:31:50 @jeffro256: I'm saying that if you choose different inputs each construction attempt, I can make you go through all your inputs by refusing to sign them, and now the honest signers are hosed 17:34:32 i'm confused, the point is that by inspecting the inputs, we don't sign transactions with different inputs for the same intended withdrawal? so no honest user should ever be choosing different inputs each construction attempt 17:37:15 and if a potentially malicious tx with different inputs is detected, then the agreed upon action would be to churn the whole balance to be sure there's no potential saved tx 17:39:51 @jeffro256: how can i get this info programmatically? i can't tell how to see this anywhere. it's not showing in describe_transfer 17:42:26 @kiersten5821:matrix.org: This works if you get at least N-M-1 other participants to agree to it, otherwise a different subset of participants which didn't hear about this version of a transaction would like to create another transaction, and they won't hear your new (to them) version of this transaction spending these inputs 17:42:49 Maybe I'm misunderstanding your described scheme 17:43:39 @kiersten5821:matrix.org: How can you know that the guy isn't going to do the exact same thing while trying to churn the balance? 17:44:05 because the churn goes to an address controlled by the multisig so it can't result in any loss 17:45:35 @kiersten5821:matrix.org: You're looking for key image information, right? 17:45:42 Or spend inputs ig 17:45:52 > <@jeffro256> This works if you get at least N-M-1 other participants to agree to it, otherwise a different subset of participants which didn't hear about this version of a transaction would like to create another transaction, and they won't hear your new (to them) version of this transaction spending these inputs 17:45:52 my scheme involves deterministically selecting one of the signers to be the creator of the tx and then broadcasting it in a way that it's visible to everyone, so there's no way for them to be "isolated" 17:45:57 yeah i just want to be able to figure out what inputs are being spent 17:46:08 and figuring out who has signed so far is also helpful but not strictly necessary 17:47:34 You have the same problem: a signer can double spend the input. I'm confused: what outcome are you actually trying to prevent? It sounds like you don't want to lose funds. A malicious double signing participant can't make you lose funds anyways, how would they do this? > <@kiersten5821:matrix.org> because the churn goes to an address controlled by the multisig so it can't result in any loss 17:51:50 Would the situation be different if Serai's FROST multisig were used? 17:51:55 @jeffro256: there are two malicious participants... was my first example poorly written? 17:51:55 you have inputs A B C 17:51:55 "we need to make a withdrawal to address X (controlled by the malicious participants)" 17:51:55 malicious participant 1 crafts withdrawal with input A 17:51:55 2 and 3 sign[... more lines follow, see https://mrelay.p2pool.observer/e/-rmh4twKcXdNbmow ] 17:53:16 Oh I think I see what you're saying. Let's say TX A goes to dest A, TX B goes to dest B. Almost all signers sign for TX A to dest A, except the last guy. The last guy can sign and not broadcast. Everyone else decides to fund dest A using different inputs in TX C, and then use the previous inputs for TX B to dest B. Last guy br [... too long, see https://mrelay.p2pool.observer/e/rbWm4twKV1N2YUR3 ] 17:54:35 Yeah you have to "reserve" inputs to transaction intents until they are confirmed spent on-chain 17:54:56 yes pretty much, although you can drop TX B from your example and it would work fine 17:55:16 yeah, how do i reserve the inputs? 17:56:14 @rucknium: Eh, not really AFAIK 17:56:46 @kiersten5821:matrix.org: You're going to have to code that 17:57:34 that's why i'm asking here to try and figure out how to find which inputs a multisig tx spends, and which signers have signed so far 17:58:07 You might want to look at Serai's code, since they do a LOT of multisig coordination over >100 participants 17:58:29 But yeah I think that it would be good to put the spent input in describe_transfer 18:00:27 Offtopic: i think describe_transfer is another rpc method that is unavailable for restricted rpc 18:01:50 so there's no "easy" way to just call a method and find this info? i'll try to look at serai and look into how to actually decompose the tx, was hoping it wouldn't be that hard 18:02:16 a bandaid could be if any attempt fails then always churn, that's annoying though 18:03:16 @kiersten5821:matrix.org: Not with the current monero-wallet-rpc AFAIK 18:03:32 Serai uses the monero-oxide rust wallet 18:04:10 I could open a PR rn for that 18:05:24 open a pr? are you saying it won't take very long? 18:23:01 your concerns are right, this should really be orthogonal to the scaling topic. > <@articmine> How much larger is this block than the short term median MS? 18:23:59 just read the comment by boog. that is progress in the right direction to make it concrete and fix this potential protocol bug and move on 18:47:02 @kiersten5821:matrix.org: https://github.com/monero-project/monero/pull/10281 20:58:19 @jeffro256: awesome, thanks. super helpful, will see if i can figure out how to integrate this now before waiting for the next release. is getting the list of people who signed it similarly not too big of a change? no big deal if it's too hard