<k​eepemup:matrix.org> What are the odds that a decoy ring member will show up twice in one transaction with many inputs?

<k​eepemup:matrix.org> What are the odds that the same decoy ring member will show up twice in one transaction that has many inputs?

<k​eepemup:matrix.org> What are the odds that the same decoy ring member will show up twice in one transaction that has many inputs?

<k​eepemup:matrix.org> Edit: not twice in the same input but twice across different inputs of the same transaction

<r​brunner7:monero.social> You know, those solutions to make Monero multisig easy, fast, and comfortable, it's no problem at all to come up with ideas how to do it. Ideas are not the problem, ideas are worth only a dime a dozen. Execution is the problem.

<r​brunner7:monero.social> Example: What the MMS currently uses, passing messages around using the Bitmessage protocol, is near ideal. Too bad that the only viable implementation to use, PyBitmessage, is old code that barely moves forward.

<r​brunner7:monero.social> Solution is trivial: Monero writes its own Bitmessage protocol implementation.

<r​brunner7:monero.social> Any takers? No? Thought so :)

<r​brunner7:monero.social> So if a competent dev now takes up the challenge, a dev that has shown that they are in it for the long run and do not shy away from improving something and improving yet again if it's not really good yet, a dev that is furthermore respected in the community, sets out to implement a self-hostable message passing daemon as a solution for easy Monero multisig, well, that's **really*<clipped messag

<r​brunner7:monero.social> * good news. I wish them luck. If they ever need a sparring partner to brainstorm or discuss details, I am ready to do my best to support.

<a​js_:matrix.org> couldn't the messaging system used in Townforge be used for multisig data exchange?

<r​brunner7:monero.social> As far as I know Townforge simply writes the messages into the blockchain, where they stay forever, and of course contribute to blockchain growth. I guess that's perfectly ok for *Townforge*. We could do something like that, using the well-known `tx_extra` mechanism: For once not NFTs on the Monero blockchain like with those "Mordinals", but multisig messages on the Monero blockch<clipped messag

<r​brunner7:monero.social> ain. Less than ideal, IMHO, for several reasons.

<a​js_:matrix.org> oh i thought it was an odd formed tx than remains in mempool only than drops off

<a​js_:matrix.org> oh i thought it was an odd formed tx that remains in mempool only than drops off

<a​js_:matrix.org> oh i thought it was an odd formed tx that remains in mempool only then drops off

<a​js_:matrix.org> moneromoooo: ^

<r​brunner7:monero.social> Possible, but if yes I would be very interested to hear how DoS attacks are prevented: What prevents me from flooding the mempool with millions of such messages? Maybe they drop off so quickly that this can hardly be successful, but messages that drop off really quickly would probably not fly for multisig. This would more or less lead to a requirement "Signers must be online at th<clipped messag

<r​brunner7:monero.social> e same time" which probably would lead to a terribly UX.

<r​brunner7:monero.social> I have literally spent days thinking things like that through when I designed the MMS ... maybe the genius idea that solves all escaped me despite that, however :)

The TF *chat* system uses unmined txes that get flushed from the txpool after a couple weeks. The hidden PM system uses mined txes. Chat is publicly visible (but could easily have payload that's encrypted to one or more people).

TF has a new player fee to mitigate spam, which cannot be applied to monero.

However, one could have a separate "special multisig txes" size limit in the txpool to further mitigate spam.

A node may also drop any such tx that's not for them (this would require wallet help though, like the wallet tells hte node "you can drop all of those" from time to time).

<r​brunner7:monero.social> You mean an overall limit of all multisig messages? Like, "No more than 1 GB of multisig messages in the mempool at any time"? Then it would probably be trivial for a malicious person to deny service to all other people by simply filling that 1 GB, no?

If a node is instead given an id to look for, which identifies the MS wallet we're interested in, the daemon could just relay specla ms txes that aren't for them, and only store ones that are. This would be as bad spam wise as any other tx.

Yes, if not the last line above.

For privacy I imagine the id could be something derived from a secret known to every MS participant and the current quantized time. Similar to OTP.

Actually, something about the TF chat system may apply o monero: a chat tx has a fee attached, despite being unineable.

This is hard to tune, but if the fee is set to, eg, 0.01 monero, it means one single person cannot spam millons of messages until their previous MS setup messages are flushed from the txpool of whoever receives the new tx.

Maybe it is actually reasonable to restrict use of such an on-chain system to people with >= 0.1 monero, so the temporary fee can be set high enough.

I'm lost. How does Rino offer a multisig wallet if the current monero multisig stuff is experimental?

<j​ohn_r365:monero.social> gingeropolous - I'm bound to get this wrong, but as always I'd imagine kayabanerve will correct me (!). As I understand it one of the core parts that needs security proofs and further audit is the key (shard?) generation process. Meaning there's non-zero risk that a private key could be reconstructed from less shards than meet the specified threshold. Perhaps even just one.

<j​ohn_r365:monero.social> Rino doesn't share shards between multiple parties, only the account creator and Rino themselves have access to multisig shards. Rino *have* to trust themselves (lol) and they have to trust the user, who holds an encrypted shard + a recovery shard (I think). So the risk of a malicious third actor isn't present.

<j​ohn_r365:monero.social> Additionally, they're also trusting the audit they paid inference to carry out: community.rino.io/rino-multisig-pr8194-audit-20220627.pdf

<j​ohn_r365:monero.social> *Edit, sorry, Rino holds 2 keys - 1 of which is encrypted by the user's login password. Then the user holds just 1; the recovery key

<a​js_:matrix.org> Rino holds 1 key

<a​js_:matrix.org> 2nd key and the recovery key is held by the user

<j​ohn_r365:monero.social> ok! thanks for the correction

<j​ohn_r365:monero.social> Actually, from their site: "For day to day usage, we keep an encrypted version of your user key. Your User Key stays with us - but…. in encrypted form - we have no way of decrypting it. When you use our service, we send you the encrypted User Key, and it gets decrypted locally in your browser."

<j​ohn_r365:monero.social> so, the user has its user key + spare key on the recovery document that needs storing safely.

<j​ohn_r365:monero.social> However, Rino has their key (unencrypted) + your user key (encrypted)

<j​ohn_r365:monero.social> matrix.monero.social/_matrix/media/…ero.social/AvsEbIEYqaEJfNWtgNvXwJiU

<j​ohn_r365:monero.social> rino.io/faq#multisig

<j​ohn_r365:monero.social> well, Rino might be storing their key for your wallet in an encrypted format, but what I mean is that they *are* able to decrypt it at will. Whereas with the copy of your key they hold, they don't store the decryption password.

"gets decrypted locally in your browser" D:

<a​js_:matrix.org> john_r365: user key and recovery key are generated client side, the RINO server does not have access to them. The user key is then encrypted using the user password, RINO also does not know the user password. RINO stores the encrypted blob + their key to the set up.

<k​ayabanerve:matrix.org> gingeropolous: By using the experimental feature

<k​ayabanerve:matrix.org> john_r365: There's always a non-zero risk of bad stuff. With Monero, we don't believe the risk is sufficiently low one cannot compromise the DKG process/signing process. There's no concern about recovering a key from less shares than intended though (as literally written). There's a concern around stuff like generation of shares.

<j​ohn_r365:monero.social> Thanks kayabanerve

<k​ayabanerve:matrix.org> Happy to :)

<r​ucknium:monero.social> keepemup: The probability is very low. Are you still going to be interested in this question next week? I could develop a calculation by then. The question is related to some things I was doing to analyze PocketChange.

<r​ucknium:monero.social> And why are you interested in this question?