vtnerd the issue is I am able with the UI to send the funds when tx is confirmed while monero-lws does not seem to be ready so it makes a crash and you have to refresh the UI

vtnerd the crash occurs after calling get_unspent_outs

<vtnerd> Lws crashes? What version are you running? Can you provide logs of the server? Post them to a GitHub issue if possible, much easier to discuss and track than this channel

vtnerd no it is not lws, it is mymonero-web-js

<vtnerd> Yikes. I'm only vaguely familiar with that, and I think it's no longer being maintained. Do you have a rough idea on where it's crashing?

vtnerd I just told you the UI make it possible to spend the funds whereas monero-lws does not seem to be ready, the UI crash after calling get_unspent_outs

vtnerd I have the same issue as plowof, for some reasons it takes lots of time to monero-lws to be able to spend the funds after the tx is being confirmed, I wouldn't want to update get_address_info and get_address_txs endpoint if this time did not exist

<vtnerd> @plowsof:monero.social: do you have the same issue? With what frontend?

<vtnerd> There's a 10 block lock time after funds are received. This is a monero protocol enforcement, lws must wait. Is the spend funds issues after the lock time?

<plowsof:matrix.org> johny__ ive found that i have to wait a long time to where i think 'does this even work / is it broken?' when i receive funds and waiting to spend them - eventually though im able to send

vtnerd I had the issue even 10 blocks after

plowsof> if this is specifically about monero-lws being slow when funds are unlocked and should be spendable (balance taking time to update etc) then yes, same issue. is this a known issue vtnerd?

plowsof> johny_ im using a beta wallet atm called skylight wallet thats connected via tor to my own monero-lws instance , sgp_ shared it recently, you would need a google play store account to join the beta :( ive not used my.monero personally

vtnerd "I think it's no longer being maintained" what is that? it does not mean monero-lws does not issue because it is being maintained, from my point of view the issue comes from monero-lws when debugging, at one point I see output without spend_key_image property from get_unspent_outs endpoints...

<vtnerd> The ui is crashing, that part is unmaintained. Seeing no spend_key_image field is possible when the received output has yet to be listed in a ring (unspent). The balance on that skylight app is likely waiting until it's unlocked, although Id have to use it to verify

vtnerd if you think everything is ok for get_unspent_outs endpoint then get_address_info and/or get_address_txs have to be updated so the UI won't let me spend the funds and crash

<vtnerd> Actually I peeked at skylight and I know what the problem is there. The backend is updated nearly instantly if --sub is used, however the frontend is polling at roughly 30 seconds or 20 seconds at best. This causes a noticeable delay that can be instant if restarted

<sgp_> Skylight code for reference: github.com/magicgrants/skylight-wallet

<vtnerd> We need to work on an instant notification channel (probably websocket). Lws switched to boost::beast so this won't be too bad

vtnerd I am not talking about 30sec issue, sometimes even 20min after I was still not able to spend it

<vtnerd> Yes, so 10 blocks passed after the output was received, and it took another 20 minutes before it was spendable?

<vtnerd> Meaning roughly 40 minutes from first receival?

vtnerd there is no rule, sometimes in my test, I have been able to spend it quickly after being confirmed

<vtnerd> That's not possible, the monero network would block it. Unless your debugging which output the mymonero-js is using it's likely using another output, giving the impression that it spends the one just received

I think you try mymonero-web-js yourself, I did my best to describe the issue, I wouldn't spend that much time if there were no issue

at the moment I can't use monero-lws because of this issue, that's what I can say

<tallhatdoug:synod.im> mrelay.p2pool.observer/m/synod.im/LdDBsRGQksaeSyWJSbQLobFy.png (mining.png)

<tallhatdoug:synod.im> LET'S GET THAT LUCKY #7 !!!

@tallhatdoug:synod.im got details/api/viewkey to get listed on blocks.p2pool.observer/pools / blocks.p2pool.observer/proofs?

vtnerd can you explain me why get_address_info give me locked_funds 0 with pending tx and total_received is the amount of pending tx?

<tallhatdoug:synod.im> might need to launch my own mirror of xmrchain, seems to be getting hammered with traffic lately?

<tallhatdoug:synod.im> what y'all think?

<tallhatdoug:synod.im> DataHoarder appreciate the credit brother 😎

use p2pool.io/explorer

01:57:14 <+br-m> <tallhatdoug:synod.im> DataHoarder appreciate the credit brother 😎

yep but got API that lists found blocks with id and height at least? (or alternatively viewkey, I'll scan blocks myself on blocks.p2pool.observer)

when I checked you only had the stats, which only lists block heights

<tallhatdoug:synod.im> tallhatdoug.com/stats

that only lists block heights, I'd need id + height

<vtnerd> johny_: If it's pending, lws doesn't report it via rest API. This is a known limitation of lws. The locked funds are zero because it hasn't picked it up yet.

<vtnerd> Total received is basically useless as it's the total incoming received without accounting for any spends (because the backend cannot verify spends). This field would be removed if redone again; it's present for historical reasons

(or viewkey, and I scan everything directly from chain data, as I do for SupportXMR / MoneroOcean / HashVault / xmrpool.eu and Qubic)

<tallhatdoug:synod.im> I'll add the id hold up

vtnerd a known limitation... but then how can you know when you are able to spend the funds if locked_funds is always 0.... that's not the behavior of official mymonero api

vtnerd and I think it is better to not return an information instead of returning wrong information

<vtnerd> Locked_funds should be nonzero when outputs are locked, and zero if none are locked. They are locked for 10 blocks unless someone chose a specific time or block. I _think_ there is a bug in lws when reporting the temporary lock, only the user specified lock is counted. but this is irrelevant as it doesn't tell you _which_ outputs are locked, you must do manually inspection regardless.

<vtnerd> You determine if funds are spendable by calling get_unspent_outs and computing the key image. If the key image isn't in the known set of candidates, then it's spendable if the unlock_time field passes. This field passes if the block height or timestamp has past, and if the output is 10 blocks old.

<vtnerd> johny_: Who cares, those fields are nearly pointless for frontends computing things, I guess we could remove them but that will take some time

<vtnerd> The problem is that lws can't compute the balance unless the not-yet-released fcmp++ balance key is used. So a lot of the fields that appear useful at a glance aren't really that helpful until all outputs are scanned for spending

vtnerd pointless? the result of all of that is I cannot use mymonero-web-js as frontend and you are advertising mymonero on your github

vtnerd I don't know know which web frontend I could use, nothing written on the github

<vtnerd> Yes, the total_received field is nearly pointless. It tells you you've got a valid account but little else. The locked_funds field doesn't help with computing the real or unlocked balance either. And when spending you definitely have to inspect each output because you have to identify unspent and unlocked outputs

<vtnerd> johny_: There's lwsf which implements the c++ wallet API of monero. Lwsf also works with a fork of monero_c and dart, such that you have a dart or c API that can be used. There's the aforementioned skylight wallet which is using lwsf/dart/c as it's backend. The mymonero-web-js is no longer being maintained afaik, and lws will [... too long, see mrelay.p2pool.observer/e/47G4zMgKbHVEc0p3 ]

<vtnerd> Openmonero also had a fork of the mymonero web stuff, I'd have to dig around to find it again

vtnerd I wasn't able to make openmonero work but I have been able to make mymonero work with monero-lws, I only have this issue, I don't know what I am going to do, create mymonero-web-js fork or monero-lws fork

<vtnerd> There's likely nothing to be done lws backend. If you find a bug, just issue a pr

<vtnerd> The issue of delay you keep mentioning is difficult to pin down because of the lock time and poll intervals

<vtnerd> I haven't really gotten a clear response to indicate that anything lws needs changing

vtnerd "there's likely nothing to be done lws backend" I am not sure about that as mymonero works fine with mymonero official api but it does not work fine with lws and mymonero offcial api is going to be down soon

<vtnerd> the bugs seem to be on the js frontend. The caveat that I could persist an empty array for spend key images (the likely reason for js crash), but the frontend shouldn't just crash on such response.

<vtnerd> I believe mymonero also added a secret API for immediate notifications, whereas lws has no such support yet

vtnerd yess the frontend shouldn't crash on such response but it shouldn't let you waste time trying to make a tx you cannot do that's why I think locked_funds information is important

<vtnerd> Each output has locked funds information that is returned. That field+block_height is how the frontend determines the real unlocked amount. This number cannot be computed from total_received+locked_funds, which is why Ive been trashing them.

vtnerd I understand your point but get_spent_outs is only called after clicking on send button so it is too late to know if you can spend or not your funds.... isn't it possible to fill locked_funds property from get_address_info with each output?

<vtnerd> johny_: yes, lws has a bug which will be fixed shortly where locked funds doesn't include the standard lock time. The mymonero app could be using this before calling unspent_outs as a filter for the ui, but ultimately get unspent outs has to be called before sebd

<vtnerd> *send. I don't know if this will fix whatever problems you seem to be having

vtnerd you mean soon locked_funds from get_address_info endpoint will not be 0 anymore with a pending tx?

<vtnerd> It will remain zero with a _pending_ tx as lws will still not report them until they get included in a block. Mymonero API definitely reported things in mempool, and this probably helped locked funds reporting

<vtnerd> Changing that will not be simple

vtnerd so probably the best fix for me is to update mymonero-web-js to calculate locked funds with get_unspent_outs endpoint?

<vtnerd> that won’t help. the spent output won’t show up there either, until it lands in a block

<vtnerd> lwsf just tracks pending txes after it created it, the mymonero team handled this differently with a mempool reporting mechanism

<vtnerd> its possible that the mymonero-web-js does similar tracking, but it sounds like they didn’t based on your reports

vtnerd why can't you call get_unspent_out and you do total_received minus all output to calculate locked_funds?

<vtnerd> you were talking about pending txes previously, I was talking about that

vtnerd I am still talking about the same, fixing my bug...

<vtnerd> I was wrong to be so flippant about total_received and locked_funds, its just annoying because subaddresses ruined those endpoints

<vtnerd> *endpoints -> fields

there is no subaddresses for mymonero app

<vtnerd> yes I know, but lwsf supports them and those fields are somewhat useless with subaddresses.

<vtnerd> all of the fields are computed using txes in blocks. pending txes will not show up in any of the fields

<vtnerd> the only workaround is to get the frontend to cache recently generated txes, and treat it as spent. or hack together lws to support pending txes

vtnerd get_unspent_outs is returning outputs even if it is spent...

<vtnerd> Yes, the backend doesn't know when the spend occurs. The viewkey is incoming only detection

<vtnerd> That's why get_address_info returns so much data. To compute the real balance requires key image computation

vtnerd I am still not sure how with the frontend I can calculate locked_funds with monero-lws

you told me to call get_unspent_outs before clicking on send button but I don't know what I can do with this endpoint if it is returning the output spent...

vtnerd it would be great if you could write code sample to calculate locked_funds with your API because I am not sure to understand everything

<vtnerd> I did, there's lwsf already

<vtnerd> I think the problem is that you want lws to do _more_ up the work, when it cant

<vtnerd> It can compute when an output is locked but not spent

<vtnerd> None of the apis indicate which output is locked, the frontend has always computed this in various ways from the unlock_time field

<vtnerd> get_unspent_outs also doesn't include unlock_time which is annoying, but this information can be merged from get_address_txs

vtnerd ok thank you then I am going to check lwsf to fix mymonero but it would have been very convenient if the api could directly return this locked_funds

<vtnerd> Yes, I've pred a fix. It won't tell which outputs are locked just the total amount

<vtnerd> Is that what you needed?

vtnerd yes I need total amount locked

<vtnerd> It will not include pending txes, which I think might be the issue you also wantrd

vtnerd if business logic is complex it is better to put it in the api rather than all frontend to implement it I think

<vtnerd> Yes, every frontend dev wants the backend to do everything. It's not possible with spent vs unspent until the balance key feature goes live, which is a ways off

vtnerd I don't understand why pending tx is an issue because mymonero frontend is already able to show if it is pending with the information he got from the API?

<vtnerd> they aren't the same backend. I could implement something like mymonero had, but it was a bit messy in how it worked

vtnerd I am telling that mymonero-web-js + monero-lws is already able to show pending tx, I can see it when I was trying it

I mean if mymonero frontend is already able to show pending tx with the data from your API then I don't know why is it a problem for you to get this info

<monerogurgi:matrix.org> Thinking about moving from a JSON config file based approach for github.com/HennyH/dosiero to something like below - any opinions/suggestions?

<monerogurgi:matrix.org> mrelay.p2pool.observer/p/ipzy2cgKY1pWMHZ5/1.txt (code snippet, 7 lines)

Can anyone guide me to monero-pools freenode logs?!

2019-2020 time period chats

Hello

<fungible.:matrix.org> MRV: seems like only monero, monero-community, monero-dev, monero-gui, monero-pow, monero-research-lab and monero-site are on those logs from back then, monero-pools logs not stored, similar as currently offtopic and other channels are not on those logs, but who knows, with i guess f_uk making a comeback rn in /r/xmrtrader (a [... too long, see mrelay.p2pool.observer/e/-Jqc38gKS1BrR0tQ ]

Yeah for past hour I am trying to stumble upon the logs but in vain. I clearly remember reading the logs in 2019 cause I am in Asia and to get to know what was being talked while am asleep.

<fungible.:matrix.org> that's around the time mining algo switched over to randomx, so i guess those discussions must have been regarding asics that were getting in the network or something along those lines, hard to tell tbh

probably about antminer's stealth ASIC mining

it's hard to not notice them, they dominated the network at the time

<snifflz1:matrix.org> Yo

<fungible.:matrix.org> o/

hi

<ravfx:xmr.mx> \o/

MRV I have the monero-pools logs locally, starting from October 2018. Do you still need them?

<reaster:matrix.reaster.dev> idk how you mine, but in case you're searching a good pool, i personally use this one: www2.aterx.com/1/pool.html

<reaster:matrix.reaster.dev> it's a pool using p2pool behind (so the benefits of p2pool of not contributing to only one big 51% pool, and remove the assle of setuping p2pool yourself)

<reaster:matrix.reaster.dev> and take 0% (it wouldn't be fair anyway)

<reaster:matrix.reaster.dev> i really like theses kinds of pool, made on top to p2pool, to make it easy for people to mine on p2pool,

<reaster:matrix.reaster.dev> if you ever know others similars i would be curious

<preland> I am also curious about that; is there anything that confirms that they are actually built on p2pool?

<ofrnxmr:xmr.mx> @preland: Yes

<ofrnxmr:xmr.mx> Look at p2pool mini's leaderboard

<ofrnxmr:xmr.mx> Also look at the p2pooler repo, which is xnrig-proxy fork that does the pplns for their pool

reaster: why

this is like a layered pool

pool on top of a pool

<ofrnxmr> because you benefit from the other p2poolers hashrate

<ofrnxmr> A small 400kh pool rarely finds blocks. Bt basing on p2pool, the payouts are much more often

<ofrnxmr> If they based on a centralized pool, would be contributing to centralized pools net share. By using p2pool, they increase the p2pool network share

<ofrnxmr> Also, it should be obvious by looking at p2pool miners hashrate, that there are either botnets or.. botnets already mining there. A small pool mining on p2pool isnt bad, in comparison

i see

Note this pool could still be doing selfish choices or other collusion even if they use a public p2pool as hashrate backend

<ofrnxmr:xmr.mx> Of course, its still centralized

<ofrnxmr:xmr.mx> Its just using p2pool mini as its pool, instead of running their own pool or using a centralized pool

yeah, pretty good for small pool block consistency

<soulexemar:matrix.org> anyone here following zerofi protocol?

<soulexemar:matrix.org> new crosschain bridge with wrapped xmr on eth, they’re showing developments on github every minute lol

<soulexemar:matrix.org> if they can truly ship it will it’ll likely moon

this is not shitoken discussion room

^

it'll likely up my ass

<soulexemar:matrix.org> DataHoarder: shitcoin? lmao

shittoken

nobody here cares about the moon

<soulexemar:matrix.org> Cindy: hey room temperature insolent pea brained individual moron, i was talking about the success of the project. it’s a monero bridge not a “shittoken”

it's not a monero bridge

ETH and XMR are both incompatible chains

and wrapped XMR is just a token based off of the value of XMR

wen doge xmr

TO THE MOOOOON

to the room, TO THE ROOM! not the moon!

<soulexemar:matrix.org> Cindy: read their whitepaper first then base your arguments on that

is this xmr? yes or no

you need some level of centralization for wrapped XMR

aka. someone has to literally be the bank and hold all the reserved XMR that is tied to each wrapped XMR token

because XMR and ETH are both incompatible

imagine if SOMEONE were to rugpull by sweep_all

then your wrapped XMR is worthless

<elongated:matrix.org> Yah everyone here wants to xmr pegged to dollar > <Cindy> nobody here cares about the moon

<snifflz1:matrix.org> @elongated:matrix.org: I don't think so

i'm not making this stuff up btw, wrapped XMR is literally just someone holding all the XMR in one wallet

<elongated:matrix.org> Hopefully we get 1 xmr = 1 usd a stable price to transact

1 xmr = $1000

<snifflz1:matrix.org> @elongated:matrix.org: Ummm how about no

<elongated:matrix.org> nioc: Nah, don’t day dream

i don't get why this is news we should care about anyway

why have a token that looks like XMR, but i don't actually own the underlying XMR

<snifflz1:matrix.org> Cindy: I wouldn't buy the shit

it's just like CEX

<elongated:matrix.org> How does WBTC work ? > <Cindy> because XMR and ETH are both incompatible

elongated: most likely the same thing

<elongated:matrix.org> Cindy: Bcoz chain finality for xmr is absurd ? Swappers need 20+ conf

<snifflz1:matrix.org> If you have to wrap a crypto I think it shows the crypto is not working as is

someone holds BTC for you in their wallet, but gives you a token that acts like some sort of certificate

that you "own" the underlying BTC

<snifflz1:matrix.org> Yea and that's ignorant to me. Just but the OG token

yeah it's dumb

<elongated:matrix.org> @snifflz1:matrix.org: Someone can wrap it and sell whenever they like and not wait an hour to finalize sell order after they decide it’s time to sell

"you won't own your XMR and you'll be happy"

CEX's wet dream i guess

<elongated:matrix.org> Give 1 conf finality and you have a working coin

elongated: but this is dumb

<snifflz1:matrix.org> @elongated:matrix.org: Yea but that goes back to what I said earlier that if you have to wrap a token to make it better, the crypto isn't good.

it's centralization

you're acting like a central bank

<elongated:matrix.org> Cindy: If it can be decentralised

<elongated:matrix.org> Or give finality layer asap

somebody has to hold the XMR

or hold the BTC

<elongated:matrix.org> Won’t Serai be similar ?

so it can't really be decentralized, unless you somehow fix that

<elongated:matrix.org> Cindy: Doesn’t fcmp++ allow vaults n stuff ?

<elongated:matrix.org> Is Serai also going to have 20+ conf to swap ?

<elongated:matrix.org> Or trade

<jeffro256> FCMP++ allows transaction chaining, but not really advanced L2 stuff

<elongated:matrix.org> @jeffro256: Ah so another decade for actual defi?

<soulexemar:matrix.org> team told they are skippen centralization which was their initial plan, you can keep track of their developments in their TG chat pretty cool > <Cindy> you need some level of centralization for wrapped XMR

<snifflz1:matrix.org> @elongated:matrix.org: You want defi on Monero?

<jeffro256> Prob never w/o some hard fork to allow for conditional signatures a la HTLCs

defi will probably conflict with the privacy features of monero

<elongated:matrix.org> @snifflz1:matrix.org: Compatible with other chains, yes

it'd probably be the very basic forms

<snifflz1:matrix.org> Cindy: Yea most definitely. That's why it's a terrible idea.

<gan:skhron.org> I assume, it's "valuable" because it's le ETH network?

<xmrsoul:matrix.org> @soulexemar:matrix.org: What’s their Telegram?

<gan:skhron.org> Otherwise, why not TARI for full cycling? 🧌

<jeffro256> Cindy: Not necessarily. Blinded defi exists, but it isn't very performant

<jeffro256> for now

<elongated:matrix.org> @jeffro256: Is it terrible for xmr ?

<elongated:matrix.org> How are we going to have decent swap experience without a finality layer then ?

i see!

<snifflz1:matrix.org> @elongated:matrix.org: XMR is fine as is

i was talking about wrapped tokens, not really swappers

wrapped tokens of coins that are incompatible with each other

<eddie:oblak.be> I agree

<soulexemar:matrix.org> @xmrsoul:matrix.org: @officialzerofi

<jeffro256> @elongated:matrix.org: No need to swap when XMR is global reserve currency ;)

<elongated:matrix.org> @snifflz1:matrix.org: It’s not, try swap xmr to other coin and see the price move while your tx has 20 conf or 1000+ if its some weird cex

<eddie:oblak.be> I don't want to swap xmr to other coins, I just swap it for goods / services

<eddie:oblak.be> I swap other coins for xmr

<elongated:matrix.org> @eddie:oblak.be: Those vendors swap it to other coins, the spread gets worse

<gan:skhron.org> @soulexemar:matrix.org: "Telegram"

<gan:skhron.org> Be a good person, and use your passport for registering the sim 🧌

<gan:skhron.org> kiddie stuff

<elongated:matrix.org> Pubic fucked up monero velocity

<xmrsoul:matrix.org> mrelay.p2pool.observer/m/matrix.org/NbSjhTuazAFUsUZXaKoLyvDM.jpeg (ima_2eb8ca9.jpeg)

<elongated:matrix.org> Without finality layer or that dns patch, exchanges are going to be vary and will need insane conf times

<xmrsoul:matrix.org> Hmm

<jeffro256> What could be nice is a tactic that Zano is doing where they add confidential assets to the L1 protocol in Zano, and on-chain swaps, which have much better liveness guarantees / speed. Then third-parties could slowly swap out synthetic assets for real off-chain assets in something like Haveno with little slippage. That's good [... too long, see mrelay.p2pool.observer/e/q7-a78gKd1F2akx6 ]

<xmrsoul:matrix.org> Someone said “tornado cash 2.0” lmao

<xmrsoul:matrix.org> Zerofi seems cool tbh will dig deeper into it

<xmrsoul:matrix.org> But codes needs to be checked when launched

has anyone actually seen a monero-related account on bsky

or fediverse

everyone seems to flock to elon's shitter

<elongated:matrix.org> nioc: Nah, don’t day dream <<>> I was being conservative only because using 1000 makes the arithmetic very easy

<elongated:matrix.org> nioc: 100, 10, 1 is easier

<elongated:matrix.org> @jeffro256: Zano is pos, they can do those things with finality on their own chain

<jeffro256> They are hybrid PoS/PoW

<jeffro256> Confidential assets / on-chain swaps are completely orthogonal to the consensus algo used

Cindy: used to run one on fedi, but the instance it was on died, for p2pool

<elongated:matrix.org> @jeffro256: Pos and pow are mined separately?

<jeffro256> Wdym mined separately?

<elongated:matrix.org> @jeffro256: Monero pow is prone to reorgs though

<elongated:matrix.org> @jeffro256: Hybrid pos/pow ? Like is it dual mined or pos is adding finality layer

<jeffro256> Some blocks are PoW, some blocks are PoS. The difficulty algo tries to balance it so that the ratio is 1:1

<jeffro256> And block can be PoW, but PoS can defeat PoW by being much quicker if the difficulty allows it to be a PoS. Only some blocks can be PoS

<jeffro256> @elongated:matrix.org: The thing about on-chain swaps is that they are even more atomic than "atomic" swaps. A deep reorg will cause either both sides to fail, or both sides to succeed

DataHoarder: that's sad

there needs to be more of the community outside xitter

<elongated:matrix.org> @jeffro256: So having wrapped token of other coin on xmr itself ? Is that possibile to do in a decentralised way ? Like issue private dai backed by dai ?

<elongated:matrix.org> Would it be possible to have HTLCs on xmr ? Ztrash seems to have something similar to allow integration with near and wider ecosystem

<elongated:matrix.org> Like their near integration

elongated: why do you want XMR to be yet another ETH

<elongated:matrix.org> Cindy: That is what @jeffro256:monero.social was asking for

<elongated:matrix.org> I just want finality layer with cross chain compatibility so users can on/off-ramp without cex

can't they already do that with atomic swaps

<elongated:matrix.org> Cindy: No, it’s one way swap

i feel like this is gonna be something that'll overcomplicate the currency

like people just want something that works

<elongated:matrix.org> Cindy: Xmr can’t depend on cex

for simple transactions, or even the special ones that FCMP++ offers

elongated: you'll be glad to hear that the training wheels are slowly getting screwed off by governments ::P

:P*

soon there won't be a single CEX that'll be legally allowed to sell monero

<elongated:matrix.org> A few ppl want that, you won’t find those ppl once it’s not easy to on/offramp > <Cindy> like people just want something that works

<elongated:matrix.org> We are surviving on instant exchanges and they will die soon

<elongated:matrix.org> If we have actual dex integrations, regulators can’t ignore monero and will allow it to be listed as they can’t stop xmr anymore and would like trades to be on books they can see

<elongated:matrix.org> Cindy: Yes and price will be 100 then 10 then 1 with a few of us using xmr in this matrix channel

<elongated:matrix.org> Most users are not even here 😅

monero will survive through word of mouth

<elongated:matrix.org> Without dex, xmr is dead man walking

<elongated:matrix.org> Cindy: Yes in memes