thanks for catching that, should be all good now

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

However, on my wallet pc i run the wallet-cli. When i do a transfer it hangs an stays unresponsive.

I am not rushing or anything its just that even when i do a ctrl+c the wallet remains unresponsive.

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?

.merge+ 8070 8075

Added

I am curious if XMR will ever support smart contract? So we can bridge tokens onto it and run even defi projects?

Pierre Picard: How can you have smart contracts and still have high transaction uniformity so as to preserve privacy?

Yeap, that's the crux of the issue

Just assume if that were resolved, XMR will have both privacy and smart contracts and then it would boom

PPL can easy hide the money trace like USDT by bridging in-out XMR network

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.

Nah, say let's move in X amount of USDT and move Y+Z out from it

How can you say Y+Z is from X?

If we are having millions of transations daily

You use arithmetic: Y+Z = X.

Stay in XMR. Enjoy the privacy

Why strictly Y+Z=X? We can Y+Z+m=X

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

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."

*miniupnp

jerfo: git submodule sync

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

PierrePicard[m] you might be interested in what Haven protocol is doing

re: private stablecoins, it's an xmr fork

If there were not smart contracts, how would bridging happen?

well you would need *some* extra capability but nothing like what is usually considered a "smart contract" system. for example, wBTC

LyzaL: Most ppl don't bother separate tokens just for privacy. "wrapped USDT" is much more appealing for its wide adoptions

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

can't believe you jsut said USDT was appealing

LyzaL: hmmm, maybe the words are not accurate lol

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

Yeah, I felt the janky part of secret network. wXMR is nothing else that I can find, nevertheless

@selsta thanks!

Just checked haven protocol. Sad that it is too shallow :(

yep, that's why network effect is so important

haven's dev competence is pretty questionable twitter.com/sethforprivacy/status/1410420794879062019

eh, not just competence - integrity twitter.com/sethforprivacy/status/1458633508537131010

Synthetic assets are notorious in many projects

I don't quite buy in the concept

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

Still, I am relying only on CEX without KYC for XMR to hide money traces

But this road is coming to an end when more and more CEXes are closing down no-KYC/withdrawal limits

i think worrying about kyc is pointless. my bank knows I xfer'd money to an exchange

nah, it is very important if you get your money directly from XMR

Haveno and atomic swaps both being actively worked on -- it's def a recognized problem. Bisq and LocalMonero are not exactly optimal

And exchanging XMR to popular cryptos is a must before you can get it into your own bank account

depends on your jurisdiction -- there's still Kraken if you're not in the UK

yeah kraken still worksforme

maybe not for long, but so far no signs of other changes\

yeap, the road is still to the end but as I say it is close

* is still not to the

not sure any of this is -dev material

tru

Anyway, we need a "pure dex" solution for exchanging XMR

isn't that what haveno are working on?

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.

so it's a traditional marketplace like crigslist or ebay

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

since trades are literally person2person, I dunno if I'd use an automatically matched partner

I'd want to know more about who I'm dealing with

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

Don't know how RUNE works out for XMR exchanges

which brings up my other concern: sending randos money through zelle cashapp etc actually seems way more sus than just using an exchange

The automatic build of my PR from about 1 hour ago by GitHub produces 2 errors that I am not able to interpret

Maybe somebody who knows more here could have a look: github.com/rbrunner7/monero/actions/runs/1487279224

PR is this here: monero-project/monero #8076

<rbrunner> "Maybe somebody who knows more..." <- Just wondering, are depreciation warnings important for monero? There's 6 of them in that workflow.

At least 6 actually.

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

I think the issue is somewhere in wallet2.cpp

As far as I can see the deprecation warnings are caused by some Trezor code. No idea about those.

What really confuses me about the compilation errors is that they only occur on MacOS, not on Linux, and not on Windows

Maybe it's a known problem, maybe even with a PR waiting already. selsta usually has the overview :)

I think MacOS' time_t is different from Windows and Linux's

Is there a particular line in the error messages that lets you suspect it could have something to do with time_t?

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.

"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."

There are a couple spelling mistakes in the keyvalue_serialization*.h.

serializible_type instead of serializ**a**ble_type and varialble instead of variable lol. Gonna fix them myself now.

rbrunner yeah you should use int64_t or something instead of time_t, probably. in the rpc

tho MacOS SDK shows time_t is just a long, same as any posix system

uint64_t

that's used for other timestamps already, just use that