What happened to the set command?

set

unknown command: set

Use "help" to list all commands and their usage

TrasherDK: which program?

it's a wallet command, maybe you entered it into the daemon?

monerod 0.17.0.0-ccfd75de0

I was looking for a "add peer <ip>" or something.

I realize, while typing, it was in the cli I used a set command 🙂

So, how do I add known peers? I'm still 2(out)+0(in)

you don't have to add any peers manually

just wait a bit, mine is currently at 5(out)+2(in)

I was triggered by "Feel free to add as peers manually if necessary". And I'm still on 2(out) only after 1 hour+

you can start monerod with `--add-peer ip`

What is going on with stagenet? Every time I open a RPC wallet, I get a lot of:

7fa3bb27b700 WARNING wallet.wallet2 src/wallet/wallet2.cpp:1847 Transaction extra has unsupported format: <edd46d1e2837ec772bb65e18d98e1e9683db481db99fa842749a9f022d59d972>

BTW: It's the release binaries.

Either someone's sending custom extra data or one of the recent consensus patches stopped grokking old txes.

You can tell which by rescanning those blocks with a version without those consensus patches.

Recent, as in 17.3.2?

The latest, with BP+ and view tags.

.merges

Merge queue empty

.merge+ 8318 8324 8326 8325 8328 8330 8331

Added

We were supposed to branch release-v0.18 on May 16th, is it still not done?

sech1: i mean we can do merges + branch but it just means we have to PR all upcoming fixes to both branches

branching now or in 2 weeks doesn't make much difference for testnet testing

or in 1 week or whatever

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

also be possible in a non-blocking format via simply not seeding if blocking (though no modern OS RNG should be).

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.

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

There's also monero-project/monero #4159 yet that was abandoned, so may be best to instead propose reviving that

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.

<kayabaNerve> "I would generally argue such..." <- Is it more important than anything else or easier to do than anything else at the moment ?

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.

<kayabaNerve> "No clue. Once we establish if..." <- boa-dev.github.io/boa/doc/rand/rngs…d-number-of-generated-bytes-be-used

"rust-random/rand #298#issuecomment-372621455", "We already don't reseed StdRng, and we make clear that reseeding is generally not necessary."

Is it enough to not care about it so much or not ?

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...

I'm not immediately convinced it applies

If your OS is malicious, it could just give you bad entropy either way, no?

reseeding wouldn't really help in that case

Right, it doesn't change security parameters

My comment is about entropy stagnancy

If you don't have your wallet in memory, but do get your entropy leaked, your first signature will leak your key

Ah yes, sorry I read your later comment wrong

If we actively increase entropy... That's not the case

It just shifts the requirement from entropy to the specific entropy used for clsag signing

*for full private key leakage

There's still a few other exploits. If you know randomness, you can break batch verification to some degree, and can break privacy

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

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

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

Instead of random, random value, initially seeded by sys

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 .-.

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

So then the question becomes how impactful that extra hash is

<kayabanerve[m]> "Anyways. This shouldn't be a..." <- Everything implemented correctly doesn't make things worse.

kayabanerve[m]: It would be better to think about p2p network changes within abstraction of "networked computer" then about rng reseeding.

How so?

s/then/than/

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

<kayabanerve[m]> "It'd also be better if I had a..." <- Have you seen any complex asynchronous code in rust ?

Uhhhh depends on how complex you're talking about. ASMR was in Rust and talked with daemons as necessary for atomic swaps though.

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

kayabanerve[m]: "github.com/SChernykh/p2pool/blob/master/src/p2p_server.cpp" like this one

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?

kayabanerve[m]: "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 ?

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 .-.

kayabanerve[m]: I'm not testing you right now; just send link to something similar in Rust, if you know, I'll read it

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

with the question.

It's a handler for an event an event loop would call, sure, but nothing about an event loop itself.

ooo123ooo1234[m]: ... I still don't know why you're looking for an example of async Rust code though.

<kayabanerve[m]> "Especially incredibly vague..." <- "github.com/farcaster-project/farcas…b/main/src/syncerd/monero_syncer.rs" this file, right ?

¯\_(ツ)_/¯

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.