jeffro256[m]: it's probably fair to say that, do you have some particular situation in mind for this question?

I was trying to brainstorm ways to take information from the blockchain to help order the tx pool events between restarts consistently that didn't involve storing extra information

For monero-project/monero #8076

Right now wall-time is used which can lead to arbitrarily large inconsistencies with tx ordering if the clock is changed manually or just during normal syncs

between restarts of the daemon? wouldn't you just reload the tx pool in whatever state it was when you saved it, which would be implicitly ordered?

Yes, but the wallet stores a value called "m_pool_info_query_time" which the daemon returns and the PR allows the wallet to incrementally synchronize the pool while simultaneously downloading blocks

That value "m_pool_info_query_info" has be increasing monotonically otherwise you the wallet will get an incomplete view of the pool

do you need consistency between interactions with different daemons? otherwise you could give each tx pool event an id from a monotonic counter, and queries would indicate the highest counter they know about

that would give you a way to track txs no longer in the pool: return a list of counter ids <= the query's top id for txs still in the pool

* that would give you a way to detect when txs are no longer in the pool: return a list of pool ids <= the query's top id for txs still in the pool

> do you need consistency between interactions with different daemons? otherwise you could give each tx pool event an id from a monotonic counter, and queries would indicate the highest counter they know about

Yes that's exactly my thought, the problem is now consistency between restarts. It doesn't need to be consistent across daemons, just consistent for one daemon

I could just store the counter but I am trying to avoid it

For simplicity

after restarts you should just re-do the pool scanning

for simplicity :)

restarts should be quite rare

Yes, but how would the wallet know when to do the rescanning? They could know for sure if the counter went down I guess but the counter might not go down

one solution would be a session id

I was thinking a session ID as well as the counter

jinx

lmao

Great minds think alike

That'll be a little extra review work, but I think it'll be worth it

jeffro256[m]: I vaguely remember that I thought through the case "daemon restart"

I would predict the daemon sees that the info about the pool content does not go as far back as the client wants to get it

And will return "Sorry, I could not give back incremental results, here have the whole pool"

And then the client switches the return value processing approach from "incremental" to "whole pool" as a reaction

I would also suspect that over the course of a year we amassed enough tests to detect if you could throw everything off

by simply restarting the connected daemon ... or maybe I misunderstand the situation you investigate?

Restarting causing inconsistency isn't necessarily a problem as-is with wall-time ordering, but wall-time ordering is susceptible to any arbitrarily large inconsistencies due to system time adjustments

Right now, as the PR stands, you can have the following situtation: 1) Wallet asks daemon for daemon time and daemon returns time A. 2) Daemon system time jumps backwards in time, either from manual adjustment or regular synchronizations to time B (B < A). 3) Daemon then add transaction T to pool at time C (B < C < A). 4) Wallet then asks for incremental refresh since A. 5) Since C < A, the daemon does not send transaction T and so

the wallet refresh is in an inconsistent state

These scenarios are eliminated if we use a steady clock (e.g. std::chrono::steady_clock or m_cookie), but now we have to worry about monotonicity across restarts

Or at least, you have to worry about notifying the wallet that they need to fetch the whole pool this time before continuing incremental refresh

Well, I guess you are right, but doesn't that self-correct after only one call?

I mean, alright, the first call right after the daemon had its time travel can omit transactions that it should return

But then it returns its new time to the client, that will use that next time, and everything should be alright already?

By the way, just to not lose perspective, we are merely talking about *pool* transactions

After 2 minutes of missing transactions, with the arrival of the next block, chances are good everything is alright

for the simple fact that the missed transactions went into that block and reach the client that way

It's anyway mildly worrying to me how much effort goes into this, where merely the processing of pool transactions gets improved, nothing else

If you really like, you could see the whole pool transaction handling as "nice to have" - the wallet would perfectly work without it ...

Looks like the cli wallet doesn't have the option to ignore the exchange_multisig_info stage for 2/2 wallets.

Alex|LocalMonero: pass in the output of the make_multisig call plus set the force update flag to true

the output of the local call*

UkoeHB: You mean the `prepare_multisig` command? The `make_multisig` command just throws an error that the wallet is already multisig.

Actually, prepare_multisig throws the same error.

I mean the output you get when you call it the first time

UkoeHB: There doesn't seem to be a force update flag in the CLI

well it's not a user-safe option

so only RPC has it

Perhaps its enablement should be added as a set flag? Or 2/2 wallets should simply not ask for the post-kex round.

Like I said before, the default should be as strict as possible. It may be feasible to have a 'fast N-of-N setup' method.

Output blackballing hasn't been useful for over 4 years: old.reddit.com/r/Monero/comments/9r…ating_and_importing_an_output_spent

Not sure if there ever was a follow up that takes public pool data into account, but I can't imagine it making much of a difference considering the significant ring size increase since then.

Is there any reason to keep this around?

Removing it would eliminate ~2k lines of code, shave a couple MB from release archives and be one less thing to worry about during seraphis transition.

can somebody explain to me how a remote hidden service is chosen when I use --tx-proxy?

is it random each time the node restarts or does it stick to the same node?

how does it get the list of available nodes?

tobtoht[m]1: can you make a GitHub issue for that?

Also Alex|LocalMonero make an issue for the n of n fast setup

monerodtxproxy: #monero:monero.social

i would like to be pointed to code if possible

UkoeHB: yes

so that i can modify the source to ensure on restart it does not connect to same node

i don't know if it has sticky behavior

tobtoht: Could the blackballing code be used to exclude coinbase outputs from decoy selection?

Rucknium: No, would be much easier to have the daemon mark coinbase outputs as such in get_outs call during tx construction rather than keeping (and updating, somehow) a list of coinbase outputs in the shared ringdb.