02:38:17 > jeffro256: "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. 02:38:17 Plain old integers allow strict ordering 02:38:39 I'll put my money where my mouth is though and write up some code for what I mean 02:39:00 It really shouldn't be a huge change to the PR 02:39:11 If people decide that its worth pursuing 02:43:00 > But of course everything changes if you find a credible angle of attack, or a concrete exploit 02:43:00 It wouldn't be a "concrete" exploit in the sense that there's anything deterministic, but third parties would be able to build information on which nodes connect to whom 02:44:24 plain old integers have more race conditions between distributed nodes 02:44:36 timestamps are just integers anyway 03:08:59 Well the integer order for refrshing doesn't have to be the same between nodes, it just needs to be consistent for one node 03:09:31 (As long as the wallet isn't refreshing from multiple nodes) 03:09:50 Idk why it would do that 03:11:05 And yeah, timestamps are just integers, but they give more timing information about the network and your node's place in it, as opposed to an increasing integer 03:12:16 > Well the integer order for refrshing doesn't have to be the same between nodes, it just needs to be consistent for one node 03:12:16 Technically, it just needs to be monotonically increasing for a connection pair (node, wallet) but that's way too much work to implement for not that much gain 09:16:12 jeffro256[m] 09:16:12 : I am still a bit sceptical whether it's a good idea to investigate in the particular frame of this PR 09:16:33 Wouldn't you say that any possibility to find out is already there *before* this PR? 09:17:08 I mean some adversary could sample the pool in 5 second intervalls, compare what comes back and derive info from it 09:17:33 So could be this is a weakness alright, but it was always there, for many years 09:18:10 If that's really the case, I propose to declare this "out of scope" for *this* PR: This is not the PR to remedy year-old weaknesses 09:18:22 I would be content to just not make matters worse 09:18:50 If you see a weakness, and you want to try to get it out of the way, I propose you wait until this one is merged, 09:18:58 and then make a new PR of your own to improve 09:20:14 Even if the chances you want to finally contribute, this would make the history of this PR even more complicated than it already is 09:20:35 and of course we would have to repeat quite a number of tests, to see whether we don't have any regression 09:20:55 Please have mercy, as I said, this PR is already over a year old ... 09:24:06 *Even if the changes you finally want to contribute are small ... 10:52:06 Seraphis meeting today at 18:00 UTC in the Matrix room--No Wallet Left Behind. Everyone is cordially invited. 14:14:31 rbrunner: I thought similar thoughts when I wrote code to collect txpool data. When restricted_rpc=true, the RPC response doesn't share the time that a tx arrived (receive_time has only one-second time resolution anyway), but you can get a very good approximation by just sending RPC queries frequently.