<e​dge7:matrix.org> Anyone for the above? 🙏

<r​ucknium:monero.social> edge7: Did you read this? reddit.com/r/Monero/comments/12kv5m…acy_impact_of_mordinals_monero_nfts

<o​frnxmr:monero.social> The problem with your question is xyproblem.info

<o​frnxmr:monero.social> Youll need to reword it if you want a proper response

<e​dge7:matrix.org> I read now the article posted by Rucknium and also this:

<e​dge7:matrix.org> medium.com/@JEhrenhofer/lets-stop-using-coinbase-outputs-da672ca75d43

<e​dge7:matrix.org> Which is still by Justin.

<e​dge7:matrix.org> I think I got the point that if a user selects coinbase transactions as decoy it is easy to say those are decoys. I think Justin is pointing out a different problem, which is about excluding decoys from a public pool transactions in particular circumstances

<e​dge7:matrix.org> I am quoting from the medium article posted above :

<e​dge7:matrix.org> For instance, suppose a pool mines block A and receives its associated coinbase output, value 1 XMR. It then pays out 0.5 XMR to one miner. The pool creates a transaction with two outputs, each for 0.5 XMR. The pool receives this change output, and it publishes this payout transaction for others to see.

<e​dge7:matrix.org> Initially, users do not know which of the outputs is a change output. However, if a pool later creates a transaction spending it, then users know that the output was spent in that transaction. It could not have been spent in any others where it is used as a decoy. We need to prevent this from happening.

<r​ucknium:monero.social> edge7: Here's more. Check the references at the bottom, too: monero-project/research-lab #109

<e​dge7:matrix.org> Thanks.

<e​dge7:matrix.org> But am wrong or Justin is pointing to a different problem? The possibility to mark outputs from mining pool as real spend which then will reduce the real ring size of any other transactions that include that output ad decoy?

<e​dge7:matrix.org> Thanks.

<e​dge7:matrix.org> But am wrong or Justin is pointing to a different problem? The possibility to mark outputs from mining pool as real spend which then will reduce the real ring size of any other transactions that include that output as decoy?

<e​ndor00:matrix.org> But how do you *actually* know that output was spent in that second transaction?

<e​ndor00:matrix.org> Don't forget that it will still be part of a ring

<e​dge7:matrix.org> endor00: in the video it is explained a bit better. Skip to around 11 minute

<s​gp:magicgrants.org> The problem is how mining pools publicly reveal information which is enough to deduce real spends and change

<e​dge7:matrix.org> Hi Justin as you are around, could you elaborate a bit more also considering the last 3/4 messages? That would be highly appreciated, cheers

<s​gp:magicgrants.org> Sorry, idk if it's just been a long day for me so it's hard to focus, but it's hard for me to really provide a direct answer :/

<s​gp:magicgrants.org> matrix.monero.social/_matrix/media/…f7fd6d03f83076bd7e2380d39c3ae7d05cf

<s​gp:magicgrants.org> here's a presentation I made for MRL back in 2018, maybe it'll help. It's a deck that showcases a bunch of mitigation options, as well as various pros and cons

<s​gp:magicgrants.org> fwiw, this probably isn't easy reading. It was made for a very specific context in time :)

<s​gp:magicgrants.org> it wasn't polished like the breaking monero episode

<s​gp:magicgrants.org> It might be helpful to approach coinbase outputs and non-coinbase outputs held by pools differently

<s​gp:magicgrants.org> slides 11-15 are probably the most important

<e​dge7:matrix.org> My only doubt is that in that episode you are pointing to a different problem than just coin base transaction. But focusing on the fact that a further transaction from the pool could reveal the real output that then can be excluded from a ring size done by ANY user in the future. And if this happens frequently the ring size decreases indirectly

<s​gp:magicgrants.org> sides 11-15 walk through a possible mitigation for pools' subsequent histories

<s​gp:magicgrants.org> I found it was important to build a web of pool transaction outputs, coinbase and not, to see which outputs could be highly associated with the pool based on certain activities. Then, I played around with different activities to see what protected the pool miners and other unaffiliated users the most

<s​gp:magicgrants.org> If you have more specific questions or if I knew what you needed help with, that would help me better answer your question

<e​dge7:matrix.org> I am just looking for some take aways. I have 2 for now :

<e​dge7:matrix.org> 1) coinbase transactions reduce the ring size for a normal user as they usually belong to pools. This is clear.

<e​dge7:matrix.org> 2) certain edge cases (as shown in the episode of breaking monero) can show the real output used by a pool. This is true as all the pools outputs are known so if in the ring size just one is considered as not being a pool output that is likely a change output and one can mark it as real. So if in any future (by any user) one sees that output the ring size is automatically decreased by one

<e​dge7:matrix.org> I just need to be sure the 2nd point is correct. 🫠😵‍💫

<e​dge7:matrix.org> I am just looking for some take aways. I have 2 for now :

<e​dge7:matrix.org> 1) coinbase transactions reduce the ring size for a normal user as they usually belong to pools. This is clear.

<e​dge7:matrix.org> 2) certain edge cases (as shown in the episode of breaking monero) can show the real output used by a pool. This is true as all the pools outputs are known so if in the ring size just one is considered as not being a pool output that is likely a change output and one can mark it as the real output for this transaction . So if in future (by any user) one sees that same output the<clipped message>

<e​dge7:matrix.org> ring size is automatically decreased by one.