06:10:02 <jeffro256[m]> rbrunner jberman Sorry for arriving so late to the party... I just started reviewing https://github.com/monero-project/monero/pull/8076 since I saw that jberman recently merged his changes into that PR
06:10:56 <jeffro256[m]> I was wondering: why are timestamps used to order the transactions? This seems like it would open up a lot of side channel attack opportunities for bad actors to map out the peer relationships 
06:11:27 <jeffro256[m]> Why not something like moneromooo suggested: order incoming txs by an increasing counter
06:11:48 <jeffro256[m]> Still not foolproof against those types of attacks, but most nodes will have the same order
06:14:58 <jeffro256[m]> You could even do some fudging by randomly ordering transactions if multiple transactions show up in between RPC calls to /get_blocks_fast
06:17:03 <jeffro256[m]> Also, then for optimization, we could use an unordered_map instead of a multimap for m_removed_txs_by_time because each transaction entering the pool would have a unique counter ID
06:23:05 <ofrnxmr[m]> What died trusted daemon do about this
06:24:13 <ofrnxmr[m]> Does*. There is a huge difference in data transfer when using trusted daemon (sync starts very fast with sub 100kb download vs 5+  seconds and 3-10mb download)
07:56:11 <rbrunner> jeffro256[m]: "why are timestamps used to order the transactions?" Not sure what you mean. If you want to have an incremental system, you have to order somehow.
07:56:41 <rbrunner> And now nothing different than before happens: Before, the were also ordered by time, by receiving time. Don't think anything is worse now.
07:57:19 <rbrunner> By the way, if you go back to the start of this history, you will find a *log* of ideas how to implement, and a log of arguing back and forth
07:57:41 <rbrunner> It seemed everybody from the dev community wanted to chime in with their own idea :)
07:58:15 <rbrunner> And well, now, after more than a freaking year, and again a lot of testing by at least 3 people, and benchmarking, and load testing
07:58:34 <rbrunner> and what not, it seems it's finally ready to get merged. Thankfully.
07:59:01 <rbrunner> But of course everything changes if you find a credible angle of attack, or a concrete exploit
08:00:36 <rbrunner> Er, I meant you will find a *lot* of ideas of course, not a log ...
08:02:22 <ofrnxmr[m]> Log fits too
08:03:12 <rbrunner> Yeah, but with "log" the statements lack somehow the "impact" that I intended :)