<methylene[m]> "Ah, yes, you've discovered the..." <- I believe I have figured out a way to solve this conundrum. I have been working on it for a long time and Monero's technology was the final missing piece to the puzzle. I believe using Monero's blockchain a stable coin can be created, which will be more stable than the US dollar. And which will naturally motivate merchants to accept it as a form of payment.

monero is unironically backed by drugs on DNMs 🤣

i think a lot of merchants would be motivated to accept monero if they just knew about it

atomfried[m]: lol well any tool can be used for good or bad purposes. Doesn't mean it's the tool's fault.

retail goods is probably not the best starting point because governments can easily do inventory tracking

hocuspocusoutoff: I agree. It's a bit of a chicken and egg problem.

> <@some_nobody:nerdsin.space> i think a lot of merchants would be motivated to accept monero if they just knew about it

* I agree. It seems like a bit of a chicken and egg problem.

hocuspocusoutoff: Over time we could implement decentralized shipping to combat the problem of government tracking.

hocus pocus out of focus: where do you think a good place to start might be?

the one i just brought up :)

decentralized cloud storage

RagnarRainMaker[: oh sorry, i dont think it is a bad thing that monero is used for such stuff

That does seem like a valuable service.

<methylene[m]> "spirobel: The network targets..." <- not really a fan of that tbh because it might be in the future like in my case. And the guessing is not worth the benefit. Is there even a benefit? Just leave the syncHeight unset if there is no daemon connection on wallet creation time.

luigi1111selsta : May I ask for an exclusive merge of 8197 ? In any order you want to merge it, there will always be conflicts since this one touches almost everything.

<jeffro256[m]> "Genuine question: Is my PR (..." <- I'd say one commit per PR, where just one function is removed would be OK for me. Don't forget, that each PR, after being merged together with other unrelated PRs, has to be tested by CI, independently of your PR's CI test.

This is so, because in meantime some other conflicting stuff could have been merged in-between. With a large PR like this, the risk is increased that there are conflicts, that can't be auto merged.

Hey guys, do current Monero node hide their info?

Something like IP address, client version, etc.

Peers know that they connect to other peers

So there's no privacy? Node leaks information?

You can run it through vpn/tor/i2p

Ultimately you need to connect to somebody to download the blockchain

Cool. Thanks for detailed reply :)

I came across github.com/dalek-cryptography/bulletproofs#comparative-performance when looking at some projects. Is this bulletproofs a possible way to optimize Monero, or does Monero's implementation prevent such types of optimizations, ignoring the porting constraints.

It seems odd to me that daleks' bp would be 7x faster. Maybe they have a faster multiexp algorithm... (seems unlikely) is there someone out there up to investigating the reason?

why does it say: ed25519 (unsafe) ?

atomfried[m]: ristretto.group/why_ristretto.html

<UkoeHB> "It seems odd to me that daleks..." <- Probably a better question for #monero-research-lab:matrix.org or #monero-research-lounge:monero.social instead of dev.

I'm trying to find a good way for applications to support robust zero confirmation payments using wallet2

any suggestions?

maybe notifications when txs are invalidated, presumably due to re-org or double spend?

You have a "double_spend_seen" flag in some RPC requesting tx info.

Just out of curiosity

Why not use http 2 for the rpc

so I guess a solution would need to monitor the tx to be removed from the pool or if a double spend is seen, which isn't currently supported (?)

any good way to monitor for a re-org through wallet2?

Not really. I'd do that through monerod, then manually refresh wallet.

Sounds like a good addition though.

Oh wait. There is on_reorg. I forgot :)

@spirorebel

in the case that it guesses a height too big without a daemon connection, maybe you can set the correct refresh height once the wallet connects. that's called wallet.setSyncHeight() in monero-javascript which passes through to wallet2->set_refresh_from_block_height()

@spirobel :)

Hey! I was wondering if anyone has ever tried to profile Monero Daemon to identify bottlenecks/issues

yes, I've used perf on it a few times. difficult to make meaningful changes due to C++ template nonsense

Serhack ^

I see, thanks for letting me know about it

SerHack: Hi Buddy!

I profile `unit_tests` and `core_tests` after each merge burst: cryptog.hopto.org/monero/health

Look at the "Valgrind" column. I have opened 2 PRs related to the found bottlenecks:

ndorf: any idea about monero-project/monero #8210 ? i think you use some bsd variant

mj-xmr[m]: wow, it seems a pretty good work

Thanks.

.merge+ 7675

Added

TY

SerHack: vtnerd did some performance analysis here: monero-project/monero #7913

and cirocosta

How come the rpc uses http 1.1 and not http 2

which features of http2 were needed?

None are needed per second, but being able to keep a connection in http 2 or send multiple requests from one connection are useful

Is there a handy list anywhere that describes the difference between monerod log levels 0,1,2,3,4 in plain english?

> <@woodser:haveno.network> @spirorebel

> in the case that it guesses a height too big without a daemon connection, maybe you can set the correct refresh height once the wallet connects. that's called wallet.setSyncHeight() in monero-javascript which passes through to wallet2->set_refresh_from_block_height()

I will make sure to set the daemon connection on startup. I still dont understand why this number is guessed. Can lead to bad DX like in my case haha But I will be quiet now and just accept it 😅 Thanks for your work by the way I wouldnt know how to survive without your library!

The higher the number, the more stuff gets logged, in generally decreasing general usefulness.

<woodser[m]> "so I guess a solution would need..." <- great idea. I will include a challenge response mechanism in my browserwallet that will instantly provide a txproof to the server (maybe shop maybe non custodial marketplace) Really interested in this type of functionality.