libera #monero-dev

12 Feb 2023

Official repo: github.com/monero-project/monero || Don’t ask to ask, just ask:) || Monero GUI dev is at #monero-gui || Monero website dev is at #monero-site || Non-dev questions -> #monero, please || No fork help, you’re on your own

• 06:10
  jeffro256[m]
  rbrunner jberman Sorry for arriving so late to the party... I just started reviewing monero-project/monero #8076 since I saw that jberman recently merged his changes into that PR
• 06:10
  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
  jeffro256[m]
  Why not something like moneromooo suggested: order incoming txs by an increasing counter
• 06:11
  jeffro256[m]
  Still not foolproof against those types of attacks, but most nodes will have the same order
• 06:14
  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
  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
  ofrnxmr[m]
  What died trusted daemon do about this
• 06:24
  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
  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
  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
  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
  rbrunner
  It seemed everybody from the dev community wanted to chime in with their own idea :)
• 07:58
  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
  rbrunner
  and what not, it seems it's finally ready to get merged. Thankfully.
• 07:59
  rbrunner
  But of course everything changes if you find a credible angle of attack, or a concrete exploit
• 08:00
  rbrunner
  Er, I meant you will find a *lot* of ideas of course, not a log ...
• 08:02
  ofrnxmr[m]
  Log fits too
• 08:03
  rbrunner
  Yeah, but with "log" the statements lack somehow the "impact" that I intended :)