13:13:08 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 13:13:28 the old one might come back :') 13:13:44 there is no "hidden pool" besides what is done for dandelion 13:14:44 if the old chain comes back, it's okay if the transactions aren't in the pool.... cause they're in the block, yeah? 13:14:55 Flushing the txpool _is_ a double spend. Reorging the chain back to old chain, woukd re-validate the txs 13:15:22 Not if they were already respent. Auto-flushing the txpool allows those txs to be respent 13:15:49 Which recreated problem A. Reorg will invalidate those re-spends 13:17:04 An 18-block-deep reorg recently hit the chain. Affected blocks were 3499659 → 3499676 13:17:10 thanks news 13:17:15 Nobody knew 13:17:22 ../s 13:17:23 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. 13:17:25 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 13:17:45 presumably so people could re-spend those coins 13:18:00 Yes, because there is no chance of those "honest" chain to win 13:18:26 Those 117 txs, if credited by recipient, are lost funds unless the sender resends them to the recipient 13:18:38 ok, so, at some point those transactions should be kicked, right? 13:18:47 7 days currently 13:19:00 IMO the first chains spends are more valid 13:19:16 which is a long time to have your money missing in the ether, no? 13:19:27 So the possibility of invalidating spends on the reorg chain doesn't matter as much 13:19:53 its the same thing 13:20:17 If i send you 100xmr, then flush/reorg when o wasnt looking, then send 100xmr to kucoin 13:20:36 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? 13:20:52 You can still do this after 7 days now 13:20:54 no, there is ropm for improvement 13:21:00 bruh 13:21:05 I guess my msg didnt send, but i typed "7 days is excessive" 13:21:44 I misread thought you said "no room for improvement" 13:21:54 Haha 13:22:37 If you are the miner you can do this now too 13:22:51 Just include the tx in the new block 13:24:46 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? 13:25:48 flush_txpool isnt for flushing invalid txs imo. Its a debug feature 13:26:07 that's beside the point 13:26:14 It flushes valid txs too, so obv not supposed to be widely used 13:26:34 but valid ones get re-added back when the node gets sent the transaction again, right? 13:26:41 Fixed difficulty, flush txpool, etc, arent tools youre supposed to use in public 13:27:00 I dont understand the q? 13:27:17 It doenst cause the txs to not get readded 13:28:12 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 13:28:33 my point is this. when you flush the TX pool, valid transactions (that were just flushed) can get added back.... invalid ones can't 13:28:39 And TX A goes back to the block it was originally mined in (but takes longer to propagate it you flush the txs) 13:28:54 so why are the invalid ones there to begin with??? 13:29:05 there should never be invalid transactions in the pool, doesn't make any sense 13:29:37 supposed to just disappear onto the ether? No record of you sending me money? 13:29:49 "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 13:29:57 yes, that is how re-orgs work 13:29:59 One minute, i see 8 confirmations, the next minute theres no tx? 13:30:09 No it isnt 13:30:26 I mean, in general it is. monero nodes are just wrongly keeping invalid transactions 13:30:37 reorgs replace blocks, not intended to invalidate txs 13:30:39 re-orgs can make transactions disappear, that's how it works 13:30:45 Invalidating is a monero problem 13:30:47 but it does though 13:30:53 LOL no it isnt 13:31:08 Reorgs dont delete transactions 13:31:25 Thats not how it works, and now how its supposed to work 13:31:27 ??? we are both sitting here agreeing that re-orgs invalidate transactions. invalid transactions may never become valid again, hence disapepar permanently from the blockchain 13:31:38 you're taking what I'm saying in bad faith 13:32:11 This is an _issue_ with monero 10 block lock 13:32:18 This is not a reorg feature 13:32:30 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 13:32:52 you always have to be the dominant voice, arguing with whatever just to hear yourself, it's so tiring 13:33:04 suck me sideways 13:33:06 I commented on the same points ofrnxmr did elsehwere 13:33:14 You're tirong 13:33:27 sadly invalidating the transactions also discloses the true spend as ringdb is not used for the re-spend 13:33:50 the transaction going back to pool is there to prevent attackers from abusing this normally 13:33:57 ofc, in this case it's affecting normal users 13:34:26 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 13:35:04 keeping the transactions for a week isn't protecting anyone's privacy, really 13:35:05 yeah. current monero setup is not optimal 13:35:19 but that's exactly what the code running in the wild has 13:37:01 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 13:37:07 more time for the data to be scrapped 13:44:17 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 13:45:17 A week is too long. Who knows why 7days was chosen 13:46:14 Well because this probably wasn't the scenario the people who wrote this code had in mind 13:46:21 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 13:46:30 I don't think the reason is to prevent double spends on the other chain at all 13:46:43 About why increased to 3 and 7 13:48:49 It doesnt make sense (to me) that invalid are kept for longer than double spends. Maybe theres some reason for that design? 13:49:43 Double spends are kept because the node only accepts the first one seen (right?), but why keep a double spend after its been mined? 13:51:31 https://github.com/monero-project/monero/commit/3bc16dc0e6bd38fbec51a054e640bacdb17a9a82 13:51:49 Cuprate removes txs by key image monerod does tx hash 13:53:58 One is malicious by the tx creator the other is not 13:54:31 You also assume a lot of thought went into the design 13:55:15 https://hackerone.com/reports/2315026 14:47:54 was the redacted info something personal or could affect Monero (if one not trusting h1)? 14:49:12 It was discussion on another vuln 14:49:16 yeah I when I drop in a report I immediately doxx myself 14:49:43 nothing to hide ;) 14:50:00 vulnerability transparency to the next level 15:42:43 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? 15:46:17 maybe this is a good question for vtnerd , but any responses appreciated 15:47:59 Do you make more than 100 parallel RPC requests to your monerod? 15:48:22 also include traffic coming from Tor daemon 15:54:16 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 15:55:22 I suppose that there is a micro delay between the connection being closed on the client end the destructor triggering a decrement in monerod 15:55:26 i.e. they're just running but not syncing 15:55:55 if the socket is opened then yes it counts as a connection 15:56:08 yeah 16:04:22 --rpc-max-connections 16:04:51 yep :) 16:04:52 You cant raise -per-private-ip higher than -man-connections 16:06:07 --rpc-max-connections 1000 --rpc-max-connections-per-private-ip 1000 16:06:07 it should also only effect restricted rpc 16:06:31 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 16:06:35 But i was having some "no connection to daemon" errors, and bumped it anyway 16:06:46 It does 16:07:05 Like 5 lines up fron the bottom on lvl 0 log 16:07:08 In red 16:07:09 :P 16:15:14 ah right there it is :D 16:29:19 It's not only restricted rpc 17:57:15 its supposed to be, hmm 18:00:49 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 18:27:38 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 20:44:14 Are there strong objections now to deploying temporary rolling DNS checkpoints very soon, in light of the recent 18-block re-org? 20:44:23 `18 blocks long, from height 3499659 (437 deep), diff 510191663980291508: 9489923b1773c2575e3320b84357e451b2dc625ba1cb9d2f4d6c352689c5ac7d` 20:44:54 ^ From `alt_chain_info` input into the `monerod` console. 20:45:16 xmrchain.net <- 117 txs invalidated 20:49:46 I can get a precise list of transactions ids involved close to the reorg so these can be checked 20:52:09 none 20:53:04 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 20:53:22 The sooner we alert the community that its gonna happen the less damage and fuss they are gonna cause. 20:53:50 Sounds like a good idea. Perhaps accompanied with a press release or tweet from the @Monero twitter handle. 20:54:41 Good thinking SyntheticBird 👍 20:56:22 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 20:57:13 MRL would simply explain the reason and scope of this mitigation 20:57:39 then community members can share it ahead and warn on a potential smearing campaign 20:57:51 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. 21:12:04 The preparation time was from the end of August or so :) 21:12:13 Now better than later I guess 21:17:25 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. 21:17:27 Plus, the other side is pussies anyway. 21:18:20 (read it with an old guy voice) LANGUAGE 21:19:46 if MRL has to take some tones that should without a doubt be pragmatism and objectivity. It's not their role to reassure people 21:20:02 I'll make the statement 21:22:09 Is this an official account? 21:22:09 https://nitter.net/MoneroResearchL 21:22:21 No 21:22:26 It says "unofficial" 21:22:31 True, my bad 21:22:52 I was thinking perhaps it was 'official' for this board but not the Monero project 21:22:56 Thanks though 21:22:58 The statements will come from GitHub and MRL blog, then spread across with that as source 21:23:19 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 21:26:09 Are you using 18.4.2? 21:26:38 It should do so, (return between refresh pulls) 21:26:57 18.4.1 should iirc 21:31:37 I’m using 18.4.1, but `get_height` still blocks for long periods while background refreshing 21:32:11 It should only block for the current download batch 21:32:23 And respond before it pulls the next batch 21:32:54 refresh -> listen -> respond -> refresh 21:55:55 This has been an issue for forever. If you use wallet2_api directly you can listen for actual progress events. 21:56:05 (with FFI bindings) 21:56:16 It was fixed recently 21:56:30 Fixed/improved 21:56:54 But yes, wallet-rpc blocked everythinf (including sigterm) while it was syncing 22:01:13 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. 22:01:15 You will have to choose a tone anyway. Might as well be pragmatic, objective and cool/calm than pragmatic, objective, and worried/fearful. 22:30:00 Fud gave us a 10% pump. MRL isnt concerned with politics or public perception 22:30:45 a technical response is all you should be asking of dev or mrl. If you want marketing Monero Marketing