01:37:40 <TrasherDK> What happened to the set command?
01:37:43 <TrasherDK> set
01:37:44 <TrasherDK> unknown command: set
01:37:44 <TrasherDK> Use "help" to list all commands and their usage
02:20:37 <selsta> TrasherDK: which program?
02:20:52 <selsta> it's a wallet command, maybe you entered it into the daemon?
02:31:24 <TrasherDK[m]> monerod 0.17.0.0-ccfd75de0
02:32:35 <TrasherDK[m]> I was looking for a "add peer <ip>" or something.
02:33:20 <TrasherDK[m]> I realize, while typing, it was in the cli I used a set command 🙂
02:38:27 <TrasherDK[m]> So, how do I add known peers? I'm still 2(out)+0(in)
02:45:13 <selsta> you don't have to add any peers manually
02:45:40 <selsta> just wait a bit, mine is currently at 5(out)+2(in)
02:49:05 <TrasherDK[m]> I was triggered by "Feel free to add as peers manually if necessary". And I'm still on 2(out) only after 1 hour+
02:58:18 <selsta> you can start monerod with `--add-peer ip`
10:32:57 <TrasherDK[m]> What is going on with stagenet? Every time I open a RPC wallet, I get a lot of:
10:33:02 <TrasherDK[m]> 7fa3bb27b700	WARNING	wallet.wallet2	src/wallet/wallet2.cpp:1847	Transaction extra has unsupported format: <edd46d1e2837ec772bb65e18d98e1e9683db481db99fa842749a9f022d59d972>
10:36:47 <TrasherDK[m]> BTW: It's the release binaries.
10:46:50 <moneromooo> Either someone's sending custom extra data or one of the recent consensus patches stopped grokking old txes.
10:47:19 <moneromooo> You can tell which by rescanning those blocks with a version without those consensus patches.
11:48:12 <TrasherDK[m]> Recent, as in 17.3.2?
12:03:00 <moneromooo> The latest, with BP+ and view tags.
17:39:30 <selsta> .merges
17:39:30 <xmr-pr> Merge queue empty
17:43:02 <selsta> .merge+ 8318 8324 8326 8325 8328 8330 8331
17:43:03 <xmr-pr> Added
18:11:56 <sech1> We were supposed to branch release-v0.18 on May 16th, is it still not done?
20:39:17 <selsta> sech1: i mean we can do merges + branch but it just means we have to PR all upcoming fixes to both branches
20:40:09 <selsta> branching now or in 2 weeks doesn't make much difference for testnet testing
20:40:18 <selsta> or in 1 week or whatever
22:26:36 <kayabaNerve> Should I necrobump a 2016 issue or make a new one? I specifically want to discuss the RNG. I'm fine with it being the existing construction, unlike the historical issue advocating for a complete move to the OS, EXCEPT for the fact it's initially seeded, not actively seeded. I'd like to specifically propose actively increasing entropy so even if the initial state is recovered, the amount of data leaked is (hopefully) minimized. This should 
22:26:37 <kayabaNerve> also be possible in a non-blocking format via simply not seeding if blocking (though no modern OS RNG should be).
22:29:09 <kayabaNerve> I would generally argue such levels of access already mean you're screwed no matter what, but there have been exploits in the past accessing memory and this would at least make it temporal to how long its affected. It likely would even be possible to actively try to increase randomness on each call, making any single memory access just that. Singular.
22:29:56 <kayabaNerve> Absolutely not an expert on this, I know hyc had a lot of commentary back in the day, more advocating defense in depth, though if this does move forward, I'd like to also explicitly propose an API to disable active reseeding because I actually need seeded RNG in my work lol
22:34:56 <kayabaNerve> There's also https://github.com/monero-project/monero/pull/4159 yet that was abandoned, so may be best to instead propose reviving that 
22:35:35 <kayabaNerve> I'd rather not discuss "if not's broken, don't change it", yet increasing our security in depth. I do think this initial proposal is sufficiently modest and efficient for doing so.
22:55:26 <ooo123ooo1234[m]> <kayabaNerve> "I would generally argue such..." <- Is it more important than anything else or easier to do than anything else at the moment ?
22:56:38 <kayabaNerve> No clue. Once we establish if this proposal has merit, that's when it'd be implemented. It could sit around as it has been, I may find a few minutes, or someone else may want to pick it up. Someone has to take the first step though.
23:06:34 <ooo123ooo1234[m]> <kayabaNerve> "No clue. Once we establish if..." <- https://boa-dev.github.io/boa/doc/rand/rngs/adapter/struct.ReseedingRng.html#when-should-reseeding-after-a-fixed-number-of-generated-bytes-be-used
23:07:04 <ooo123ooo1234[m]> "https://github.com/rust-random/rand/issues/298#issuecomment-372621455", "We already don't reseed StdRng, and we make clear that reseeding is generally not necessary."
23:07:35 <ooo123ooo1234[m]> Is it enough to not care about it so much or not ?
23:09:11 <kayabanerve[m]> Definitely a fair critique. Now the discussion gets to be seed stagnancy versus malicious os RNG. Considering we initially seed from the OS which is theoretically malicious...
23:09:46 <kayabanerve[m]> I'm not immediately convinced it applies
23:10:25 <jeffro256[m]> If your OS is malicious, it could just give you bad entropy either way, no?
23:11:15 <jeffro256[m]> reseeding wouldn't really help in that case
23:16:08 <kayabanerve[m]> Right, it doesn't change security parameters
23:16:18 <kayabanerve[m]> My comment is about entropy stagnancy
23:16:48 <kayabanerve[m]> If you don't have your wallet in memory, but do get your entropy leaked, your first signature will leak your key
23:17:04 <jeffro256[m]> Ah yes, sorry I read your later comment wrong 
23:17:07 <kayabanerve[m]> If we actively increase entropy... That's not the case
23:18:08 <kayabanerve[m]> It just shifts the requirement from entropy to the specific entropy used for clsag signing 
23:18:29 <kayabanerve[m]> *for full private key leakage
23:19:22 <kayabanerve[m]> There's still a few other exploits. If you know randomness, you can break batch verification to some degree, and can break privacy
23:19:59 <kayabanerve[m]> Anyways. This shouldn't be a radical change and it shouldn't make anything worse, even if it doesn't practically make things better, yet it should be a theoretical improvement by adding a temporal component
23:21:28 <jeffro256[m]> Yeah I was actually looking at that PR you mentioned earlier, and I think the only draw back is the fact that that it is blocking, which could really slow down ringct ops. We could have a worker thready grab entropy from the OS while not busy so it's ready to go without a syscall, but that would complicate the code a little bit 
23:22:23 <kayabanerve[m]> Right. I'm proposing random, try sys random for additional, move on if none, else mix with what you can (up to 32 bytes), random value
23:22:35 <kayabanerve[m]> Instead of random, random value, initially seeded by sys
23:23:31 <kayabanerve[m]> It does add an extra hash and means an os which turns malicious and is reading your memory can poison it. They can also read your key out of memory .-. this is a networked computer .-. networking access generally isn't privileged .-.
23:24:13 <kayabanerve[m]> But even if we say it can't simply reveal the private key, yes, rng poisoning could reduce nonce strength. We just already have that as a risk when we start the daemon 
23:24:32 <kayabanerve[m]> So then the question becomes how impactful that extra hash is
23:25:09 <ooo123ooo1234[m]> <kayabanerve[m]> "Anyways. This shouldn't be a..." <- Everything implemented correctly doesn't make things worse.
23:25:41 <ooo123ooo1234[m]> kayabanerve[m]: It would be better to think about p2p network changes within abstraction of "networked computer" then about rng reseeding.
23:26:52 <kayabanerve[m]> How so?
23:27:08 <ooo123ooo1234[m]> s/then/than/
23:34:08 <kayabanerve[m]> It'd also be better if I had a Rust dev helping me out who could take some load off my back :p There's a lot of better things. Immediately, I do have an actual task though
23:40:42 <ooo123ooo1234[m]> <kayabanerve[m]> "It'd also be better if I had a..." <- Have you seen any complex asynchronous code in rust ?
23:41:22 <kayabanerve[m]> Uhhhh depends on how complex you're talking about. ASMR was in Rust and talked with daemons as necessary for atomic swaps though.
23:41:41 <kayabanerve[m]> So I feel I can claim competency in async rust, even if I can't claim to have written a runtime or done anything overtly complex :p
23:42:13 <ooo123ooo1234[m]> kayabanerve[m]: "https://github.com/SChernykh/p2pool/blob/master/src/p2p_server.cpp" like this one
23:43:25 <kayabanerve[m]> I believe I've done similarly complex code before in general, though I haven't written that much code in Rust. Nothing there looks horrifically complex though. Why?
23:44:53 <ooo123ooo1234[m]> kayabanerve[m]: "https://github.com/SChernykh/p2pool/blob/master/src/p2p_server.h#L91" What would be different in Rust in case of code attached to event loop ?
23:45:33 <kayabanerve[m]> I really don't care to be asked questions in some sort of test when I don't know why and this isn't a job interview .-.
23:47:04 <ooo123ooo1234[m]> kayabanerve[m]: I'm not testing you right now; just send link to something similar in Rust, if you know, I'll read it
23:47:25 <kayabanerve[m]> Especially incredibly vague questions such as that. If we're discussing an event loop, there's a lot of comments you can make. Events should be an enum you match off of! You need to use Arcs to share data across threads! Data spawned to another thread must be Send + Sync which is automatically applied as applicable! And none of it really helps either of us, especially when you cite a function definition that doesn't seem to line up
23:47:25 <kayabanerve[m]> with the question.
23:47:40 <kayabanerve[m]> It's a handler for an event an event loop would call, sure, but nothing about an event loop itself.
23:48:06 <kayabanerve[m]> ooo123ooo1234[m]: ... I still don't know why you're looking for an example of async Rust code though. 
23:54:56 <ooo123ooo1234[m]> <kayabanerve[m]> "Especially incredibly vague..." <- "https://github.com/farcaster-project/farcaster-node/blob/main/src/syncerd/monero_syncer.rs" this file, right ?
23:55:24 <kayabanerve[m]> ¯\_(ツ)_/¯
23:55:43 <kayabanerve[m]> Maybe. I don't know what this discussion is or what you're asking. If you want to continue it, please PM me, yet this is currently just spamming #monero-dev AFAICT.