01:39:19 <hyc> thanks for catching that, should be all good now
08:13:19 <blub> The last time, i was encountering a problem, i was using one pc for my node and the other one for the wallet . Now because i was using a rotating drive it was taking forever . Now that i am using a ssd its like night to day . Really quick and my wallet pc is not hanging 
08:13:40 <blub> However, on my wallet pc i run the wallet-cli. When i do a transfer it hangs an stays unresponsive. 
08:13:58 <blub> I am not rushing or anything its just that even when i do a ctrl+c the wallet remains unresponsive.
08:14:27 <blub> After a while i do the transfer and all is fine and dandy. I am guessing this has to do with some multi process thingy?
08:30:24 <selsta> .merge+ 8070 8075
08:30:24 <xmr-pr> Added
14:40:52 <PierrePicard[m]> I am curious if XMR will ever support smart contract? So we can bridge tokens onto it and run even defi projects?
14:43:10 <Rucknium[m]> Pierre Picard: How can you have smart contracts and still have high transaction uniformity so as to preserve privacy?
14:43:26 <PierrePicard[m]> Yeap, that's the crux of the issue
14:43:55 <PierrePicard[m]> Just assume if that were resolved, XMR will have both privacy and smart contracts and then it would boom
14:44:36 <PierrePicard[m]> PPL can easy hide the money trace like USDT by bridging in-out XMR network
14:46:49 <Rucknium[m]> Moving Z amount of money into XMR and Z out of it does not stop a sophisticated adversary from realizing that those two transactions are linked.
14:47:35 <PierrePicard[m]> Nah, say let's move in X amount of USDT and move Y+Z out from it
14:47:43 <PierrePicard[m]> How can you say Y+Z is from X?
14:48:20 <PierrePicard[m]> If we are having millions of transations daily
14:48:26 <Rucknium[m]> You use arithmetic: Y+Z = X. 
14:49:15 <Rucknium[m]> Stay in XMR. Enjoy the privacy
14:49:19 <PierrePicard[m]> Why strictly Y+Z=X? We can Y+Z+m=X
14:50:37 <PierrePicard[m]> Just saying a possible future for XMR when many other blockchains are booming like crazy. Most likely we need a "stable coin" of privacy which is a practical aspect
15:02:29 <jerfo> Does anyone ever get this error when trying to update the unbound submodule in the v0.17.2.3 branch?: "Fetched in submodule path 'external/miniupnp', but it did not contain 4c700e09526a7d546394e85628c57e9490feefa0. Direct fetching of that commit failed." 
15:02:52 <jerfo> *miniupnp
15:26:19 <selsta> jerfo: git submodule sync
15:34:07 <LyzaL> I don't think XMR needs smart contracts but I tell ya what if we could bridge to ethereum and get wXMR on Uniswap, that would be sexy
15:34:25 <LyzaL> PierrePicard[m] you might be interested in what Haven protocol is doing
15:34:41 <LyzaL> re: private stablecoins, it's an xmr fork
15:34:49 <PierrePicard[m]> If there were not smart contracts, how would bridging happen?
15:35:21 <LyzaL> well you would need *some* extra capability but nothing like what is usually considered a "smart contract" system. for example, wBTC
15:36:11 <PierrePicard[m]> LyzaL: Most ppl don't bother separate tokens just for privacy. "wrapped USDT" is much more appealing for its wide adoptions
15:36:15 <LyzaL> Secret network has a bridge to XMR but it's kinda janky, I think Haven and Thorchain are also both doing somethin. this is gettin offtopic tho :X
15:37:38 <LyzaL> can't believe you jsut said USDT was appealing
15:41:18 <PierrePicard[m]> LyzaL: hmmm, maybe the words are not accurate lol
15:42:19 <LyzaL> I see what you're saying though -- Secret network supports that kinda thing but also relies on Intel SGX for security :-| Monero's not gonna do anything that risky
15:42:47 <PierrePicard[m]> Yeah, I felt the janky part of secret network. wXMR is nothing else that I can find, nevertheless
15:52:43 <jerfo> @selsta thanks!
16:04:43 <PierrePicard[m]> Just checked haven protocol. Sad that it is too shallow :(
16:04:43 <PierrePicard[m]> https://coinmarketcap.com/currencies/haven-protocol/markets/
16:09:00 <LyzaL> yep, that's why network effect is so important
16:09:36 <hyc> haven's dev competence is pretty questionable https://twitter.com/sethforprivacy/status/1410420794879062019
16:10:42 <hyc> eh, not just competence - integrity https://twitter.com/sethforprivacy/status/1458633508537131010
16:11:11 <PierrePicard[m]> Synthetic assets are notorious in many projects
16:11:19 <PierrePicard[m]> I don't quite buy in the concept
16:11:49 <LyzaL> yeah there was a pretty bad inflation bug recently I guess I was more saying that it seems technically interesting to me, not that I'd put significant money there
16:12:12 <PierrePicard[m]> Still, I am relying only on CEX without KYC for XMR to hide money traces
16:13:30 <PierrePicard[m]> But this road is coming to an end when more and more CEXes are closing down no-KYC/withdrawal limits
16:14:14 <hyc> i think worrying about kyc is pointless. my bank knows I xfer'd money to an exchange
16:14:41 <PierrePicard[m]> nah, it is very important if you get your money directly from XMR
16:15:29 <LyzaL> Haveno and atomic swaps both being actively worked on -- it's def a recognized problem. Bisq and LocalMonero are not exactly optimal
16:15:34 <PierrePicard[m]> And exchanging XMR to popular cryptos is a must before you can get it into your own bank account
16:16:02 <LyzaL> depends on your jurisdiction -- there's still Kraken if you're not in the UK
16:16:10 <hyc> yeah kraken still worksforme
16:16:30 <hyc> maybe not for long, but so far no signs of other changes\
16:16:41 <PierrePicard[m]> yeap, the road is still to the end but as I say it is close
16:16:49 <PierrePicard[m]> * is still not to the
16:16:53 <hyc> not sure any of this is -dev material
16:17:08 <LyzaL> tru
16:17:53 <PierrePicard[m]> Anyway, we need a "pure dex" solution for exchanging XMR
16:18:29 <hyc> isn't that what haveno are working on?
16:22:19 <LyzaL> yep, although if I'm being honest if it works like Bisq the UX won't be very good. Bisq has individual offers a la LocalMonero, no order book for automatic buyer / seller matching.
16:23:15 <hyc> so it's a traditional marketplace like crigslist or ebay
16:23:57 <LyzaL> I don't think you can list like random items for sale like openbazaar or anything but yeah I guess so. it relies on seller reputations and such
16:24:05 <hyc> since trades are literally person2person, I dunno if I'd use an automatically matched partner
16:24:16 <hyc> I'd want to know more about who I'm dealing with
16:24:50 <LyzaL> ideally it would be trustless enough so as not to matter, but yeah if you're going to be sending somebody money by Zelle or something then sure
16:25:10 <PierrePicard[m]> Don't know how RUNE works out for XMR exchanges
16:25:13 <LyzaL> which brings up my other concern: sending randos money through zelle cashapp etc actually seems way more sus than just using an exchange
17:39:56 <rbrunner> The automatic build of my PR from about 1 hour ago by GitHub produces 2 errors that I am not able to interpret
17:40:20 <rbrunner> Maybe somebody who knows more here could have a look: https://github.com/rbrunner7/monero/actions/runs/1487279224
17:41:46 <rbrunner> PR is this here: https://github.com/monero-project/monero/pull/8076
18:54:13 <Elijah[m]> <rbrunner> "Maybe somebody who knows more..." <- Just wondering, are depreciation warnings important for monero? There's 6 of them in that workflow. 
18:54:36 <Elijah[m]> At least 6 actually. 
18:55:41 <Elijah[m]> The first error is in In file included from /Users/runner/work/monero/monero/src/rpc/core_rpc_server.cpp:38. Something about /Users/runner/work/monero/monero/contrib/epee/include/serialization/keyvalue_serialization_overloads.h:81:17: error: member reference base type 'long' is not a structure or union
19:28:27 <Elijah[m]> I think the issue is somewhere in wallet2.cpp
20:22:49 <rbrunner> As far as I can see the deprecation warnings are caused by some Trezor code. No idea about those.
20:23:18 <rbrunner> What really confuses me about the compilation errors is that they only occur on MacOS, not on Linux, and not on Windows
20:24:46 <rbrunner> Maybe it's a known problem, maybe even with a PR waiting already. selsta usually has the overview :)
20:26:56 <Elijah[m]> https://stackoverflow.com/a/48045971/7732434
20:27:12 <Elijah[m]> I think MacOS' time_t is different from Windows and Linux's
20:30:14 <rbrunner> Is there a particular line in the error messages that lets you suspect it could have something to do with time_t?
21:15:13 <Elijah[m]> Well the bug is in wallet2.cpp or core_rpc_server.cpp and has to do with (un)serialization. The only thing that can mess up serialization is the time_t. 
21:15:13 <Elijah[m]> https://www.cplusplus.com/reference/ctime/time_t/
21:15:13 <Elijah[m]> "Portable programs should not use values of this type directly, but always rely on calls to elements of the standard library to translate them to portable types."
21:19:08 <Elijah[m]> There are a couple spelling mistakes in the keyvalue_serialization*.h.
21:19:08 <Elijah[m]> serializible_type instead of serializ**a**ble_type and varialble instead of variable lol. Gonna fix them myself now.
22:50:17 <hyc> rbrunner yeah you should use int64_t or something instead of time_t, probably. in the rpc
22:50:44 <hyc> tho MacOS SDK shows time_t is just a long, same as any posix system
22:51:30 <hyc> uint64_t
22:51:43 <hyc> that's used for other timestamps already, just use that