Buffer Playback...

[16:35:27] Good terminology and UX would go a long way to keep users informed

[16:35:37] e.g. "scan key", "view key", "private key"

[16:35:40] Or something like that

[16:35:46] With giant warnings before showing you those keys

[16:36:39] Maybe use different encoding prefixes or something, to avoid accidental misuse

[17:02:22] but to put it in context UkoeHB , i thought perhaps the seraphis re: assimilation meant assimilating that bitcoin "feature". I may have been thinking too loopily that day

[17:10:25] hmm idk anything about bitcoin so I'm not sure

[17:43:06] well just the ability to observe user activity

[17:54:47] Why is that a Bitcoin feature? Only permissioned individuals (with the view key) can view wallet spends, right? So visibility is very limited and controlled by the wallet owner, which afaik is very different from Bitcoin's "everyone can see everything" model.

[17:56:11] Maybe I am misunderstanding what you mean by "Bitcoin feature"

[18:12:18] yeah, if a view-all key became a thing in monero, it would be considerably different than bitcoin

[18:14:21] except, of course, if to be granted the privilege of transacting with certain entities, you had to comply via handing over these keys.

[18:44:25] Question. I've been watching the "Breaking Monero" series on youtube and there is a lot of talk around how important the ring size is to hide who is spending the monero. I'm curious why this is such a big issue as my understanding is that the spenders wallet address isn't ever used on chain and instead a different, one time, address is derived. Am I understanding this correctly?

[18:45:18] Yes. Basically, monero without ring signatures is bitcoin with hidden amount if everyone used a new address every single time.

[18:45:51] But you still know which outputs are spent without ring signatures. Even if they go to a new place every time.

[18:46:26] but if it is impossible to go from the one time address back to the senders address. Why is it such an issue to keep increasing ring size?

[18:46:56] You don't know the wallet addresses associated with a transaction, but you can still try to associate an ip to a transaction as it gets sent (if you're monitoring traffic in the network)

[18:48:04] Because it helps increase privacy if you get some other information in addition to what is on the chain, which can include addresses (ie, Alice Customer gives Bob Exchange her address to withdraw some monero, then she spends that output - Without ring sigs, Bob now knows when Alice paid for something).

[18:48:14] And from there, figure out who owed which outputs

[18:48:50] She doesn't know what she did with it (without other extra info), but that's a data point. And the more data points you have, the more you can infer other things, usually probabilistically.

[18:49:05] Okay so lets say an attacker can say with 100% confidence that you are address X, they can then go to the node that it was sent from and potentially ask for logs or something from the ISP to find which IP you used to connect ( infering no VPN or TOR). Is this correct?

[18:49:15] The higher the ring size, the more possibilities there are.

[18:50:11] Is address X your IP ? If so, you already have the IP. If it's a Monero address, it doesn't help you get an IP address.

[18:50:14] So no.

[18:50:37] Or by address do you mean a one time output public key ?

[18:50:42] X is the one time address generated

[18:50:56] my bad

[18:51:37] Then, by "it was sent from", do you mean "that output X was spent in a tx, and we go to the node that sent it" ?

[18:51:47] (assuming no ring sigs)

[18:52:15] Then assuming further than you know which node it is, yes, but that's circular reasoning really.

[18:52:38] Then, assuming further you can get a warrant, you can ask the ISP for that node for logs.

[18:52:39] hmmm yea I'm confusing myself

[18:53:44] If you run lots of nodes with plenty of connections to others in the network, you can probably get a fair idea of where a tx comes from first, but it's probabilistic too (again).

[18:53:52] And harder to pull off with dandelion.

[18:54:12] And that part doesn't have anything to do with ring sigs.

[18:54:52] Of course if you do something braindead like not using your own node but a stranger's, they'll know you sent that tx.

[18:55:24] But that's like pulling a card off a pack, showing it to someone, then asknig "what card did I pick" ?

[21:20:49] Should we schedule a meeting about this issue? monero-project/research-lab #84

[00:17:58] .

[14:00:47] FloodXMR has a new version reddit.com/r/Monero/comments/ogs2k1…ransaction_flooding_attacks_against

[14:51:58] Should we schedule a meeting about this issue? monero-project/research-lab #84 <- i think would be useful

[15:16:38] Hopefully the authors addressed the major issues with the initial FloodXMR preprint

[15:16:47] Did they also update on IACR?

[15:34:50] Looks like they didn't update the preprint; that's unfortunate

[15:49:06] Im not familiar with the issues. Do they mean FloodXMR is not a practical risk?

[17:14:59] The initial preprint made some incorrect assumptions about consensus rules

[09:39:52] Someone in Reddit uploaded the new FloodXMR paper: swisstransfer.com/d/b5c38718-3a2b-48f3-8783-f115497b1af0

[13:37:19] "Simulation results show that by executing the proposed attack for one month, a malicious actor could trace 41.21% of all transaction inputs created after the month."

[13:37:29] that seems incorrect, the selection window is moving

[13:45:30] also they have no notes on the overall / total cost of the attack, sadly

Playback Complete.

My thoughts is that FloodXMR is in principle more credible that Big Bang because there was a possible credible motivation for the spam attack

... but the major lack of any rigor combined with incorrect assumptions in the article took away most of the credibility