01:25:10 <RagnarRainMaker[> <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.  
01:25:58 <atomfried[m]> monero is unironically backed by drugs on DNMs 🤣
01:26:43 <hocuspocusoutoff> i think a lot of merchants would be motivated to accept monero if they just knew about it
01:26:58 <RagnarRainMaker[> atomfried[m]: lol well any tool can be used for good or bad purposes.  Doesn't mean it's the tool's fault.  
01:27:31 <hocuspocusoutoff> retail goods is probably not the best starting point because governments can easily do inventory tracking
01:27:31 <RagnarRainMaker[> hocuspocusoutoff: I agree.  It's a bit of a chicken and egg problem.
01:27:44 <RagnarRainMaker[> > <@some_nobody:nerdsin.space> i think a lot of merchants would be motivated to accept monero if they just knew about it
01:27:44 <RagnarRainMaker[>  * I agree.  It seems like a bit of a chicken and egg problem.
01:30:02 <RagnarRainMaker[> hocuspocusoutoff: Over time we could implement decentralized shipping to combat the problem of government tracking.
01:30:29 <RagnarRainMaker[> hocus pocus out of focus:  where do you think a good place to start might be?
01:30:41 <hocuspocusoutoff> the one i just brought up :)
01:30:41 <hocuspocusoutoff> decentralized cloud storage
01:31:26 <atomfried[m]> RagnarRainMaker[: oh sorry, i dont think it is a bad thing that monero is used for such stuff
01:31:46 <RagnarRainMaker[> That does seem like a valuable service.  
04:23:05 <spirobel[m]> <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. 
06:32:00 <mj-xmr[m]> 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.
06:42:39 <mj-xmr[m]> <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.
08:10:23 <mj-xmr[m]> 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.
08:15:40 <TengfeiNiu[m]> Hey guys, do current Monero node hide their info?
08:16:02 <TengfeiNiu[m]> Something like IP address, client version, etc.
08:28:18 <hocuspocusoutoff> Peers know that they connect to other peers
08:29:59 <TengfeiNiu[m]> So there's no privacy? Node leaks information?
08:32:17 <hocuspocusoutoff> You can run it through vpn/tor/i2p
08:32:43 <hocuspocusoutoff> Ultimately you need to connect to somebody to download the blockchain
09:00:17 <TengfeiNiu[m]> Cool. Thanks for detailed reply :)
14:00:13 <Elijah[m]> I came across https://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. 
14:38:42 <UkoeHB> 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?
14:39:35 <atomfried[m]> why does it say: ed25519 (unsafe) ?
14:41:04 <fluffypony> atomfried[m]: https://ristretto.group/why_ristretto.html
15:01:24 <sethforprivacy> <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.
15:13:34 <woodser[m]> I'm trying to find a good way for applications to support robust zero confirmation payments using wallet2
15:13:38 <woodser[m]> any suggestions?
15:14:34 <woodser[m]> maybe notifications when txs are invalidated, presumably due to re-org or double spend?
15:19:29 <moneromooo> You have a "double_spend_seen" flag in some RPC requesting tx info.
15:22:46 <bootlegbilly[m]> Just out of curiosity
15:22:51 <bootlegbilly[m]> Why not use http 2 for the rpc
15:27:27 <woodser[m]> 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 (?)
15:27:32 <woodser[m]> any good way to monitor for a re-org through wallet2?
15:30:09 <moneromooo> Not really. I'd do that through monerod, then manually refresh wallet.
15:30:44 <moneromooo> Sounds like a good addition though.
15:31:26 <moneromooo> Oh wait. There is on_reorg. I forgot :)
16:01:38 <woodser[m]> @spirorebel
16:01:38 <woodser[m]> 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()
16:01:58 <woodser[m]> @spirobel :)
17:15:18 -xmr-pr- taoeffect opened issue #8209: Fresh fullnode does not sync
17:15:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8209
18:11:44 <SerHack> Hey! I was wondering if anyone has ever tried to profile Monero Daemon to identify bottlenecks/issues
18:15:18 -xmr-pr- camberkenpas opened issue #8210: FreeBSD "Listen queue overflow" issues
18:15:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8210
18:20:16 <hyc> yes, I've used perf on it a few times. difficult to make meaningful changes due to C++ template nonsense
18:20:24 <hyc> Serhack ^
18:24:04 <SerHack> I see, thanks for letting me know about it
18:28:33 <mj-xmr[m]> SerHack: Hi Buddy!
18:28:33 <mj-xmr[m]> I profile `unit_tests` and `core_tests` after each merge burst: http://cryptog.hopto.org/monero/health/ 
18:28:33 <mj-xmr[m]> Look at the "Valgrind" column. I have opened 2 PRs related to the found bottlenecks:
18:28:59 <mj-xmr[m]> https://github.com/monero-project/monero/pull/7469
18:29:10 <mj-xmr[m]> https://github.com/monero-project/monero/pull/7717
18:29:57 <selsta> ndorf: any idea about https://github.com/monero-project/monero/issues/8210 ? i think you use some bsd variant
18:30:33 <SerHack> mj-xmr[m]: wow, it seems a pretty good work
19:08:25 <mj-xmr[m]> Thanks.
19:19:59 <selsta> .merge+ 7675
19:20:00 <xmr-pr> Added
19:31:18 <mj-xmr[m]> TY
20:21:15 <woodser[m]> SerHack: vtnerd did some performance analysis here: https://github.com/monero-project/monero/issues/7913
20:21:50 <woodser[m]> and cirocosta
20:25:08 <bootlegbilly[m]> How come the rpc uses http 1.1 and not http 2
21:11:49 <hocuspocusoutoff> which features of http2 were needed?
21:17:26 <bootlegbilly[m]> None are needed per second, but being able to keep a connection in http 2 or send multiple requests from one connection are useful
21:40:20 <sgp_> Is there a handy list anywhere that describes the difference between monerod log levels 0,1,2,3,4 in plain english?
22:36:02 <spirobel[m]> > <@woodser:haveno.network> @spirorebel
22:36:02 <spirobel[m]> > 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()
22:36:02 <spirobel[m]> 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!
22:36:41 <moneromooo> The higher the number, the more stuff gets logged, in generally decreasing general usefulness.
22:37:51 <spirobel[m]> <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.