<m​onero.arbo:matrix.org> so hey, when we get a re-org deeper than 10 blocks, would it make sense for nodes NOT to stick invalidated transactions back in the pool? like, they should be re-checked, right? maybe that's obvious but it seems suboptimal the solution is for users and pools to manually flush their transaction pool

the old one might come back :')

there is no "hidden pool" besides what is done for dandelion

<m​onero.arbo:matrix.org> if the old chain comes back, it's okay if the transactions aren't in the pool.... cause they're in the block, yeah?

<o​frnxmr:xmr.mx> Flushing the txpool _is_ a double spend. Reorging the chain back to old chain, woukd re-validate the txs

<o​frnxmr:xmr.mx> Not if they were already respent. Auto-flushing the txpool allows those txs to be respent

<o​frnxmr:xmr.mx> Which recreated problem A. Reorg will invalidate those re-spends

<d​rinksomemilk:matrix.org> An 18-block-deep reorg recently hit the chain. Affected blocks were 3499659 → 3499676

<o​frnxmr:xmr.mx> thanks news

<o​frnxmr:xmr.mx> Nobody knew

<o​frnxmr:xmr.mx> ../s

<m​onero.arbo:matrix.org> I'm not really sure I follow. There'd be two chain tips with different transactions spending the same coin, and eventually one would win.

<m​onero.arbo:matrix.org> I thought we were on the same page that having transactions stuck back in the mempool was bad? sech1 popped into the MoneroOcean discord this morning to ask MO to flush the tx_pool

<m​onero.arbo:matrix.org> presumably so people could re-spend those coins

<o​frnxmr:xmr.mx> Yes, because there is no chance of those "honest" chain to win

<o​frnxmr:xmr.mx> Those 117 txs, if credited by recipient, are lost funds unless the sender resends them to the recipient

<m​onero.arbo:matrix.org> ok, so, at some point those transactions should be kicked, right?

<o​frnxmr:xmr.mx> 7 days currently

<b​oog900:monero.social> IMO the first chains spends are more valid

<m​onero.arbo:matrix.org> which is a long time to have your money missing in the ether, no?

<b​oog900:monero.social> So the possibility of invalidating spends on the reorg chain doesn't matter as much

<o​frnxmr:xmr.mx> its the same thing

<o​frnxmr:xmr.mx> If i send you 100xmr, then flush/reorg when o wasnt looking, then send 100xmr to kucoin

<m​onero.arbo:matrix.org> all I'm saying is that if we're asking pool operators to manually flush their TX pool,. it seems there's room for improvement. is that controversial?

<b​oog900:monero.social> You can still do this after 7 days now

<o​frnxmr:xmr.mx> no, there is ropm for improvement

<m​onero.arbo:matrix.org> bruh

<o​frnxmr:xmr.mx> I guess my msg didnt send, but i typed "7 days is excessive"

<m​onero.arbo:matrix.org> I misread thought you said "no room for improvement"

<o​frnxmr:xmr.mx> Haha

<b​oog900:monero.social> If you are the miner you can do this now too

<b​oog900:monero.social> Just include the tx in the new block

<m​onero.arbo:matrix.org> honestly if flushing the TX pool causes the transactions to not get re-added.... it kind of implies to me they shouldn't be there to begin with. A new node coming online would receive that TX and go "nah that's invalid" and dump it, right?

<o​frnxmr:xmr.mx> flush_txpool isnt for flushing invalid txs imo. Its a debug feature

<m​onero.arbo:matrix.org> that's beside the point

<o​frnxmr:xmr.mx> It flushes valid txs too, so obv not supposed to be widely used

<m​onero.arbo:matrix.org> but valid ones get re-added back when the node gets sent the transaction again, right?

<o​frnxmr:xmr.mx> Fixed difficulty, flush txpool, etc, arent tools youre supposed to use in public

<o​frnxmr:xmr.mx> I dont understand the q?

<o​frnxmr:xmr.mx> It doenst cause the txs to not get readded

<o​frnxmr:xmr.mx> If there is TX A on honest chsin, invalidated, then flushed, then TX B on attacking chain, then honest chain overtakes, TX B nlw becomes invalid

<m​onero.arbo:matrix.org> my point is this. when you flush the TX pool, valid transactions (that were just flushed) can get added back.... invalid ones can't

<o​frnxmr:xmr.mx> And TX A goes back to the block it was originally mined in (but takes longer to propagate it you flush the txs)

<m​onero.arbo:matrix.org> so why are the invalid ones there to begin with???

<m​onero.arbo:matrix.org> there should never be invalid transactions in the pool, doesn't make any sense

<o​frnxmr:xmr.mx> supposed to just disappear onto the ether? No record of you sending me money?

<m​onero.arbo:matrix.org> "it might become valid later" I mean okay, lots of bullshit transactions might become valid later, doesn't mean they should be stuff in the pool just in case

<m​onero.arbo:matrix.org> yes, that is how re-orgs work

<o​frnxmr:xmr.mx> One minute, i see 8 confirmations, the next minute theres no tx?

<o​frnxmr:xmr.mx> No it isnt

<m​onero.arbo:matrix.org> I mean, in general it is. monero nodes are just wrongly keeping invalid transactions

<o​frnxmr:xmr.mx> reorgs replace blocks, not intended to invalidate txs

<m​onero.arbo:matrix.org> re-orgs can make transactions disappear, that's how it works

<o​frnxmr:xmr.mx> Invalidating is a monero problem

<m​onero.arbo:matrix.org> but it does though

<o​frnxmr:xmr.mx> LOL no it isnt

<o​frnxmr:xmr.mx> Reorgs dont delete transactions

<o​frnxmr:xmr.mx> Thats not how it works, and now how its supposed to work

<m​onero.arbo:matrix.org> ??? we are both sitting here agreeing that re-orgs invalidate transactions. invalid transactions may never become valid again, hence disapepar permanently from the blockchain

<m​onero.arbo:matrix.org> you're taking what I'm saying in bad faith

<o​frnxmr:xmr.mx> This is an _issue_ with monero 10 block lock

<o​frnxmr:xmr.mx> This is not a reorg feature

<m​onero.arbo:matrix.org> anyway, we've heard your opinion. maybe let somebody else react, cause I somehow doubt that everyone agrees with you about how the mempool is handed when re-orgs go deeper than 10 blocks

<m​onero.arbo:matrix.org> you always have to be the dominant voice, arguing with whatever just to hear yourself, it's so tiring

<o​frnxmr:xmr.mx> suck me sideways

I commented on the same points ofrnxmr did elsehwere

<o​frnxmr:xmr.mx> You're tirong

sadly invalidating the transactions also discloses the true spend as ringdb is not used for the re-spend

the transaction going back to pool is there to prevent attackers from abusing this normally

ofc, in this case it's affecting normal users

<m​onero.arbo:matrix.org> that's already the situation though, when pool operators are manually flushing so people can re-spend, AND it'a also the case when the re-orgs ("attacking") chain wins, which after at most a few hours we can say pretty definitely which chain won

<m​onero.arbo:matrix.org> keeping the transactions for a week isn't protecting anyone's privacy, really

yeah. current monero setup is not optimal

but that's exactly what the code running in the wild has

<m​onero.arbo:matrix.org> if anything keeping those transactions around for so long instead of purging them asap damages people's privacy more, cause only adversaries that kept the old alt chain or transactions from the memory pool will gain the advantage you're talking about

<m​onero.arbo:matrix.org> more time for the data to be scrapped

<b​oog900:monero.social> IMO the protections from a tx on chain A being invalidated by a reorg then a tx on chain B being invalidated by A coming back is not worth the inconvenience of not being able to spend your monero for a week if chain B stays ahead

<o​frnxmr:xmr.mx> A week is too long. Who knows why 7days was chosen

<b​oog900:monero.social> Well because this probably wasn't the scenario the people who wrote this code had in mind

<o​frnxmr:xmr.mx> Double spends are only 3 days. Moo said the values may have been 1 day and 3 days at some point. Maybe discussion available about why

<b​oog900:monero.social> I don't think the reason is to prevent double spends on the other chain at all

<o​frnxmr:xmr.mx> About why increased to 3 and 7

<o​frnxmr:xmr.mx> It doesnt make sense (to me) that invalid are kept for longer than double spends. Maybe theres some reason for that design?

<o​frnxmr:xmr.mx> Double spends are kept because the node only accepts the first one seen (right?), but why keep a double spend after its been mined?

<b​oog900:monero.social> monero-project/monero 3bc16dc

<b​oog900:monero.social> Cuprate removes txs by key image monerod does tx hash

<b​oog900:monero.social> One is malicious by the tx creator the other is not

<b​oog900:monero.social> You also assume a lot of thought went into the design

<b​oog900:monero.social> hackerone.com/reports/2315026

<b​asses:matrix.org> was the redacted info something personal or could affect Monero (if one not trusting h1)?

<b​oog900:monero.social> It was discussion on another vuln

<s​yntheticbird:monero.social> yeah I when I drop in a report I immediately doxx myself

<b​asses:matrix.org> nothing to hide ;)

<s​yntheticbird:monero.social> vulnerability transparency to the next level

<w​oodser:monero.social> it appears `--rpc-max-connections-per-private-ip` is limited to 100 before monerod cannot even start. is there any reason this couldn't have an upper limit of e.g. 1000 for local development?

<w​oodser:monero.social> maybe this is a good question for vtnerd , but any responses appreciated

Do you make more than 100 parallel RPC requests to your monerod?

<s​yntheticbird:monero.social> also include traffic coming from Tor daemon

<w​oodser:monero.social> I have more than 100 monero-wallet-rpcs connected to my monerod. my understanding (and what I see) is that they still count against the limit even after the stop making any requests

<s​yntheticbird:monero.social> I suppose that there is a micro delay between the connection being closed on the client end the destructor triggering a decrement in monerod

<w​oodser:monero.social> i.e. they're just running but not syncing

<s​yntheticbird:monero.social> if the socket is opened then yes it counts as a connection

<w​oodser:monero.social> yeah

<o​frnxmr:xmr.mx> --rpc-max-connections

<w​oodser:monero.social> yep :)

<o​frnxmr:xmr.mx> You cant raise -per-private-ip higher than -man-connections

<o​frnxmr:xmr.mx> --rpc-max-connections 1000 --rpc-max-connections-per-private-ip 1000

<o​frnxmr:xmr.mx> it should also only effect restricted rpc

<w​oodser:monero.social> just discovered that, testing now. probably monerod should show an informative error when rpc-max-connections-per-private-ip is set higher than rpc-max-connections instead of just not starting

<o​frnxmr:xmr.mx> But i was having some "no connection to daemon" errors, and bumped it anyway

<o​frnxmr:xmr.mx> It does

<o​frnxmr:xmr.mx> Like 5 lines up fron the bottom on lvl 0 log

<o​frnxmr:xmr.mx> In red

<o​frnxmr:xmr.mx> :P

<w​oodser:monero.social> ah right there it is :D

It's not only restricted rpc

<o​frnxmr:monero.social> its supposed to be, hmm

<o​frnxmr:monero.social> maybe they are just counted separately (or i misunderstood). I had expressed concerns about an external entity/ies using all of connections, blocking you from being able to control the node via unrestricted, and was told something along the lines of the limits only applying to restricted rpc

I recently hit that limit on an unrestricted RPC, so I had to increase it. As far as I can see, the limit is applied on the lower level, where monerod doesn't know if it's restricted or not

<r​ucknium:monero.social> Are there strong objections now to deploying temporary rolling DNS checkpoints very soon, in light of the recent 18-block re-org?

<r​ucknium:monero.social> `18 blocks long, from height 3499659 (437 deep), diff 510191663980291508: 9489923b1773c2575e3320b84357e451b2dc625ba1cb9d2f4d6c352689c5ac7d`

<r​ucknium:monero.social> ^ From `alt_chain_info` input into the `monerod` console.

<o​frnxmr:xmr.mx> xmrchain.net <- 117 txs invalidated

I can get a precise list of transactions ids involved close to the reorg so these can be checked

<s​yntheticbird:monero.social> none

<s​yntheticbird:monero.social> I'll just say that if we have a few days ahead of us WE NEED TO PREPARE by already, pre-deployment call out that Qubic is very likely to go on a social disinformation campaign

<s​yntheticbird:monero.social> The sooner we alert the community that its gonna happen the less damage and fuss they are gonna cause.

<a​pplelover999:matrix.org> Sounds like a good idea. Perhaps accompanied with a press release or tweet from the @Monero twitter handle.

<a​pplelover999:matrix.org> Good thinking SyntheticBird 👍

<s​yntheticbird:monero.social> I don't think the @Monero twitter handle should be the representative. They could probably relay an MRL statement similar to the gist written and shared on the recommendation of enabling ban list because of spy nodes concerns

<s​yntheticbird:monero.social> MRL would simply explain the reason and scope of this mitigation

<s​yntheticbird:monero.social> then community members can share it ahead and warn on a potential smearing campaign

<r​ucknium:monero.social> Right. I think a statement coming from MRL makes sense. The Core Team wants to remain technically neutral, but available to implement the DNS checkpoints if needed, from what I interpret.

The preparation time was from the end of August or so :)

Now better than later I guess

<a​pplelover999:matrix.org> Sounds fine. Although the statement should be written from a position of strength, calmness, and control. Avoid using words like "concerns", "worries", "fear". A strong, short, firm response will hit harder than the opposite.

<a​pplelover999:matrix.org> Plus, the other side is pussies anyway.

<s​yntheticbird:monero.social> (read it with an old guy voice) LANGUAGE

<s​yntheticbird:monero.social> if MRL has to take some tones that should without a doubt be pragmatism and objectivity. It's not their role to reassure people

<o​frnxmr:xmr.mx> I'll make the statement

Is this an official account?

<o​frnxmr:xmr.mx> No

<o​frnxmr:xmr.mx> It says "unofficial"

True, my bad

I was thinking perhaps it was 'official' for this board but not the Monero project

Thanks though

The statements will come from GitHub and MRL blog, then spread across with that as source

<w​oodser:monero.social> is there any way to make monero-wallet-rpc's `get_height` call return its current height immediately, without blocking in the request queue? it can be a real problem not being able to know if the wallet is making any progress

<o​frnxmr:xmr.mx> Are you using 18.4.2?

<o​frnxmr:xmr.mx> It should do so, (return between refresh pulls)

<o​frnxmr:xmr.mx> 18.4.1 should iirc

<w​oodser:monero.social> I’m using 18.4.1, but `get_height` still blocks for long periods while background refreshing

<o​frnxmr:xmr.mx> It should only block for the current download batch

<o​frnxmr:xmr.mx> And respond before it pulls the next batch

<o​frnxmr:xmr.mx> refresh -> listen -> respond -> refresh

<b​inarybaron:matrix.org> This has been an issue for forever. If you use wallet2_api directly you can listen for actual progress events.

<b​inarybaron:matrix.org> (with FFI bindings)

<o​frnxmr:xmr.mx> It was fixed recently

<o​frnxmr:xmr.mx> Fixed/improved

<o​frnxmr:xmr.mx> But yes, wallet-rpc blocked everythinf (including sigterm) while it was syncing

<a​pplelover999:matrix.org> You're totally right about being pragmatic and objective. I agree with you there. But do remember that delivery of that information still holds immense power.

<a​pplelover999:matrix.org> You will have to choose a tone anyway. Might as well be pragmatic, objective and cool/calm than pragmatic, objective, and worried/fearful.

<o​frnxmr:xmr.mx> Fud gave us a 10% pump. MRL isnt concerned with politics or public perception

<o​frnxmr:xmr.mx> a technical response is all you should be asking of dev or mrl. If you want marketing Monero Marketing