<0xfffc> modular.com/blog/how-to-beat-unslot…using-mojo-with-zero-gpu-experience

<kiersten5821:matrix.org> 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 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 mrelay.p2pool.observer/e/tZ_V4NwKQ0dHWUha ]

<kiersten5821:matrix.org> * the first signer crafts a tx sending coins out to a recipient

<kiersten5821:matrix.org> * signers 2 and 3 sign

<kiersten5821:matrix.org> * signer 4 signs but doesn't broadcast[... more lines follow, see mrelay.p2pool.observer/e/tZ_V4NwKQ0dHWUha ]

<jeffro256> @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

<jeffro256> If the Bitcoin multisig wallet uses a Schorr key splitting scheme like Monero (e.g. OP_CHECKSIGADD), then that wallet has the same issue

<jeffro256> 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

<kiersten5821:matrix.org> @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

<jeffro256> There's isn't a wallet2-native way to do this

<jeffro256> @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

<kiersten5821:matrix.org> really? there's no way to check what inputs are being spent? how can that be, shouldn't the information be there?

<jeffro256> @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

<jeffro256> @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

<kiersten5821:matrix.org> 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

<kiersten5821:matrix.org> 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

<kiersten5821:matrix.org> @jeffro256: how can i get this info programmatically? i can't tell how to see this anywhere. it's not showing in describe_transfer

<jeffro256> @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

<jeffro256> Maybe I'm misunderstanding your described scheme

<jeffro256> @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?

<kiersten5821:matrix.org> because the churn goes to an address controlled by the multisig so it can't result in any loss

<jeffro256> @kiersten5821:matrix.org: You're looking for key image information, right?

<jeffro256> Or spend inputs ig

<kiersten5821:matrix.org> > <@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

<kiersten5821:matrix.org> 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"

<kiersten5821:matrix.org> yeah i just want to be able to figure out what inputs are being spent

<kiersten5821:matrix.org> and figuring out who has signed so far is also helpful but not strictly necessary

<jeffro256> 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

<rucknium> Would the situation be different if Serai's FROST multisig were used?

<kiersten5821:matrix.org> @jeffro256: there are two malicious participants... was my first example poorly written?

<kiersten5821:matrix.org> you have inputs A B C

<kiersten5821:matrix.org> "we need to make a withdrawal to address X (controlled by the malicious participants)"

<kiersten5821:matrix.org> malicious participant 1 crafts withdrawal with input A

<kiersten5821:matrix.org> 2 and 3 sign[... more lines follow, see mrelay.p2pool.observer/e/-rmh4twKcXdNbmow ]

<jeffro256> 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 mrelay.p2pool.observer/e/rbWm4twKV1N2YUR3 ]

<jeffro256> Yeah you have to "reserve" inputs to transaction intents until they are confirmed spent on-chain

<kiersten5821:matrix.org> yes pretty much, although you can drop TX B from your example and it would work fine

<kiersten5821:matrix.org> yeah, how do i reserve the inputs?

<jeffro256> @rucknium: Eh, not really AFAIK

<jeffro256> @kiersten5821:matrix.org: You're going to have to code that

<kiersten5821:matrix.org> 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

<jeffro256> You might want to look at Serai's code, since they do a LOT of multisig coordination over >100 participants

<jeffro256> But yeah I think that it would be good to put the spent input in describe_transfer

<ofrnxmr> Offtopic: i think describe_transfer is another rpc method that is unavailable for restricted rpc

<kiersten5821:matrix.org> 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

<kiersten5821:matrix.org> a bandaid could be if any attempt fails then always churn, that's annoying though

<jeffro256> @kiersten5821:matrix.org: Not with the current monero-wallet-rpc AFAIK

<jeffro256> Serai uses the monero-oxide rust wallet

<jeffro256> I could open a PR rn for that

<kiersten5821:matrix.org> open a pr? are you saying it won't take very long?

<spirobel:kernal.eu> 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?

<spirobel:kernal.eu> 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

<jeffro256> @kiersten5821:matrix.org: monero-project/monero #10281

<kiersten5821:matrix.org> @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