15:03:22 <br-m> <rucknium> MRL meeting in this room in two hours.
16:20:17 <br-m> <jberman> I'll have limited availability in today's meeting unfortunately. I've been working pretty much exclusively on FCMP++ & Carrot stressnet issues. Repeating from last week, the issues we're seeing mainly seem to stem from existing issues in monerod. The FCMP++ & Carrot integration has had some hiccups, but for the most part the integration seems to be holding up well with hiccups patched
17:00:37 <br-m> <rucknium> Meeting time! https://github.com/monero-project/meta/issues/1281
17:00:50 <br-m> <rucknium> 1. Greetings
17:00:56 <br-m> <articmine> Hi
17:01:57 <br-m> <jeffro256> Howdy
17:02:49 <br-m> <jeffro256> @jberman: I can second this, he's been working like a dog ;) I've also been working on working on existing issues in monerod which the stressnet exposed
17:02:56 <br-m> <hinto> hello
17:03:22 <br-m> <vtnerd> Hi
17:03:42 <br-m> <rucknium> 2. Updates. What is everyone working on?
17:03:44 <br-m> <jeffro256> It's been very interesting to say the least, and definitely highlights the importance of fixing existing issues of efficient transaction/block propagation b/c it'll be needed more than ever with 4x bigger txs
17:05:12 <br-m> <rucknium> me: Keeping stressnet stressed. Keeping stressnet infrastructure (e.g. https://stressnetnode1.moneronet.info/ , https://stressnetnode2.moneronet.info/ , and seed nodes) alive and well.
17:06:13 <br-m> <hinto> me: PoWER and looking into ZMQ for Cuprate
17:06:42 <br-m> <vtnerd> me: legacy and balance keys now fully work in lws. Now working on an official docker image, as btcpayserver really needs it
17:07:02 <br-m> <jeffro256> Yay!
17:07:23 <br-m> <articmine> Me working on a write-up on the penalty and scaling. 
17:08:20 <br-m> <rucknium> 3. Proof-of-Work-Enabled Relay ("PoWER") (https://github.com/monero-project/research-lab/issues/133).
17:08:40 <br-m> <hinto> I've updated my proposal from last meeting: https://github.com/monero-project/research-lab/issues/133#issuecomment-3377869740
17:09:01 <br-m> <hinto> The P2P interface is slightly different than RPC/ZMQ, it's a 1-time challenge/solution exchange
17:09:26 <br-m> <hinto> The RPC/ZMQ endpoint provides unique challenges per connection and holds them until an expiry time, solutions are verified at other TX relaying endpoints; these could be cleared occasionally or maybe cleaned if set.size() >= POWER_MAX_ACTIVE_NONCES
17:10:25 <br-m> <hinto> Unique connections are still left undefined but I think this can be decided elsewhere, for now I assuming some network details
17:11:25 <br-m> <jeffro256> Maybe I'm misunderstanding the proposal, but keeping a finite set of valid certificates is a DoS vector 
17:11:32 <br-m> <boog900> I still believe requiring RPC connections to be held for PoW is fine 
17:11:56 <br-m> <boog900> And simplifies the protocol a lot 
17:12:36 <br-m> <hinto> @jeffro256: If there is no limit the node's memory can be exhausted
17:13:02 <br-m> <jeffro256> The protocol shouldn't require holding potential certificates in the first place 
17:14:09 <br-m> <jeffro256> It should be holding already completed PoW only
17:14:09 <br-m> <boog900> Wallet2 and monero-oxide both hold rpc connections
17:15:16 <br-m> <hinto> @jeffro256: Doesn't there have to be a limit on this as well?
17:16:07 <br-m> <jeffro256> Yes, but the attacker would have to do X seconds of PoW to store 16 bytes on your machine
17:16:21 <DataHoarder> if this certificate/check can be generated from the connection details, it'd not be any extra data other than connection itself, bounded by connection limit
17:16:26 <br-m> <hinto> @boog900: FYI this would bypass the state problems, RPC could exchange like P2P/ZMQ
17:16:32 <DataHoarder> even if it has to store x bytes, it'd be bounded by connection limit
17:17:00 <br-m> <jeffro256> And worst case scenario, they get to re-use PoW for a separate connection after doing many, many thousand of iterations of PoW. Whereas worst case scenario w/ your current proposal is that connections doing 0 PoW can lock out honest peers 
17:18:29 <br-m> <hinto> Ok I see, I misunderstood the idea, I think that's acceptable
17:18:58 <br-m> <boog900> @hinto: It only means people who don't hold RPC connections can't relay >8 input txs
17:19:43 <br-m> <jeffro256> The cert also needs to be signed (preferably symmetrically for performance) by the validating node, otherwise the attacker can make up challenges in advance 
17:20:27 <br-m> <vtnerd> I guess lws gets to pass power along to client wallets? Otherwise the server has to do it which isnt ideal
17:20:44 <br-m> <articmine> What kind of expiry on the cert?
17:21:39 <br-m> <jeffro256> In other words, creation of challenges should be stateless (besides the node's permanent signing keys), otherwise it poses a DoS vector to honest peers. The onus of storing ones's own validation information should be on the proving peer
17:23:47 <DataHoarder> 19:19:43 <br-m> <jeffro256> The cert also needs to be signed (preferably symmetrically for performance) by the validating node, otherwise the attacker can make up challenges in advance 
17:23:49 <DataHoarder> (I again bring up TOTP as an example of how challenges could be computed with a time factor on the go, based on an agreed "secret" information)
17:23:52 <br-m> <boog900> Is there an issue I am not seeing by requiring people to hold RPC connections? 
17:24:15 <br-m> <hinto> @jeffro256: Is this necessary on a 128-bit nonce?
17:25:43 <br-m> <jeffro256> DataHoarder: But why share secret information when secret information does not need to be shared?
17:26:19 <DataHoarder> the TOTP result is shared
17:26:19 <br-m> <boog900> @boog900: Wallet2 does it, monero-oxide does it. If we think this is acceptable, then we don't need to handle certificates, used nonces etc
17:26:19 <br-m> <hinto> @articmine: I think 1-5 minutes from the request would be okay
17:26:19 <DataHoarder> not the secret part
17:26:48 <DataHoarder> the agreed secret part doesn't specifically need to be sent over, it can be incoming connection details + local random secret
17:27:08 <DataHoarder> to re-verify the TOTP() of this you just need the connection details + time it was generated at
17:27:15 <br-m> <articmine> @hinto: That makes sense
17:27:34 <br-m> <jeffro256> @hinto: In my stateless proposal, yes. Not necessary in your proposal since it's infeasible to guess a 128-bit nonce generated on a node you don't operate
17:28:03 <DataHoarder> that'd generate a nonce (of however many bits) you can verify when the proving peer brings back a PoW result (along with the above^)
17:28:19 <br-m> <jeffro256> DataHoarder: How would the prover know your local random secret without asking you?
17:28:33 <br-m> <jeffro256> DataHoarder: This is susceptible to front-loading attacks 
17:28:36 <DataHoarder> they don't, the prover doesn't run TOTP
17:29:28 <DataHoarder> local node, when RPC connection that must be verified comes in, returns result of TOTP(details | secret | time) + time
17:29:35 <br-m> <jeffro256> So the prover still has to request a challenge, yes?
17:29:48 <DataHoarder> yes, but this challenge doesn't need storage by node
17:30:08 <DataHoarder> it's also limited in time directly (As you get time when prover returns PoW, and can instantly remove these)
17:30:11 <br-m> <jeffro256> Okay then I think we're talking about the same thing 
17:32:07 <br-m> <syntheticbird> @boog900: i love how no one answered you probably because they have doubt in mind but don't manage to put words on it.
17:32:08 <br-m> <syntheticbird> (i see no issue)
17:32:52 <br-m> <jeffro256> @boog900: Sorry, what specific actors you do mean by "people" and RPC to which software?
17:33:45 <br-m> <boog900> Wallets holding RPC connections to monerod 
17:34:12 <br-m> <boog900> If we think this requirement is OK then we can just generate a random nonce on connection like we will do for P2P
17:35:26 <br-m> <jeffro256> I think it should be optional, especially for local nodes. But I'm okay with supporting PoW for wallet->daemon connections, specifically for transaction submission endpoints 
17:35:48 <DataHoarder> as I suggested last time it's maybe better to have out of meeting conversations, but isn't it generally that 1) node must be able to generate challenges and not keep per-challenge state (single global state is ok as it's fixed byte size)  and 2) the prover must not be able to generate new nonces ahead of time (or collect too many without a defined
17:35:50 <DataHoarder> expiration date) and 3) valid nonces for PoW have to expire after a defined amount 
17:36:00 <br-m> <jeffro256> I wouldn't support it for other endpoints 
17:36:29 <DataHoarder> unrestricted RPC could have it disabled, restricted RPC enabled?
17:36:50 <br-m> <boog900> It would still work the same as your proposals, with an endpoint to get the challenge and an endpoint to submit 
17:37:24 <br-m> <boog900> Its just the challenge is for a specific connection so you cannot disconnect then reconnect and submit 
17:37:42 <br-m> <hinto> DataHoarder: PoWER is skipped on local/trusted interfaces
17:37:53 <br-m> <jeffro256> DataHoarder: Agreed. State per success-post-verification is okay though, and is probably necessary. But yeah further implementation details of the exact should probably be discussed on the Github issue, not in here 
17:38:48 <DataHoarder> post verification is bounded to RPC connection limits, so reasonable data usage there would be fine as it comes with a bound
17:39:58 <br-m> <jeffro256> Not just RPC connection limits, but PoW recently performed 
17:41:28 <DataHoarder> Right. RPC connects/disconnect (doesn't keep TCP connection open) so ports are not relevant.
17:42:19 <DataHoarder> If given expiration explicitly via generation these can be kept exactly as long as needed then removed away 
17:42:44 <br-m> <boog900> Tbf me and hinto have discussed it and he thought it would be unpopular to require wallets to hold connections.
17:43:12 <br-m> <boog900> I disagree though and can't see an issue, it would simplify the protocol a lot.
17:43:24 <br-m> <jeffro256> Oh hold connections?
17:43:42 <br-m> <jeffro256> Yeah I wouldn't want to implement it like that 
17:44:01 <br-m> <jeffro256> It would probably break a lot of app developers' flows 
17:44:10 <br-m> <jeffro256> Just do PoW when submmiting a tx 
17:44:25 <br-m> <boog900> Wallet2 and monero-oxide both hold connections
17:45:34 <br-m> <boog900> @jeffro256: As long as you can do more than 1  request per connection you can still do this
17:45:56 <br-m> <vtnerd> one issue I’m seeing is with ZMQ router/dealer stuff. you can’t use those setups with PoWER probably
17:46:11 <br-m> <vtnerd> I dont know of anyone using those setups though
17:46:51 <br-m> <boog900> @jeffro256: Fwiw they will still work as long as you don't send a > 8-input tx
17:47:40 <br-m> <jeffro256> @boog900: Is wallet2 really doing that? Hmmm... Probably not ideal for remote node privacy
17:47:40 <DataHoarder> alternatively have send_raw_transaction allow a list of transactions :)
17:47:45 <br-m> <hinto> FWIW I agree it would simplify everything, although agree with jeffro
17:48:15 <br-m> <boog900> @jeffro256: Why? Better than reconnecting for every request
17:48:22 <br-m> <articmine> @boog900: Which is not a serious issue
17:49:42 <br-m> <hinto> I think we can further discuss on the issue, should we move on?
17:50:09 <br-m> <jeffro256> @boog900: Why would re-connecting ever be worse for privacy? Re-connecting means that RPC requests from different wallets with the same host have some mixing. It's not much, but it's something 
17:52:44 <br-m> <boog900> @jeffro256: True but that's minimal and breaks my RPC PoWER idea D:
17:53:08 <br-m> <rucknium> 4. Transaction volume scaling parameters after FCMP hard fork (https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf). Revisit FCMP++ transaction weight function (https://github.com/seraphis-migration/monero/issues/44).
17:53:50 <br-m> <articmine> Any questions on this?
17:54:46 <br-m> <articmine> In particular the square root weights
17:55:18 <br-m> <articmine> ...and quadratic fees
17:57:54 <br-m> <articmine> Seeing none I will continue with my writeup and suggest we move on
17:58:29 <br-m> <jeffro256> For the record, I still NACK for the same reasons as last week, I just don't have anything new to add at the moment
17:58:40 <br-m> <rucknium> 5. FCMP alpha stressnet (https://monero.town/post/6763165).
17:59:27 <br-m> <rucknium> There was a new stressnet release, version 1.2: https://github.com/seraphis-migration/monero/releases
18:00:14 <br-m> <rucknium> With large blocks, nodes are having problems staying connected. The release fixes a minor cause of the connection problems, but many more remain.
18:00:17 <br-m> <jeffro256> Working through issues at the moment. Is there any specific issue someone wants to bring up or re-iterate?
18:00:44 <br-m> <rucknium> I am glad that you and jberman are invested in this stressnet ;)
18:01:15 <br-m> <rucknium> As you said, many of the issues are longstanding monerod issues, not specifically FCMP issues
18:01:20 <br-m> <rucknium> And we saw most of them on last year's stressnet
18:01:52 <br-m> <rucknium> Last year's stressnet just fixed the truly fatal issues, like irreparable netsplits.
18:02:04 <br-m> <mayhem69:matrix.org> I'm not sure if its an existing issue with monerod or with the stressnet version but these bans that are happening on stressnet are causing connectivity issues between peers:
18:02:05 <br-m> <mayhem69:matrix.org> https://github.com/seraphis-migration/monero/issues/180
18:02:40 <br-m> <rucknium> AFAIK, there is no easy way to clear all of your nodes' bans without restarting the node.
18:03:08 <br-m> <rucknium> Can some console command and/or RPC method be written to clear all bans?
18:04:20 <br-m> <rucknium> Even better, write something that can clear bans by CIDR subnet notation. Then you can clear all bans with a large CIDR, but clear specific subnets, too.
18:04:20 <br-m> <mayhem69:matrix.org> There is a script on of the guys made to clear the bans via the RPC which works but covers up the cause of the bans. If the bans are legit and supposed to happen then that is fine, the script that be used to clear the bans periodically. 
18:04:20 <DataHoarder> get_bans already exists, and set_bans as well. set_bans with ban: false should unban?
18:04:54 <DataHoarder> could make something that is CIDR aware
18:04:56 <br-m> <jeffro256> There's this script which I haven't tested yet: https://github.com/seraphis-migration/monero/issues/180#issuecomment-3405320886
18:04:57 <br-m> <jeffro256> No idea if it works or not 
18:05:11 <br-m> <jeffro256> @rucknium: This would be nice 
18:06:25 <br-m> <mayhem69:matrix.org> Yes that is the script and its using get_bans and set_bans and it seems to resolve the issue. Just figured I would bring it up b/c it is annoying to have unban to get connectivity and not everyone running a node is doing so and as such I find my node gets isolated from the network quite often. 
18:06:26 <br-m> <mayhem69:matrix.org> Anyway if this is expected behavior then that is fine. Just figured I would bring it up in case its not. 
18:06:37 <br-m> <rucknium> An external script is useful, but having a dedicated way to do it would help ordinary stressnet users
18:07:33 <br-m> <rucknium> No, the bans aren't supposed to happen, but they do because nodes think you are misbehaving when the network has heavy load.
18:08:41 <br-m> <jeffro256> Might be more serialization issues. We're looking into it. Better logging is a must going forward IMO 
18:08:57 <br-m> <rucknium> IIRC, on last stressnet, the ban timeout was set low manually in a stressnet PR
18:09:01 <br-m> <jeffro256> Or other levin limits 
18:09:17 <br-m> <jeffro256> @rucknium: That could be done here 
18:09:19 <br-m> <rucknium> Logging can stress a node too, AFAIK. That's double stress :D
18:09:39 <br-m> <spirobel:kernal.eu> aren't the bans cleared on restart? > <@rucknium> Can some console command and/or RPC method be written to clear all bans?
18:10:00 <br-m> <rucknium> @spirobel:kernal.eu: Yes, but often you don't want to restart.
18:10:28 <br-m> <rucknium> Last stressnet, restarting was very annoying since the node re-validated the entire txpool on restart. That's fixed for this one.
18:11:24 <br-m> <rucknium> I had a few out-of-memory crashes on an 8-GB RAM VPS with log level 2.
18:11:42 <br-m> <mayhem69:matrix.org> yes I notice bans occuring even when there is much load, seems to happen on my node when its syncing. And then its exacerbated b/c my node will try to connect to a node multiple times where I am banned and then my node bans then and its just a death spiral of bans.  I will try to add more info to the issue as I find it but I a [... too long, see https://mrelay.p2pool.observer/e/4tbFlL8KblM1WXNu ]
18:12:52 <br-m> <rucknium> Here it is: https://github.com/spackle-xmr/monero/pull/7 "Peer ban duration to 2 minutes"
18:13:28 <br-m> <jeffro256> Will add to v1.3 TODO list 
18:13:41 <br-m> <jeffro256> thanks
18:15:06 <br-m> <rucknium> Is there a specific goal with stressnet debugging, such as "network can smoothly handle txpool size X and block size Y"?
18:15:46 <br-m> <spirobel:kernal.eu> @rucknium: would it make sense to split the concept of peer bans from an exponential back off? usually in a distributed system you would do an exponential back off when a queue gets overloaded. 
18:16:04 <br-m> <rucknium> This isn't the final FCMP stressnet, of course, but as the issues are being chipped away, it could be good to know when the, uh, sculpture is considered complete.
18:16:27 <br-m> <rucknium> monerod always feels ban-happy to me.
18:17:04 <br-m> <spirobel:kernal.eu> @spirobel:kernal.eu: this peer ban death spiral sounds more like this type of situation when a back off would make sense compared to a ban  
18:17:16 <br-m> <jeffro256> Not yet, we didnt't have a specific mind in goal going into alpha, but you and everyone else have found a laundry list of good issues to work on in the short term. Perhaps future time period can have more focused goals 
18:17:29 <br-m> <rucknium> Occasional bans on mainnet wouldn't be as much of a problem. On a small stressnet, you are banning one of only a few possible peers.
18:18:02 <br-m> <articmine> All these improvements on network efficiency also harden Monero against spam and DDOS attacks > <@rucknium> Is there a specific goal with stressnet debugging, such as "network can smoothly handle txpool size X and block size Y"?
18:18:27 <br-m> <jeffro256> It's hard to control measurement of "smoothness" on an asynchronous network of peers which you don't control 
18:18:50 <br-m> <jeffro256> But yes, I agree that more specific goals should be finalized before a final stressnet 
18:20:08 <DataHoarder> would the final stressnet have any block verification improvements (or multithreading?)
18:20:51 <DataHoarder> it's still quite noticeable when mining as doing submit_block (or on miners) they will keep mining the old template for a while, as monero still has not verified the submitted block via RPC and this takes 5-20s
18:21:04 <br-m> <jeffro256> Yes, it should. There are a few big CPU-time improvements in review at the moment 
18:21:08 <DataHoarder> this effectively makes that time in between "lost" for miners
18:21:37 <br-m> <jeffro256> For example: https://github.com/monero-project/monero/pull/10157 should help that issue w/ large mempools 
18:21:47 <br-m> <spirobel:kernal.eu> how is your impression of the current peer ban list code? I just know from the wallet work, that rpc requests from the wallet also ended up on this ban list and it felt like the bans were sprinkled into the code base.  > <@jeffro256> It's hard to control measurement of "smoothness" on an asynchronous network of peers which you don't control 
18:21:58 <br-m> <boog900> IMO monero should do what bitcoin does and relay blocks after checking PoW but before verifying txs 
18:22:07 <br-m> <jeffro256> Assuming the change concept is sound, #10157 will be extended for FCMP++ txs 
18:22:28 <br-m> <jeffro256> There's also: https://github.com/seraphis-migration/monero/pull/101
18:22:36 <DataHoarder> that is done by P2Pool now boog900
18:22:51 <br-m> <rucknium> @boog900:monero.social: monerod doesn't do that now?
18:22:51 <DataHoarder> so everyone benefits, not just P2Pool blocks
18:22:52 <br-m> <boog900> yeah I know but we shouldn't rely on that IMO 
18:23:02 <DataHoarder> no, it has to verify transactions first
18:23:12 <DataHoarder> or sending bad blocks to other nodes causes them get banned
18:23:22 <br-m> <rucknium> In most circumstances, I guess it won't matter much if everything works smoothly with fluffy blocks.
18:23:25 <br-m> <jeffro256> @boog900: I've also thought about this. It's not a bad idea. I wonder how it would affect network health with a miner of similar hashpower to Qubic ~33%, willing to cause disruption for no return 
18:23:54 <br-m> <jeffro256> @rucknium: No, it verifies all consensus rules and input proofs before relaying 
18:23:59 <DataHoarder> 10157 looks good. specifically, if the received block is for the expected next height and all txs in mempool were verified to be valid, shouldn't this block have a quicker verification time? Or is the verification re-triggered?
18:25:20 <br-m> <jeffro256> DataHoarder: It should yes. Transaction input verification is only re-triggered if the dereferenced chain state for a transaction is changed, which will only happen in a >10-block reorg
18:25:45 <DataHoarder> then 10157 would cover these delays seen while mining, good.
18:26:57 <br-m> <jeffro256> If it works, yes, it should. 
18:28:40 <br-m> <rucknium> More on stressnet?
18:29:45 <br-m> <rucknium> Thank you all community members who are running stressnet nodes 🧡
18:30:02 <br-m> <rucknium> 6. Mining pool centralization: Temporary rolling DNS checkpoints (https://github.com/monero-project/monero/issues/10064), Share or Perish (https://github.com/monero-project/research-lab/issues/146), and Lucky transactions (https://github.com/monero-project/research-lab/issues/145).
18:32:31 <DataHoarder> checkpoints, still waiting for fixes. If we can get a proper repro case (via modified submit_block on known monero state) it'd be great, that way can attach a debugger and look at it.
18:32:34 <DataHoarder> Longer term splitting of the code paths as written in other channels makes more sense later on
18:32:54 <DataHoarder> Qubic broke something last week on their side and while fixing it they re-enabled selfish mining for a few more days, before it being disabled. They managed several reorgs of varying depths (some 5-7?) with ~1.6-1.8 GH/s.
18:33:08 <DataHoarder> They currently stay at around ~1.2 GH/s and have decided to withhold bonus XMR payments from miners after a vote to attempt to prevent their price going lower. Mining/marathon schedule unchanged.
18:33:59 <br-m> <rucknium> Thanks for keeping up with the Qubic movements, DataHoarder. What is "bonus XMR payments"?
18:35:55 <DataHoarder> Before, if price at end of epoch was > than an amount (at start of epoch) miners would receive some XMR (converted to their token) in their payments. this was part of their profit calculations
18:36:23 <DataHoarder> if it was below, it was instead converted to qubic and burned. now any xmr they find will always be burned.
18:37:23 <DataHoarder> (their people kept complaining that miners dumped too much qubic on each payout)
18:37:51 <DataHoarder> I don't think it's relevant to discuss for MRL, but an interesting note that has made them even less profitable compared to XMR or XMR+merge mining
18:37:51 <br-m> <rucknium> They are reducing the incentive to mine with Qubic now?
18:37:58 <br-m> <articmine> DataHoarder: The classic bear raid approach
18:38:29 <DataHoarder> It was an incentive originally thought to reduce selling pressure (if you don't sell price will go up which means more Qubic for you next week and so on)
18:38:55 <DataHoarder> it ofc, when they attracted short term miners, caused more selling pressure
18:40:21 <DataHoarder> This was the reasoning on their side to why stop now, Rucknium: https://irc.gammaspectra.live/36558af247094870/image.png 
18:40:37 <DataHoarder> but yes. there is no extra incentive except you get Qubic instead of something else
18:41:25 <DataHoarder> I think further questions around that could go onto -offtopic or -lounge if on topic enough ^\
18:42:36 <br-m> <articmine> Thanks for the Qubic update. 
18:42:48 <br-m> <rucknium> For next week, should this go on the agenda? https://github.com/hbs/MoneroMisc/blob/master/CARROT-discussion.md
18:42:48 <br-m> <rucknium> It suggests allowing user to not have an outgoing view key that can see outbound txs.
18:43:44 <br-m> <rucknium> There was discussion in #monero-research-lounge:monero.social  about it.
18:44:47 <br-m> <articmine> I say let the discussion in Lounge continue first.
18:45:58 <br-m> <articmine> If there is some loose consensus there then bring it here
18:46:21 <DataHoarder> There were some issues found with current schemes that would break current carrot construction if some of the keys were made the same, and the alternative was for users to keep using legacy wallets (with the lack of forward secrecy)
18:47:08 <br-m> <rucknium> @articmine: Alright.
18:47:25 <br-m> <rucknium> We can end the meeting here. Thank you everyone.
18:48:18 <br-m> <articmine> Thanks 
20:04:44 <tevador> articmine: Legacy wallets also get forward secrecy under Carrot (from an attacker who doesn't know a public address). They also get Janus attack protection.
20:05:18 <tevador> My recommendation would be to allow users to generate a legacy wallet (with k_s and k_v) instead of a new wallet (with the new keys, including the outgoing view key). This has good plausible deniability because all wallets made before the fork are legacy wallets anyways.
20:07:01 <tevador> New wallets should definitely not be constructed with k_ps = s_ga because: (1) Such use was not part of the audit. (2) Doing so loses internal forward secrecy. (3) It's impractical because it needs the private spend key to scan for owned enotes.
20:07:13 <tevador> *k_ps = s_vb
22:49:12 <br-m> <jberman> On stressnet: taking stock and looking at the issues, there is a lot we can solve in the short term/medium term to improve daemon performance before we hit a wall. I think we should continue to knock out these issues and then re-assess upon hitting a wall
22:49:32 <br-m> <jberman> Clearly the daemon is having issues with a 300mb pool and 5mb blocks, so I think a rational immediate goal is for the daemon to not have issues at these levels
22:49:55 <br-m> <jberman> Examples of issues with clear fixes that we can solve short/medium term:
22:49:55 <br-m> <jberman> Example1: daemons dropping a connection that finds a fluffy block >4MB. That is a clear issue with a simple fix (that we've now rolled out in alpha stressnet v1.2)
22:49:55 <br-m> <jberman> Example2: daemons re-relaying every complete tx in their pool every x interval causing dropped connections. We know how to fix that (tx relay v2 massively helps, and IMO this PR is helpful too: https://github.com/seraphis-migration/monero/pull/174)
23:14:04 <br-m> <kayabanerve:matrix.org> tevador: That sounds like the reasonable and practical way to make a new wallet without an OVK