<m​onerobull:matrix.org> you guys should really just try out haveno

<r​avfx:xmr.mx> Been doing that since LM dead lol, it just work™️

<r​avfx:xmr.mx> All my partners have other things to do that sit in front of computers

<r​avfx:xmr.mx> they only seam to use phones

<g​ooglemozilla:matrix.org> I take everything I said back. Sorry mbull. Bisq security deposit is ~$200 in BTC.

<m​onerobull:matrix.org> lmao

<g​ooglemozilla:matrix.org> It has increased since I last checked.

<m​onerobull:matrix.org> >to use bisq you will only require a small loan of a million dollars

<m​onerobull:matrix.org> it just straight up doesnt make sense to buy BTC and then XMR on bisq

<m​onerobull:matrix.org> it is quite literally cheaper to buy USDT and then buy XMR on ogre

<m​onerobull:matrix.org> and you are less likely to get your house raided bcs the CEX sees your coins going to ogre, not some guy who will do what knows what with them

<g​ooglemozilla:matrix.org> Personally, I still think that doing BTC/ETH on CEX and then switching to XMR through Serai is the easier option.

<m​onerobull:matrix.org> nah

<m​onerobull:matrix.org> ltc will be better

<m​onerobull:matrix.org> btc takes too long and ETH can get really pricey

<m​onerobull:matrix.org> btc takes too long and ETH can get really pricey too

<g​ooglemozilla:matrix.org> Why? ETH fees are almost free when not dealing with contracts.

<m​onerobull:matrix.org> depends on how its implemented on serai

<g​ooglemozilla:matrix.org> Assuming Serai supports L2 networks.

<m​onerobull:matrix.org> i know serai has eth smart contracts

<m​onerobull:matrix.org> but those might only be for sending not receiving

<r​avfx:xmr.mx> Swapping XMR to serai will be nice indeed.

<r​avfx:xmr.mx> But still extra swapping, time and fee to convert XMR to cash.

<r​avfx:xmr.mx> I personally do prefer use ETH if I have choice between BTC and ETH, at least ETH, I can plan my schedule ahead

<g​ooglemozilla:matrix.org> Will Serai be ETH L1 or L2?

<m​onerobull:matrix.org> eth L1 at launch

<g​ooglemozilla:matrix.org> supporting*

<g​ooglemozilla:matrix.org> Will Serai be ETH L1 and L2?

<m​onerobull:matrix.org> ETH, BTC, XMR, DAI

<m​onerobull:matrix.org> (dai on eth l1)

<r​avfx:xmr.mx> Remembering that time when I walked in the middle of not my city for 4 hours waiting for the bitcoin to confirm... so I can get cash lol

<m​onerobull:matrix.org> that time i waited 45 minutes for 2 btc confs

<m​onerobull:matrix.org> (it was the last time i used bitcoin)

<r​avfx:xmr.mx> That's nothing

<r​avfx:xmr.mx> My record was evicion lol

<r​avfx:xmr.mx> That time when you use max fee as usual and someone manage to time your sending of bitcoin right before a massive surge

<r​avfx:xmr.mx> Another time I did a unstoppable and the corn was stuck for 8 hours... I needed to be back online 12H after to "claim a refund"

<g​ooglemozilla:matrix.org> ETH L1 transactions are extremely expensive for smart contract interactions. The cost of swapping on ETH L1 now is $34.65, while Arbitrum transactions are approximately $0.001 to $0.01, depending on network traffic.

<m​onerobull:matrix.org> yeah

<r​avfx:xmr.mx> It's why I want to ideally only deal with XMR as far as money go.

<r​avfx:xmr.mx> Other coins only when I flat long them

<m​onerobull:matrix.org> pretty sure arbitrtum is a candidate for integration after launch

<g​ooglemozilla:matrix.org> I'm looking forward to the mainnet launch (without audits) later this month.

<g​ooglemozilla:matrix.org> That is, the release candidate.

<g​ooglemozilla:matrix.org> Vitalik's probably going to use Serai - that'll be great publicity for Monero.

<p​reland:monero.social> I have only ever used actual bitcoin once; I had bought around $100 worth of bitcoin before the price jump in 2021 which brought it up to around 138

<p​reland:monero.social> I decided that I should send it off-exchange for security because “that’s how real people do it”. Bad mistake, because this was during the bitcoin boom, and transaction fees and times were exceedingly high.

<p​reland:monero.social> I sent it to my exodus wallet, and then ended up sending it back onto the exchange in shame because I couldn’t afford the fees to use it for anything else. The cost of that little endeavor was basically all of the gains.

<p​reland:monero.social> After that I realized that Bitcoin wasn’t actually feasible to use; it would take me many years to eventually find Monero though 😂

<g​ooglemozilla:matrix.org> Is Monero vulnerable to the same problem if its usage and price are equivalent to those of Bitcoin?

<r​avfx:xmr.mx> At least monero block size are variable and will grow with demand.

<r​avfx:xmr.mx> Surge will increase the fee but then the block will grow to eat the backlog

<r​avfx:xmr.mx> That got tested (and fixed) during last March stress test

<p​reland:monero.social> My concern (which I’ve mentioned on and off for a while) is *how much* can it grow before we start having larger issues?

<p​reland:monero.social> Because Monero is not Bitcoin: it is going to have a *lot* more transactions going on if/when things start taking off

<r​avfx:xmr.mx> Well, the main issue seam to be the RPC part of the nodes.

<r​avfx:xmr.mx> Specially **wallet nodes**, get hammered harder when demand grow.

<r​avfx:xmr.mx> That will have to be somewhat optimized or the system have to be used in more decentralized way.

<p​reland:monero.social> Tbh imo it would be wise for us to remove the wallet-node separation and make the node light enough to be ran by anyone, even with a cell phone

<p​reland:monero.social> Though that would have unique issues for scalability too

<r​avfx:xmr.mx> Well, the phone don't have the storage capacity

<r​avfx:xmr.mx> most phones**

<p​reland:monero.social> Scalability sucks because you have to be perfect, because your imperfection *is* your scalability

<r​avfx:xmr.mx> non, wallet would have to connect to more random safe nodes.

<r​avfx:xmr.mx> Or wallet user maintain his own node

<r​avfx:xmr.mx> Instead of 10000 wallet trying to RPC one node

<p​reland:monero.social> This could be addeessed through some magic trick encryption thing (I forgot the name of it)

this has been a problem i've wondered about for a long time. even if you don't hand over view keys for wallet scanning, you then incur lots of data costs to pull blocks and scan the chain locally.

<p​reland:monero.social> Ik it’s a controversial opinion to have, especially since we are pretty far ahead of a lot of other chains, but Monero’s main issue atm is scalability, in terms of storage space, bandwidth, and latency. These are all problems that we unfortunately inherited from our “upstream” blockchain roots.

<r​avfx:xmr.mx> It's the same problem for all the blockchains.

<r​avfx:xmr.mx> The blockchain have to be stored somewhere.

<r​avfx:xmr.mx> Light wallet can help, but you need to run a vps somewhere (or host your own)

<g​ooglemozilla:matrix.org> ArcticMine solved this problem.

<g​ooglemozilla:matrix.org> ArticMine solved this problem.

<g​ooglemozilla:matrix.org> I think he mentioned that in the future, advancements in storage, RAM, and other components will lead to improvements in scalability, making it no longer an issue.

<p​reland:monero.social> I keep hearing this mythical name, and I hadn’t even heard of him before today despite me 1. Trying for a while to figure out the members of Monero Core using publicly available knowledge, and 2. Looking into how we could make Monero more scalable

<p​reland:monero.social> Although ig I must’ve seen his name in the one monero meta folder with all the signing keys

yeah, that's the downside. and some people like to wave off the concern and effort of setting up a vps, but imho, it's non-trivial. most providers aren't going to offer the 200+gb needed for storage, and then you have to consider datacaps, how to pay them, which company to trust, what country you want your server in, etc etc. it's a whole rabbit hole.

<r​avfx:xmr.mx> Storage is almost free

<r​avfx:xmr.mx> Bandwidth is free

<r​avfx:xmr.mx> latency is not a problem

<g​ooglemozilla:matrix.org> I highly recommend watching this talk on scalability by him:

<g​ooglemozilla:matrix.org> youtube.com/watch?v=9RJ5HDmuucY

<p​reland:monero.social> Which I would agree with….if the blockchain didn’t grow et infinitum, and the bandwidth wouldn’t grow to absurdly high levels which would need to be multiplied by the number of nodes, which *speaking of which*, the latency issue would become an issue if Musk gets his way and we have 1 million people on Mars and some of them want Monero (ik its far fetched, but we shouldn’t<clipped message>

<p​reland:monero.social> explicitly lock this out)

respectfully, that's the hand waving i mean. storage is not almost free. there is a literal price on it. BuyVM has some of the best prices in north america and most of those instances don't offer 200gb+, and they're almost always sold out

<p​reland:monero.social> Will do 👍

i'll concede that while bandwidth is not free, the caps are generally big enough for a monero-specific node (avg 1tb/node/month)

latency is not the problem, jurisdiction is. i'll speak for myself - I don't like european hosts. I prefer sticking to the USA.

<p​reland:monero.social> Latency shouldn’t be an issue so long as the most recent node can be consistently propagated before the next

<p​reland:monero.social> It’ll be the secret final boss of scalability

yeah, i guess that's a good point - i've never had latency issues so I never thought about propagation. I see why it was brought up now.

<r​avfx:xmr.mx> Main problem is that RPC is not really multithreaded, so a full node running on a 192 cores Epyc will be saturated with 0% CPU usage (aka RPC taking 100% of one or two cores)

<r​avfx:xmr.mx> that's what brought nodes down during the stress test

<p​reland:monero.social> Why wasn’t this realized sooner???

wow. yeah, great call out.

<r​avfx:xmr.mx> We did not have such a stress test before

<r​avfx:xmr.mx> That is fixed many way, more people run nodes

<r​avfx:xmr.mx> Wallet can use more nodes (I think feather is the best for that)

<r​avfx:xmr.mx> Or Wallet use there own node (like monero-gui), in that case no problem but it's going to use storage on your system

<r​avfx:xmr.mx> or of course, improve the code so it's more thread friendly

<p​reland:monero.social> I guess not, but if the current consensus for network operations relies somewhat heavily on having concurrent RPC calls to nodes (translation: more than one user per node) then the RPC being multithreaded is somewhat implied, at least I would’ve thought so

<p​reland:monero.social> Hmm

<p​reland:monero.social> Maybe I’ll take a look at that code later; is it still not multithreaded?

<r​avfx:xmr.mx> I did not look at the code

<r​avfx:xmr.mx> But I did look at my node metrics

<r​avfx:xmr.mx> There is some locking somewhere or something idk

<p​reland:monero.social> Tbh I absolutely suck at multithreading, but I’ll see what it currently looks like

<r​avfx:xmr.mx> If everyone did run there own node that would be a no issue

<r​avfx:xmr.mx> But it's too much to ask everyone to have a node I think. And it's nor normies friendly enough

<r​avfx:xmr.mx> s/nor/not/

<g​ooglemozilla:matrix.org> Will Cuprate be able to fix the multithreading problem?

<r​avfx:xmr.mx> Maybe, you are asking the wrong person

<g​ooglemozilla:matrix.org> @boog900:monero.social

<s​yntheticbird:monero.social> It's more complex than just putting more threads. but yes, Cuprate should bring parallelism improvements

<r​ucknium:monero.social> Severing data to wallets and verifying the blockchain are two different tasks that even two different programs can do. Bitcoin and its cousins do it by delegating the wallet-serving task to an Electrum server

<g​ooglemozilla:matrix.org> Is Cuprate currently capable of hosting nodes, or is it still in active development?

<r​ucknium:monero.social> Serving, not severing*

<r​ucknium:monero.social> I suggested to cuprate devs to architect things so that the tasks could be separated. I think they are trying to do that.

<s​yntheticbird:monero.social> It is still in active development and not ready for test release. But cuprate is already capable of serving p2p network and syncing blockchain

<s​yntheticbird:monero.social> boog I think you were writing but the window as too low, sorry if I cut your response

<g​ooglemozilla:matrix.org> Is Cuprate simply a rewrite of the existing node implementation? If so, could using a tool like TRACTOR help accelerate development?

<g​ooglemozilla:matrix.org> darpa.mil/program/translating-all-c-to-rust

<s​yntheticbird:monero.social> OMG NO IT ISN'T

<r​avfx:xmr.mx> hmm, I like where where the tractor come from lol

<r​avfx:xmr.mx> hmm, I like where the tractor come from lol

<b​oog900:monero.social> I do have plans for a separate binary just for RPC, although we aren't doing that currently

<g​ooglemozilla:matrix.org> Sorry for these naive questions. I'm having trouble finding reliable information on Cuprate due to its limited documentation.

<b​oog900:monero.social> No, its a complete different design

<s​yntheticbird:monero.social> In an ideal world where we value performance over everything, Cuprate would have had to be architectured as one thread, do everything and each thread have its own database and async runtime. but that would have been... horrible

<s​yntheticbird:monero.social> and only useful in case of high parallelism.

<b​oog900:monero.social> I dunno how would you handle an incoming using multiple threads?

<s​yntheticbird:monero.social> like Actix, one real time thread dispatching requests around

<s​yntheticbird:monero.social> like Actix, one real time thread with the socket dispatching requests around

<s​yntheticbird:monero.social> I think nginx had some docs on that pattern

<b​oog900:monero.social> *incoming block

<b​oog900:monero.social> This is probably only beneficial if requests are independent, when verifying a block we dispute txs to be checked over multiple threads using `rayon`.

<b​oog900:monero.social> *distribute

<s​yntheticbird:monero.social> I was mainly talking about RPC

<s​yntheticbird:monero.social> huh

<s​yntheticbird:monero.social> matrix hello ? are you okay

<s​yntheticbird:monero.social> i was talking about RPC not P2P. This one cannot be independent.

<s​yntheticbird:monero.social> You would have a P2P pool that would validate and interact with the network and *feed* the RPC threads that all have their own txpool/database

<b​oog900:monero.social> OK yeah that makes sense

<s​yntheticbird:monero.social> I know, this is completely overkill compared to a different binary, all you do is avoiding context switch

<s​yntheticbird:monero.social> well actually no

<s​yntheticbird:monero.social> nvm what i said

<s​yntheticbird:monero.social> each thread having their own database make them independent, an rpc binary would still fetch at p2p binary database, not duplicating it

<b​oog900:monero.social> LMDB supports multi-process access, but yeah I don't know if avoiding the context switch is worth not being able to use multiple thready to get data for a single request

<b​oog900:monero.social> LMDB supports multi-process access, but yeah I don't know if avoiding the context switch is worth not being able to use multiple threads to get data for a single request

<s​yntheticbird:monero.social> well in practice, independent actors have always been the pattern of choice for serving requests, because the performance are predictable (thread local). relying on multiple threads means relying on OS scheduler and runtime scheduler. Do i think it's worth it? absolutely not, would be horrible to code and get right, and current architecture is already excellent enough.

<k​ewbit:matrix.org> It would be great if a phat ass server could have 1 docker instance doing the righting and have 9 others just reading the same volume

<k​ewbit:matrix.org> It would be great if a phat ass server could have 1 docker instance doing the writing and have 9 others just reading the same volume

<k​ewbit:matrix.org> But by simply reading you’re locking the LMDB file right?

<k​ewbit:matrix.org> I wonder if there is a workaround

<s​yntheticbird:monero.social> One database, multiple threads.

<s​yntheticbird:monero.social> One P2P binary, multiple RPCs

<s​yntheticbird:monero.social> One database docker, 9 rpc docker

<s​yntheticbird:monero.social> We're really just onto the same resource contention.

<s​yntheticbird:monero.social> I think it might bring performance improvements but just because of the scheduling

<k​ewbit:matrix.org> What do you need the RPC for

<s​yntheticbird:monero.social> making people wallet works

<k​ewbit:matrix.org> Because I am doing something interesting with crates.io/crates/monero-wallet

<k​ewbit:matrix.org> Memory guarded multi instance

<k​ewbit:matrix.org> I’ll I’ve been working on it instead of Haveno for a bit cause cause woodser needs it

<k​ewbit:matrix.org> I’m adding Dart FFI hooks too, so you don’t need to start a http server for each lol

<k​ewbit:matrix.org> Cause I just love dart

<b​oog900:monero.social> I would strongly recommend against that and I would point you to monero-serai/monero-oxide or kayabanerve's monero-wallet: github.com/serai-dex/serai/blob/dev…p/networks/monero/wallet/Cargo.toml which is now going to need a name change :(

<g​ooglemozilla:matrix.org> Has this been audited?

<b​oog900:monero.social> Is currently being audited: ccs.getmonero.org/proposals/monero-serai-wallet-audit.html

<g​ooglemozilla:matrix.org> If I recall correctly, the CCS funding for this audit has recently been completed. So no audits.

<k​ewbit:matrix.org> Oh! It’s been done already?

<k​ewbit:matrix.org> Interesting

<k​ewbit:matrix.org> I’ll check the spec

<k​ewbit:matrix.org> I had a specific operational philosophy for this one

<k​ewbit:matrix.org> The audit is 1000 Xmr

<k​ewbit:matrix.org> The fuck

<k​ewbit:matrix.org> 👃👃👃

<b​oog900:monero.social> It's way more work than you realize

<k​ewbit:matrix.org> Can you smell that

<k​ewbit:matrix.org> No I completely get it,

<k​ewbit:matrix.org> I realise

<k​ewbit:matrix.org> But 1000

<g​ooglemozilla:matrix.org> I can smell you being jealous. You now realize that you could've scammed more from your CCS. Oh well.

<k​ewbit:matrix.org> That’s an absolute piss take

<k​ewbit:matrix.org> I don’t get jealous

<k​ewbit:matrix.org> It’s one of my Devine personality traits

<b​oog900:monero.social> + in monero-wallet you are pulling in deps that are completely unrelated to Monero. For example the `bulletproofs` crate, is not the same as Monero's bulletproofs

<k​ewbit:matrix.org> Thanks I’ll revise

<g​ooglemozilla:matrix.org> It's called economics. The supply of people who are knowledgeable and willing enough to audit Monero is extremely small. Therefore, the compensation is large.

<k​ewbit:matrix.org> Fair play, maybe I undervalued my own CCS, good think to take away for future freelance stuff

<g​ooglemozilla:matrix.org> May God have mercy on all the clients of your future freelance work.

<s​yntheticbird:monero.social> LMFAO

<k​ewbit:matrix.org> I was quite excited about learning this, I may just do it anyway for the sake of learning more detail in rust, and the math side of crypto but which is the one that’s Audited I’ll link that

<k​ewbit:matrix.org> Hey hey! Play nice I haven’t done too badly this year

<s​yntheticbird:monero.social> waiting for le ChatGPT generated audits on pedersen vector commitments

<b​oog900:monero.social> how much time have you spent on it

<b​oog900:monero.social> (monero-wallet)

<k​ewbit:matrix.org> Bootstrapped it but mostly research

<b​oog900:monero.social> define Bootstrapped

<k​ewbit:matrix.org> For me that’s planning what libraries I need, planning the project layout

<k​ewbit:matrix.org> Modules layout

<k​ewbit:matrix.org> Deciding if something should an abstract module entirely

<k​ewbit:matrix.org> Of modules don’t exist, how am I going to formulate those crypto functions, finding C++ hooks for the things that are just too hard for me to figure out

<k​ewbit:matrix.org> If modules don’t exist, how am I going to formulate those crypto functions, finding C++ hooks for the things that are just too hard for me to figure out

<k​ewbit:matrix.org> I planned and implemented the FFI so I can later hook into dart

<k​ewbit:matrix.org> Setup how the default config file will look if being used as a CLI or RPC without params

<k​ewbit:matrix.org> Like daemon address

<k​ewbit:matrix.org> So not mega far in but I work 3 times quicker than the average person

<k​ewbit:matrix.org> Which company is doing the audit?

<g​ooglemozilla:matrix.org> Cypher Stack

<k​ewbit:matrix.org> Knew it

<k​ewbit:matrix.org> lol

<k​ewbit:matrix.org> Fair play tho

<k​ewbit:matrix.org> Again

<k​ewbit:matrix.org> :D

<3​21bob321:monero.social> They do most of them

<s​yntheticbird:monero.social> They are very good at them

<s​yntheticbird:monero.social> Tho no one can beat Zellic imo

<b​oog900:monero.social> kewbit.org: did you use chatGPT to build monero-wallet

<b​oog900:monero.social> or even a bit of it