> <@mj-xmr:matrix.org> Before we go on the record, I have to make everybody aware, that there's a parasite looking for a host, after I excreted him. He feels cold and is currently trying to attach to Rucknium and Endor.

> Don't take his comments very seriously. He's just trying to annoy and compromise you. That's what he gets paid for - to hinder Monero's progress.

"github.com/mj-xmr/SolOptXMR/blob/b7…xmr-logo.svg?short_path=114627d#L19" facepalm

<hyc> "why does magnitude of hashrate..." <- It doesn't.

<UkoeHB> "If there is a network problem/..." <- +1, is it your own idea ?

<kayabaNerve> "My frustration is the only way a..." <- +1

<kayabaNerve> "As a side note, while I know..." <- What's the another coin ? Any hints ?

<jeffro256[m]> "And on the other side, accepting..." <- There are examples when such merchants say "we've added 0-conf txs, on the first abuse they will be turned off". It isn't safe.

<UkoeHB> "Ah yeah same person, but..." <- every such meeting is an example of very ineffective way of problem solving since no goal / no critical questions / no focus / no priorities; in the best case it's boring, in the worst case it's a show on purpose

<ooo123ooo1234[m]> "There are examples when such..." <- What abuse ? You can’t unless you do a 51% attack

<nikg83[m]> "What abuse ? You can’t unless..." <- Race condition of mempool with two txs at the same time: 1st one goes to node of exchange, 2nd one goes to everyone else; since node of exchange isn't mining then there is 100% chance that it will be double 0 confirmation spend

It must be low latency broadcast

In btc it was probably just outbidding by fee

ooo123ooo1234[m]: Send me 1xmr with your race condition, I will payback even if it doesn’t confirm

<nikg83[m]> "Send me 1xmr with your race..." <- How can i be sure that you will not cheat in part "I will payback" ?

<ooo123ooo1234[m]> "How can i be sure that you..." <- Send 0.001 , I will send 1 back if you can prove your attack

nikg83[m]: It's broken game, are you joking ?

<nikg83[m]> "Send me 1xmr with your race..." <- Reread what I said and you can test it for free locally with your monerod. No need to pay to anyone.

ooo123ooo1234[m]: Prove the attack on me

891dgWQKn5NEJMyz9hsnDL7udKu4uYRDfMWuCRW5FjPageGKjupdYNCQYjQQNRNA8ze81kSXZw1FeVj4MmLvF3EGPMgsP8x

nikg83[m]: I need address of monerod used by you. In case of exchange it could be found port scanning or some interactive tests

ooo123ooo1234[m]: Why will the vendor give you node addr ?

nikg83[m]: I've explained how to find it asking.

* find it without asking.

* be found via port scanning

ooo123ooo1234[m]: I am a vendor, go scan

nikg83[m]: Vendor with huge volume would have website with domain

ooo123ooo1234[m]: Huge vendor will not expose his backend servers

nikg83[m]: In the worst case It requires few interactive txs

ooo123ooo1234[m]: Want me to send you a fixedfloat or any instant exchanger to test your attack ?

nikg83[m]: fixedfloat doesn't support 0 -conf, there are at least 3 conf

exchange also doesn't use 0 conf

ooo123ooo1234[m]: It will show received and pending verification

nikg83[m]: Yes it could be used for a test. But it wouldn't lead to bounty

Go attack, come back with a video of your race attack on instant exchange

ooo123ooo1234[m]: I will pay you 1 xmr

nikg83[m]: Video isn't a proof

ooo123ooo1234[m]: Bye, don’t pollute this channel anymore

nikg83[m]: ok, but identification of node used by exchanges will take time. And without bounty it isn't interesting.

nikg83[m]: Can we test it with your own node ?

So that step of node ip:port identification skipped ?

Or tell me ip:port of fixedfloat

ooo123ooo1234[m]: A vendor isn’t going to give you details

* of fixedfloat's monerod

<nikg83[m]> "A vendor isn’t going to give you..." <- Then wait until I will find ip:port of some exchange

<ooo123ooo1234[m]> "> <@mj-xmr:matrix.org> Before we..." <- Facepalm what? Did you give up on all fronts and starting to discuss art now? What next? Poetry?

mj-xmr[m]: I thought that enjo and mj-xmr are two different people. Turns out it isn't. And that file leaks it.

I'd say, that doxing on a public channel in a privacy coin is a reason for permanently banning you and all your socks.

mj-xmr[m]: There are 10 such leaked things. It's literally published by you into git. And it's just my guess.

And you think that you should be pointing this out publicly?

Where in Africa were you born exactly?

<mj-xmr[m]> "Every parasite's gotta make a..." <- Did you try to look into mirror ?

ooo123ooo1234[m]: We used to say this when we were ~8 y.o.

This is MRL, kid.

> <@mj-xmr:matrix.org> We used to say this when we were ~8 y.o.

> This is MRL, kid.

or not to say, who do you know ?

* or not to say, how do you know ?

OK. I'm giving up this BS. I won't ignore your account, because it's funny to see how dumb you are, but I hope I won't be tempted to reply to your crap. Beat it, kid.

mj-xmr[m]: Does it include answers to critical questions ? or not yet

<mj-xmr[m]> "OK. I'm giving up this BS. I won..." <- I'm interested in attacking problems, not people.

let's see what the top of this channel reads...............

Casual chats: #monero-research-lounge

Be excellent to each other

nioc: A valid point.

Too bad that it doesn't apply to Reddit and GitLab. I assume that everybody read the link that I posted?

<nioc> "Be excellent to each other" <- It's relevant when hard problems were being attacked on regular basis. Otherwise it's abused for the sake of personal interests

even if it doesn't fix the 10 block lock, i think the ref outs by pubkey (or something other than its temporal order) makes the blockchain /protocol more robust in the event of netsplit and altchain reorgs, right?

oh right. the messy business about block rewards

it's relevant at all times

?

gingeropolous: my comment was not directed at you :)

UkoeHB: Can we solve the burning bug by having shared keys be multiplied by the key image? So instead of Hs(8raG || i)G + B, it's Hs(8rA || ki || i)G + B

I hate to only be suggesting this a few days AFTER code freeze for the next release but I'd think that end this entire class of attacks and prevent wallets from needing to do any processing of it.

Not to mention the L2 solution flow it offers, which I'm currently being frustrated by, and so on.

I think we've discussed before ki[0] is secure, but it's best to do ki as a whole. Regarding light clients, they'd add 32 bytes per scanned TX (if ki[0]), yet they already needed to get R values so I'm not too concerned about that. While different kis could be provided by a malicious server... so could different output keys/Rs. I really don't see this as changing the surface too much. Pinging jberman as well as I know he got

mad at me when I brought up the bandwidth reqs of a merkle tree membership proof :p

*though I also think we worked that out

* I think we've discussed before ki\[0\] is secure, but it's best to do ki as a whole. Regarding light clients, they'd add 32 bytes per scanned TX (if ki\[0\]), yet they already needed to get R values so I'm not too concerned about that. While different kis could be provided by a malicious server... so could different output keys/Rs. I really don't see this as changing the surface too much. Pinging jberman as well as I know

he got mad at me when I brought up the storage reqs of a merkle tree membership proof :p

And from a multisig side of things, my current timing (which is a 2-round protocol for the entire TX) isn't affected which means I don't believe this has any significant impact to TX creation flow in theory. I couldn't comment on the exact wallet 2 internals though.

s/wallet/wallet2/, s/2//

s/be/hash/, s/multiplied by//

s/be/hash/, s/multiplied by//, s/8rA/8raG/

kayabaNerve: no, unless I am misreading you. ki is a function of Hs(...) + B

input ki used for the output shared key

It’s not forward compatible with seraphis to bake that into the normal flow

Not output shared key uses the output ki it won't know because only the receiver would and they're not the receiver, they're the sender, which is derived from the sender's chosen output shared key

Plus there is no clear advantage for non-multisig

While I do understand Seraphis is intended to be incredibly modular, I do believe this is a legitimate problem we should fix and the solution is to have the linkability tag used to derive output keys. If we can fix this now, yet Seraphis wouldn't support the same fix, I'd posit that's an issue with Seraphis, not an issue with this.

There is already a solution that works with seraphis. I’m not understanding the advantage here

... I mean, all wallets need to have this code and it's a pain to implement. It's the straw that broke my camel's back with my own wallet impl and made me decide to no longer have it available.

If Seraphis isn't vulnerable to the burning bug... good. That's how it should be. This is a proposal that isn't for Seraphis.

It looks like a multisig thing. Am I missing something?

Though I do think it's a problem if we fix this outside of Seraphis and then Seraphis re-introduces it.

In that case, yes.

??

This can be used against exchanges. You send 1 XMR to an exchange, get credited 1 XMR, then send 1 unspendable XMR to exchanges.

It forces EVERY wallet on the network to have the complete contextual state for the entire lifetime of the wallet.

Oh that’s what you’re referring to

And it requires processing code to track this and forces wallets to decide which outputs, of potential many, to use.

Yes. I'm discussing fixing this entire class of attack, against all Monero wallets, by including the key image/linkability tag in the shared key used to calculate the output key, thereby forcing output keys to be unique if validly formed.

I lost the context for a bit

It moves context from the entire wallet's lifetime on the network to solely the transaction in front of it, where if the TX in front of it was mined and confirmed without issue, the output keys must be unique if you can decode them as you normally would.

So there is the Seraphis discussion regarding modularity, as this makes outputs determined after linkability which... may break your msg flow?

I'd have to read through Seraphis to comment there and then you may have a solution to burning bugs that isn't linkability tag inclusion in the shared key hash.

But this proposal is immediately for the current Monero, not Seraphis.

the general solution is to always use a randomly generated address

It's really hard for me to endorse single use subaddresses and constantly communicating new adddresses as a solution .-.

And considering this attack is decided by the sender, not the receiver... you either do have enforce single use subaddresses or have extremely contextual code which may not offer a clear path forward.

something like this definitely wouldn't be ready by this hardfork

<kayabanerve[m]> "And from a multisig side of..." <- +1 for deep questions; This discussion with concrete code and it's model would be even more focused. But it's already quite deep for the beginning

Right, yet are we saying Seraphis will definitively be the next hard fork/Seraphis is guaranteed to solve this at a protocol level making this discussion in all forms void?

no? it's just not an urgent question, so it's fine to think about it slowly

I'm not proposing this for today :p

I'm trying to start this conversation

... can Seraphis include linking tags when deriving one time keys? Would you consider that incompatible, or solely not preferable to the point it becomes a cost-benefit analysis?

*TX input linking tags for their one time keys used to derive output keys, to be perfectly clear

Considering we now have view key construction of linking tags... I don't see why that would be an issue at all tbh

Eh. It doesn't work with the flow established in 4.8...

<kayabanerve[m]> This can be used against exchanges. You send 1 XMR to an exchange, get credited 1 XMR, then send 1 unspendable XMR to exchanges. <= This kind of attack is rather costly no?

dEBRUYNE: It's 0 cost. You send 1 unspendable XMR yet get credit for it anyways.

We have a fix for it, which is wallets knowing every single output they've ever received to, and if it detects a second, larger output, it only credits O2 - O1.

Ah right

But that requires fully contextual wallets incapable of scanning individual TXs which makes a few things hell. There's also another angle I'm trying to discuss privately at this time, though it's sufficiently contrived it shouldn't be an issue to dicuss publicly.

s/dicuss/discuss/

kayabanerve[m]: can you make an MRL issue to discuss this?

UkoeHB: Yes, if you first read my PMs to discuss the second stage evolution of this and certify it's sufficiently theoretical it can be disclosed :p

just woke up from a nap gimme a sec

All good :) Thanks for helping

My current conclusion is while this is critical, it's critical for me, not for Monero, and I'm just mad at Monero for forcing me to consider it as critical :p I don't see it as an urgent discussion either, though my life would be easier if I could have Monero consider it critical urgently (making it out of my custom scope)

monero-project/research-lab #103 <- issue about modifying the shared key derivation to prevent the burning bug, regarding higher level protocols today, RCT, and Seraphis.