left a comment here: monero-project/monero #8513/files#r952031123

.merges

.merge- 8464

Removed

Who handles the gitlab server at repo.getmonero.org? There are a ton of spam repos and groups

I do. Kinda. If you find a way to remove them easily, let me know.

Not familiar with gitlab server, I'm afraid :/

Hi.... (full message at libera.ems.host/_matrix/media/r0/do…1d1db815988f29ffde0502f155d17de2a85)

I also passed `disable-dns-checkpoints=1` and `enable-dns-blocklist=1` to my config file. Maybe this is the reason of disconnect?

<woodser[m]> "after calling `scan_tx` with ids..." <- opened an issue for this problem: monero-project/monero #8531

Hello guys just curious, why can't we get Monero mathematically proven and formally verified to be correct from its specification to C implementation to binary code? If we treat software program as mathematical proofs to a theorem, then using the rules of induction along with automated theorem prover we can mathematical prove that Monero is secure and correct without relying on cat and mouse game of finding bugs through auditing and bug

bounty

Are you talking about "formal verification"? It sounds like it. As far as I know, that is only possible for programs that are significantly simpler than a code like monero's source.

I assume sometimes the secret spend key must be sent from a client to the daemon. What security precautions are taken for that? I know there is TLS between wallet rpc and daemon, but that's optional. What else is there? I see temp storage in `epee::wipeable_string` as in `wallet_rpc_server::on_query_key()`. Other precaution on the wire? Encryption maybe?

When you say daemon... which daemon do you mean ? wallet daemon or node daemon ?

Because the node doesn't need to see your keys. If one asks, you can be sure they're a scammer.

IIRC query_key was added because someone wanted to be able to get the keys, not sure why. It should not be needed.

Assume that if the keys go over the wire, they're compromised.

Unless SSL with whitelisted certs. Because all that goes through the network stack, and we have no idea where it gets copied to.

And even if SSL with whitelisted certs, the other side may be merrily copying them all over memory.

Also, TLS is encryption.

Ah, actually, thinking about it, there is one good reason to send keys over the wire: creating a new wallet.

Same thing applies.

Hey congrats on passing 11K commits y'all !

<jozsef[m]> "Are you talking about "formal..." <- That's not true. It may be difficult to formally verify large programs but it's not impossible. Gernot Heiser has proven that formal verification scales decently even with software with millions of lines of code. It's just expensive but otherwise very well worth it especially for a software like Monero committed to financial privacy

dark: You can submit a CCS funding proposal to perform such a verification.

I mean the node daemon. I assumed (maybe I'm wrong) that when you create a transaction from a wallet and broadcast that to the network, you broadcast that to a daemon and that broadcast needs a private spend key. Does it not?

the transactions gets created on the wallet side, the daemon does not need any key

dark: I'm obviously no expert in formal verification. If this is possible, by all means that would be great. I just thought that formal verification is only possible if you can actually come up with a mathematically precise specification of what the program does and then you verify that and so that is only possible for simpler programs. The problem I see with this is that a code like monero is not written based on some specification. It

is written based on what it needs to do. How do you described that with the language of formal mathematics? Some parts of the math, yes, but every functionality? Sounds science & and fiction to me. But I'm happy to be proven wrong.

selsta: Okay, so the private spend key never leaves the wallet. That's reassuring.

moneromooo: updated with your suggestion monero-project/monero #8519

hmm have to double check if it gets initialized correctly

and have to check if it works correctly on testnet and stagenet

selsta: builds fine on my machine, tests and benchmarks run fine

the library on its own builds fine* idk what's wrong when included as a submodule

what command do you use to build UkoeHB/monero f7c53b8 ?

some cmake voodoo

i'll try to get it working

just regular make

the CI doesn't like it either: github.com/UkoeHB/monero/actions/runs/2907157096

some CMake stuff is missing

yeah but it's dying before it even gets to unit tests

clangd also doesn't like that `asm`

UkoeHB: [ OK ] seraphis_crypto.mx25519_sample_tests (0 ms)

will send you the diff

monero changes: paste.debian.net/hidden/974b0f33 mx25519 changes: paste.debian.net/hidden/1744bb63

selsta: thanks that worked

hi I made a exchange on changlly xmr 1.22 from my monero gui account to changlly and there saying they didn't get it

JB[m]12: do you have a transaction id?

also can you join the monero support channel on matrix?

a47e131c1a58f573de04bd1e58e0e0c7be28ed54239780ca15527370515db50c

please join #monero-support:monero.social

#monero-support:monero.social

sorry I got logged off