01:39:19 thanks for catching that, should be all good now 08:13:19 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 However, on my wallet pc i run the wallet-cli. When i do a transfer it hangs an stays unresponsive. 08:13:58 I am not rushing or anything its just that even when i do a ctrl+c the wallet remains unresponsive. 08:14:27 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 .merge+ 8070 8075 08:30:24 Added 14:40:52 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 Pierre Picard: How can you have smart contracts and still have high transaction uniformity so as to preserve privacy? 14:43:26 Yeap, that's the crux of the issue 14:43:55 Just assume if that were resolved, XMR will have both privacy and smart contracts and then it would boom 14:44:36 PPL can easy hide the money trace like USDT by bridging in-out XMR network 14:46:49 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 Nah, say let's move in X amount of USDT and move Y+Z out from it 14:47:43 How can you say Y+Z is from X? 14:48:20 If we are having millions of transations daily 14:48:26 You use arithmetic: Y+Z = X. 14:49:15 Stay in XMR. Enjoy the privacy 14:49:19 Why strictly Y+Z=X? We can Y+Z+m=X 14:50:37 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 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 *miniupnp 15:26:19 jerfo: git submodule sync 15:34:07 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 PierrePicard[m] you might be interested in what Haven protocol is doing 15:34:41 re: private stablecoins, it's an xmr fork 15:34:49 If there were not smart contracts, how would bridging happen? 15:35:21 well you would need *some* extra capability but nothing like what is usually considered a "smart contract" system. for example, wBTC 15:36:11 LyzaL: Most ppl don't bother separate tokens just for privacy. "wrapped USDT" is much more appealing for its wide adoptions 15:36:15 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 can't believe you jsut said USDT was appealing 15:41:18 LyzaL: hmmm, maybe the words are not accurate lol 15:42:19 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 Yeah, I felt the janky part of secret network. wXMR is nothing else that I can find, nevertheless 15:52:43 @selsta thanks! 16:04:43 Just checked haven protocol. Sad that it is too shallow :( 16:04:43 https://coinmarketcap.com/currencies/haven-protocol/markets/ 16:09:00 yep, that's why network effect is so important 16:09:36 haven's dev competence is pretty questionable https://twitter.com/sethforprivacy/status/1410420794879062019 16:10:42 eh, not just competence - integrity https://twitter.com/sethforprivacy/status/1458633508537131010 16:11:11 Synthetic assets are notorious in many projects 16:11:19 I don't quite buy in the concept 16:11:49 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 Still, I am relying only on CEX without KYC for XMR to hide money traces 16:13:30 But this road is coming to an end when more and more CEXes are closing down no-KYC/withdrawal limits 16:14:14 i think worrying about kyc is pointless. my bank knows I xfer'd money to an exchange 16:14:41 nah, it is very important if you get your money directly from XMR 16:15:29 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 And exchanging XMR to popular cryptos is a must before you can get it into your own bank account 16:16:02 depends on your jurisdiction -- there's still Kraken if you're not in the UK 16:16:10 yeah kraken still worksforme 16:16:30 maybe not for long, but so far no signs of other changes\ 16:16:41 yeap, the road is still to the end but as I say it is close 16:16:49 * is still not to the 16:16:53 not sure any of this is -dev material 16:17:08 tru 16:17:53 Anyway, we need a "pure dex" solution for exchanging XMR 16:18:29 isn't that what haveno are working on? 16:22:19 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 so it's a traditional marketplace like crigslist or ebay 16:23:57 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 since trades are literally person2person, I dunno if I'd use an automatically matched partner 16:24:16 I'd want to know more about who I'm dealing with 16:24:50 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 Don't know how RUNE works out for XMR exchanges 16:25:13 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 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 Maybe somebody who knows more here could have a look: https://github.com/rbrunner7/monero/actions/runs/1487279224 17:41:46 PR is this here: https://github.com/monero-project/monero/pull/8076 18:54:13 "Maybe somebody who knows more..." <- Just wondering, are depreciation warnings important for monero? There's 6 of them in that workflow. 18:54:36 At least 6 actually. 18:55:41 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 I think the issue is somewhere in wallet2.cpp 20:22:49 As far as I can see the deprecation warnings are caused by some Trezor code. No idea about those. 20:23:18 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 Maybe it's a known problem, maybe even with a PR waiting already. selsta usually has the overview :) 20:26:56 https://stackoverflow.com/a/48045971/7732434 20:27:12 I think MacOS' time_t is different from Windows and Linux's 20:30:14 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 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 https://www.cplusplus.com/reference/ctime/time_t/ 21:15:13 "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 There are a couple spelling mistakes in the keyvalue_serialization*.h. 21:19:08 serializible_type instead of serializ**a**ble_type and varialble instead of variable lol. Gonna fix them myself now. 22:50:17 rbrunner yeah you should use int64_t or something instead of time_t, probably. in the rpc 22:50:44 tho MacOS SDK shows time_t is just a long, same as any posix system 22:51:30 uint64_t 22:51:43 that's used for other timestamps already, just use that