> 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.

Plain old integers allow strict ordering

I'll put my money where my mouth is though and write up some code for what I mean

It really shouldn't be a huge change to the PR

If people decide that its worth pursuing

> But of course everything changes if you find a credible angle of attack, or a concrete exploit

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

plain old integers have more race conditions between distributed nodes

timestamps are just integers anyway

Well the integer order for refrshing doesn't have to be the same between nodes, it just needs to be consistent for one node

(As long as the wallet isn't refreshing from multiple nodes)

Idk why it would do that

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

> Well the integer order for refrshing doesn't have to be the same between nodes, it just needs to be consistent for one node

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

jeffro256[m]

: I am still a bit sceptical whether it's a good idea to investigate in the particular frame of this PR

Wouldn't you say that any possibility to find out is already there *before* this PR?

I mean some adversary could sample the pool in 5 second intervalls, compare what comes back and derive info from it

So could be this is a weakness alright, but it was always there, for many years

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

I would be content to just not make matters worse

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,

and then make a new PR of your own to improve

Even if the chances you want to finally contribute, this would make the history of this PR even more complicated than it already is

and of course we would have to repeat quite a number of tests, to see whether we don't have any regression

Please have mercy, as I said, this PR is already over a year old ...

*Even if the changes you finally want to contribute are small ...

Seraphis meeting today at 18:00 UTC in the Matrix room--No Wallet Left Behind. Everyone is cordially invited.

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.