got it. they managed to post it anyway.

does having a hidden service introduce the same issues?

are we having federation issues? or why did you repost it?

thank you very much, Rucknium. your understanding of my question was spot-on, and the R code works excellently! very useful.

I'd like to ask a few more questions:

• is 314 a common seed in R, or just something you randomly picked?
• in statistics in general, are there cases where n * 100000 random samples (any distribution) would be insufficient? is it a good rule of thumb?

good point. FCMP++ will be an upgrade to the Monero protocol through a network upgrade. to realize the privacy benefits of it, you need a new addressing scheme. so far the scheme was planned to be Jamtis-RCT. Carrot is a separate addressing scheme to be used with FCMP++. nothing prevents the simultaneous use of both, and they look the same to outside observers. FCMP++ was basically "upgraded" by adding another potential addressing scheme to it.

this doesn't guarantee that both will be used. my guess would be that the industry will converge on one addressing scheme.

it is now. the Matrix came back online at 18:00 UTC.

not true. watch the leaked Chainalysis video (e.g. currently available at https://odysee.com/@nyxmr:d/chainalysis:f, may not be in the future). they did a lot of their correlations by running nodes and observing transactions that were directly submitted through those nodes.

run your own full node.

Tuta accepts Monero as payment.

do they directly take actual XMR, or do you mean that they sell vouchers to Proxy Store that Proxy Store then resells for XMR? as far as I know, it's the latter, and there is a huge difference between the two.

As you “have no time to look deeper into this” we will end the discussion here.

I find the questions you raise very useful, but this tone totally kills the ability to convince anyone.

I tend to think that the ability to simply switch to other servers with a few clicks/taps is a big improvement over the Signal model, where you're at the mercy of a single company. I agree that until community-run servers emerge (I don't know the progress on this) and people switch to those, SimpleX-the-company can perform a limited form of statistical surveillance. they can also defederate from any server (I suppose that's how they would carry out the "disruption" they mention in their terns of service), though that's something that every server can do.

is there a better architecture that can prevent this? if there is, we should look into that.

AppImages are better than .debs, but still have basically full access to your userspace. flatpaks have a permission system, can be built with very strict permissions and the you can modify those as you see fit, e.g. through the Flatseal graphical interface. I would much more prefer a Haveno (universal or Reto) flatpak.

see what happens to cause it to recover.

this should set you up as a starter: https://www.liquity.org/blog/on-price-stability-of-liquity

I was under the impression that the oracle signal was on chain, from liquidity pools against other stables

that would mean that if even one of those stables dies, LUSD would destabilize too (and there would be no possibility of intervention, since that protocol is completely ossified). that's worse overall.

Maker was not immutable yet

I was talking about Chronicle, the oracle protocol that spun off from Maker.

basically that is never going to happen.

look at Maker's history, what's been promised, and what's been delivered. don't take it for granted that puredai will ever happen.

yeah, you created an account and posted this right after and nothing else. you must be totally not Majestic Bank yourself.

you ripped me off every time I used your service. you skewed the price in your favor by several percentages after my transaction was detected, while the trade was processing. I even corrected my calculation for price volatility during the trade, so you can't say "sorry, the market tanked while you were waiting". overall I usually ended up losing 4-5% compared to mid-market prices at the time of the first confirmation of my deposit. (for perspective, this was in times when XMR had good global liquidity and anything above 2.5% loss was basically a ripoff.)

the only remotely positive thing about you is that you pour a lot of money into Monero conference sponsorships. this self-advertising is the sole thing that keeps your reputation within the Monero community from going to zero.

your shitty practices ensured I will never trust you again. get lost.

they've done worse every time I used them: they jacked up the price well after my deposit was detected by them. I ended up losing several percents compared to the price they promised.

it's a scammy service and they invest a lot into event sponsorships (for conferences, meetups) to gain visibility. they also leave useless comments on GitHub issues, which also looks like self-promotion. just like this useless Lemmy post. I'll never use them again.

as someone who has studied both, I would recommend LUSD (v1) over dai. LUSD was launched 3 years ago, so it stood the bear test. the minimum collateralization ratio of 110% applies to individual troves as long as the total system collateralization is over 150%. once that's breached, troves are required to have 150% minimum. the Achilles heel is the oracle. if Chainlink pulls the rug, which they can, it's over (sadly, Tellor is used by Liquity in a way that it can't protect against a Chainlink apocalypse). Maker is somewhat better in this because they use Chronicle, which is ran by more trustworthy people, but I'm almost sure they haven't made their contracts immutable. if that is the case, then the same attack vector exists there.

as you'll see, neither of these are the solution we're looking for, and they both run on the no-privacy, hypercomplex, captured, constantly changing Ethereum blockchain, so... fuck.

but dai for a long time has not been what the market thinks it is. avoid it.

Rucknium brought up your concern during today's Monero Research Lab meeting, some people commented on it: https://libera.monerologs.net/monero-research-lab/20240410#c361656

there is:

IRC: irc://irc.libera.chat/#no-wallet-left-behind

Matrix: https://matrix.to/#/#no-wallet-left-behind:monero.social

nice catch! I will avoid them until they secure their infrastructure.

there is nothing that requires a perpetuals market to have a lower volume than the whole spot market for the underlying asset. perpetuals are derivative assets, the reason they exist is to enable trading regardless of access to the underlying asset's supply.

side note: Binance will shut down their XMRUSD perpetuals with the delisting, but they will keep running their XMRUSDT perpetuals (USDⓈ-M XMRUSDT):

Please note that users may continue trading USDⓈ-M XMRUSDT and ANTUSDT Perpetual Contracts.

(https://www.binance.com/en/support/announcement/binance-will-delist-ant-multi-vai-xmr-on-2024-02-20-f73b083ba6834771b07dbe5319917ae5)

on the major existing decentralized exchange, Bisq, you already have a publicly observable price feed for XMRBTC. you can calculate XMRUSD based on that and a BTCUSD price feed that you trust.

DEXs that are in the making, namely Serai and Haveno, both plan to have at least one XMR pair with an Ethereum-based dollar-pegged coin. I suppose, although I'm not sure, that at least in the case of Serai the trades on that pair will have publicly observable prices.

Haveno will also have non-blockchain, actual fiat (cash, wire, payment apps) pairs with XMR.

you can take sources like this and calculate an average or a median. current price aggregators, like coin listing sites, will probably do the same, so it's likely that even in a DEX-only future you'll get your prices from the same sources as today.

heads up about the screenshots -- when you need to obscure text (or anything else) on a picture, don't use blurring, pixelization or similar effects. they can be brute-forced and the original text can be retrieved, with trivial computing power. always use color fill to obscure data, and don't make it exactly as big as the data is (~visual padding).

this concept has been discussed before as "return addresses". it would marginally increase the transaction size and thus the storage requirements, but it's possible and seems reasonable. it looks like no one pursued it since knaccc formalized it. nevertheless it's on the roadmap ("Future" tab).

https://old.reddit.com/r/Monero/comments/b0gjud/monero_return_addresses_who_would_use_this_feature/

https://github.com/monero-project/research-lab/issues/53