lemmy instance monero.town gone. is anybody know the admin?

How Monero P2P fiat trading actually works in 2026 — platforms, fees, and what to expect

With LocalMonero gone (May 2024) and AgoraDesk shutting down shortly after, the P2P XMR↔fiat ecosystem had to rebuild from scratch. Having traded actively through all of this (683 trades, 454 partners on the old platforms), here's a practical breakdown of where things stand now.

The current platforms

Haveno-based DEX (RetosSwap / DawnSwap) The most trust-minimized option. Both sides lock a security deposit in 2-of-3 multisig before the trade begins. An arbitrator holds the third key and only steps in if there's a dispute. No KYC, no centralized custody.

• RetosSwap: ~$2M/month volume, 15% security deposits, 0.6% fees, 24-48h arbitration
• DawnSwap: Smaller but growing, 5% deposits (lower locked capital), ~2% fees, 24/7 arbitration team

XMRBazaar — Classifieds-style, zero fees. You negotiate and execute manually. Good for large trades with established counterparties, no arbitration.

OpenMonero — Newer platform, 0% fees, clearnet + .onion. CBM and F2F supported. Smaller user base but growing.

Payment methods that actually work

Cash by Mail (EU-wide) — Underrated. Physical cash in an envelope, tracked shipping. With multisig escrow the risk is minimal — if the cash doesn't arrive, dispute resolves in your favor with tracking proof. Works across the whole EU.

Face-to-Face — Best for larger amounts. SW Germany has decent liquidity if you know where to look. Frankfurt, Stuttgart, Rhine-Main corridor.

Bank transfer / SEPA — Higher reversal risk (chargebacks), usually requires more established trading relationships.

What to expect on pricing

With LocalMonero/AgoraDesk gone, spreads have widened. 8-12% over spot is standard for EUR P2P with privacy-preserving payment methods. If you're seeing 3-5%, the counterparty is either losing money or running high volume at thin margins.

For traders looking to get started

If you're new to Haveno: the UI is a bit rough but the mechanics are solid. Both sides lock deposits before any money moves. The escrow is automatic — no trusting a human intermediary with custody.

I'm active on RetosSwap and DawnSwap as arnoldnakamura (CBM + F2F, EUR). Previously chingchongfalung on LocalMonero/AgoraDesk — archived proof. Telegram: @arnoldnakamura if you want to trade directly.

Happy to answer questions about the mechanics of any of these platforms.

Monero has serious problems with scalability and now some devs want to cap the blocksize @ 90MB.

I think this is a good idea, it will protect Monero to operate in the niche of extreme privacy.

For world scale P2P digital cash we have Bitcoin Cash (BCH) which scales extremely well.

cross-posted from: https://monero.town/post/6752562

This post originally appeared on my website.

On September 14, 2025, a malicious mining pool successfully performed an 18-block "blockchain reorganization" of the Monero blockchain. Qubic, the mining pool, used its mining hashpower to generate an alternative blockchain history and replaced about 70 minutes of the honest chain's most recent history.

The main effect of the reorganization ("reorg" for short) was the invalidation of 115 transactions that had been included in the original honest chain. The coins in the transactions that were invalidated did not disappear. It is simply as if the transactions never occurred at all. The coins sent by the invalidated transactions returned to the sender's wallet and it is as if the recipients' wallets never received the coins.

Monero's protocol requires that users wait for 10 blocks before spending coins that they have just received. Since blocks are produced at a rate of one every 2 minutes on average, that's a 20 minute wait, on average. The wait is an annoyance for users, but it serves an important purpose.

In normal circumstances, Monero's "10 block lock" prevents transaction invalidation, but in this extreme case of an 18-block reorg, the 10 block lock was overwhelmed and did not prevent the 115 transactions from being invalidated. In this post, will see how the much-hated, but misunderstood, 10 block lock on spending newly-received Monero coins can prevent transaction invalidation on short reorgs and how things go wrong when the reorgs are deeper.

We will say that a transaction is "valid" if it has been included in a block on the main blockchain or it is eligible to be mined into a new block on the blockchain. A transaction is "invalid" if it cannot be mined into a new block.

We will compare the validity rules for bitcoin transactions and Monero transactions. Monero transactions need to obey the same basic rules as bitcoin transactions, but with some twists that make Monero special.

How bitcoin does it

A fundamental concept of many cryptocurrencies, including bitcoin and Monero, are transaction outputs. An output is a quantity of the currency inside of a transaction that is spendable. To provide a refresher on the concept of a bitcoin transaction output, I will quote my earlier article analyzing the Bitcoin Cash hard fork:

An output is a concept closely related to – but distinct from – address. An output is identified by its transaction ID plus its position in the transaction outputs, i.e. first position, second position, third position, etc. Once an output is spent by another transaction, it is spent permanently and cannot be reused. However, an address can be re-used repeatedly.

Transactions usually have more than one output because even a payment to a single recipient usually does not use up all of the output being spent. The remaining value, "change" like metal coins returned to a customer in a brick-and-motor store, is sent back to the sender's address in a second output in the same transaction.

A new bitcoin transaction that is eligible for inclusion in a new block will contain the transaction ID and the output position (first, second, third, or...) of the output being spent. The output position is the local output index. The index only refers to the position inside of its own transaction. This will be different from how Monero does it.

In bitcoin and Monero, a single blockchain is a consistent version of history. Transactions must appear on the blockchain in the correct order or else users could spend the same coins multiple times or create coins out of thin air.

In a single bitcoin blockchain (i.e. single version of history) a valid transaction must obey these rules that are relevant to our analysis:

1. An output that has already been spent cannot be spent again.
2. A transaction can only spend an output that has already been included in a prior block or in the same block as the transaction. Spending outputs from thin air is not allowed.
3. The spender must prove that they are authorized to spend the output by producing a cryptographic signature with their private key that matches the public key associated with the output.

The only exception to rule #2 is when miners are paid in completely new coins as payment for their service of mining new blocks.

A cryptographic signature is the result of a specific mathematical operation that combines the user's private key (which is never shared publicly) and the message that authorizes spending.

How Monero does it

Monero has many privacy features. One of them is "ring signatures". In bitcoin, every signature spends a single output. There is a one-to-one relationship between the output being spent and the transaction that spends it. There is no ambiguity about which output is spent, so the flow of funds is easily traced.

In Monero, a ring signature declares that any one of several outputs are being spent in a given transaction. An external observer cannot know which of the outputs in the ring is actually being spent. Monero's current ring size is 16, which means that there is one "real spend" hidden in the ring with 15 "decoy" outputs.

How does Monero fulfill the conditions that bitcoin requires of its transactions?

Bitcoin's rule #1 was "An output that has already been spent cannot be spent again." Monero makes sure that an output is only spent once by requiring that transactions include the key image of the output that is being spent. Each output has a unique key image that cannot be faked, yet in normal circumstances an observer cannot know which specific output is spent in a ring signature. Once a key image inside a transaction is included in a block, no other transactions with that key image are allowed inside the blockchain.

Bitcoin's rule #2 was "A transaction can only spend an output that has already been included in a prior block or in the same block as the transaction." Monero's rule is similar, with an important difference: Monero transactions can only spend an output that has already been included in a block at least 10 blocks ago. This rule is known as the "10 block lock". Since decoys and real spends are treated the same in the transaction validation process, all 15 of the decoy ring members must also follow this rule.

Bitcoin's rule #3 was "The spender must prove that they are authorized to spend the output by producing a cryptographic signature with their private key that matches the public key associated with the output." In bitcoin, there is a single public key. In Monero at current ring size, there are 16 public keys for every output that is to be spent. For a specified set of 16 public keys, the ring's cryptographic signature must match the whole set and only that set. You cannot split the signature and somehow replace one or more ring members. If you want to change any of the ring members, you must create a whole new signature, which requires creating a new version of the transaction.

A shortcut

Bitcoin transactions refer to outputs that they spend by their transaction ID and the output index inside that transaction. Monero transactions use a global output index to spend outputs. The global index is a count of every single output that has ever been included in Monero blocks. There are about 140 million outputs on the Monero blockchain already, with more added about every two minutes, on average.

The global output index is a useful shortcut. Ring signatures must refer to many outputs at once. If outputs in rings were referenced explicitly by transaction ID, each Monero transaction would be take up much more space to store. A transaction ID requires 32 bytes to store. Integer index numbers take up much less space: 4 bytes or less.

Monero transactions are already much larger than bitcoin transactions. A 2-input/2-output bitcoin transaction is about 0.4 kilobytes. A 2-input/2-output Monero transaction is about 2.2 kilobytes. An unpruned Monero node already takes up about 240 gigabytes of storage for the whole blockchain. Including every single transaction ID explicitly in each ring would increase the size of a 2-in/2-out Monero transaction by about 50 percent. Instead, rings refer to outputs implicitly by their global index number.

Since bitcoin transactions refer to their parent transactions explicitly by their transaction ID, the transactions' validity is basically independent of the exact position of the parent transactions in the blockchain. The parent transaction could be included in the previous block, a block from a week ago, or even the same block that the child transaction is included in. The situation is different with Monero transactions. Since the index of outputs depends on its exact position on the blockchain, the child transaction will not be valid if the index ordering is different from what the child transaction expected.

How can the output index ordering be different from what a Monero transaction was "expecting"?

The 10 block lock establishes the expectation. The global output index in blocks produced 10 or more blocks in the past is not supposed to change. The output index in blocks shallower than 10 blocks can change without major problems.

Such events occur occasionally just as a result of the random mining process. There is no coordination between miners where they "take turns" mining blocks. Each block production is a random event and sometimes random events can occur nearly simultaneously, in different parts of the network. It takes time for new blocks to spread throughout the network. Therefore, short alternative chains can develop occasionally until the whole network agrees on the one longest chain. The short chains that lose the race are eventually ignored by nodes in a process called orphaning. In normal circumstances, honest miners do not try to produce these alternative chains, yet unintentionally a few alternative chains of 1, 2, and very rarely 3 blocks long are produced. The output indices in these alternative chains can differ from each other. However, the short chains do not violate the expectations of new transactions because they are shorter than 10 blocks.

A simplified example

When orphaned chains are 10 blocks or longer, the expectations of new transactions are violated. Therefore, the transactions can be invalidated. Let's visually walk through an example.

To allow a compact diagram, in this example we will set the ring size to 3 and the block lock to 3. Each transaction will have a single transaction output and each block will have exactly 2 transactions. Coinbase transactions, which are reward payments to miners, are ignored.

The diagram shows the abbreviated transaction output public keys of each transaction. The output index is shown to the right of each public key.

Our transaction is labeled 4b20 and colored purple. Simplifying more, we will treat this 4b20 identifier as if it refers to the ring, output, and transaction itself in one concise label. Our transaction only selects ring members outside of the 3-block lock. When there is a 3-block lock, that means that rings cannot contain outputs from the most recent 2 blocks previous to one that included the transaction. The lock is represented by the red-orange coloring of blocks preceding the block where our transaction was originally confirmed.

The wallet software has created the ring and generated a valid signature for the public keys associated with the outputs in the ring. The ring members have indices 54, 49, and 48. The real spend is output public key f382, with index 49. At this point, no external observer knows that the real spend is f382. The other two outputs in the ring were selected randomly by the wallet software when the transaction was created.

This is the normal functioning of the example chain. New transactions are created. Their rings include outputs from blocks prior to the locked blocks. The transactions, with valid ring signatures, are included in new blocks and all is well.

However, it is possible for a powerful malicious miner to upset the orderly functioning of the blockchain. Even with a minority of total network hashpower, the malicious miner can occasionally get lucky and produce long alternative chains, in secret, faster than the honest miners can produce them. When the malicious miner successfully mines an alternative chain longer than the honest chain, it reveals the chain to the network. Suddenly, nodes in the Monero network realize that the longest chain is the new malicious one and they orphan the honest chain. This event is depicted in the diagram below.

The transactions of the orphaned honest chain are expelled from the orphaned blocks. They are seeking to be included in the new chain, if they have not already been included. Notice that the index numbers on the attacking chain refer to different output public keys than the original honest chain because some outputs are different and the outputs that are the same are in a different order.

Output c63c was originally in the ring created by our transaction. The ring referred to it by index 54. Output c63c is still valid on the attacking chain and actually was included in a later block on the attacking chain. The figure below shows where it went on the attacking chain. It now has index 57 on the attacking chain.

The new output index being out of order is a big problem for our transaction. In the new version of the chain created by the malicious miner, index 54 points to output public key 14bd instead of c63c.

The transaction's signature for the ring is no longer valid in the new chain history because the whole set of public keys do not match the signature, even though c63c is in the new chain. For our transaction to be valid, the attacking chain must have the exact same transactions in the exact same order as the honest chain, which did not happen here. Our transaction cannot be included in a new block because it is invalid.

Privacy impact

The transaction we created is invalid, but we can create another one that spends the same amount of coins to the same recipient. We change the ring and produce a new signature for that ring. We must include the same real spend, and here is where the ring privacy protections go wrong in this situation. The decoys, randomly selected, are different, but the real spend is the same. The figure below shows the old invalid ring on the left and the new valid ring on the right. The two rings only overlap on one output: f382 at index 49.

Any external observer of the blockchain can see this overlap of the two rings and deduce that the real spend was f382, defeating the privacy protections that ring signatures are supposed to provide. The observer knows that the two rings were trying to spend the same output because the ring has the same key image, as was mentioned before. The figure below summarizes the privacy impact. f382, in yellow, appears in both rings.

18-block reorg

On September 14, 2025, the Monero blockchain experienced an 18-block reorg. The deep reorg violated the assumption that reorg depths would not exceed 9 blocks. The incident invalidated 115 transactions that expected the 10 block lock rule to not be broken.

The 18-block reorg was achieved by Qubic, another cryptocurrency project. For months, Qubic has held a large, yet minority, share of Monero hashpower and has executed short blockchain reorgs to unfairly raise its share of mining revenue through a selfish mining strategy. A clickable visualization of the 18-block reorg event is viewable here.

Does the 18-block reorg mean that Qubic held a majority of hashpower? Not necessarily. Mining is a random process subject to luck. Qubic has had many chances to get lucky. According to block timestamps, Qubic mined a total of 20 blocks in 66 minutes. Assume that network mining difficulty was equal to network hashpower. If Qubic had 40 percent of network hashpower, it would have a 5 percent chance of creating 20 blocks in 66 minutes or less. This result is based on using an Erlang distribution where the shape parameter is 20 and the rate parameter is 0.4 * 1/2, i.e. 40% of the hashpower necessary to produce the usual one block per 2 minutes. Given that Qubic could try again and again, a 5 percent chance per attempt can turn into a very high chance with repeated attempts.

What happened to transactions in the orphaned chain? Most of the transactions (456) were expelled from the orphaned chain and included later in the attacking chain. 115 of the transactions were invalidated because they referenced outputs on the orphaned chain. Below is a table counting the number of transactions invalidated on each block of the orphaned chain. Notice that the first orphaned block at height 3,499,659 contained zero transactions, so no subsequent transactions would have included any outputs from that block inside their rings.

Orphan chain block height	Valid	Invalidated
3,499,659	0	0
3,499,660	96	0
3,499,661	38	0
3,499,662	22	0
3,499,663	8	0
3,499,664	3	0
3,499,665	0	0
3,499,666	24	0
3,499,667	20	0
3,499,668	14	0
3,499,669	79	0
3,499,670	24	10
3,499,671	38	28
3,499,672	39	25
3,499,673	0	0
3,499,674	3	0
3,499,675	27	31
3,499,676	21	21

Even in the final block of the orphaned chain at height 3,499,676, only half of transactions were invalidated because, by chance, about half of transactions contained no rings that referenced an output in the orphaned chain. Their ring members were all on the chain prior to the first orphaned block at height 3,499,659.

Case study of one transaction

We will follow the journey of one transaction that became invalidated: tx id d3e574c05b01f5d74815e3894f55e1645f402cdbf0415877f49e752a71b0d376.

This transaction was originally included in the orphaned chain at block height 3,499,672. Its ring specified global output index 139,283,631, plus 15 other indices from earlier in the chain. Within the orphaned chain, index 139,283,631 pointed to the output with public key b2de1e442b60b70ac681e9044581bb2dcbf66c97865b340d9a8ae4e3bb8e3d61 at block height 3,499,660. Note that some Monero block explorers label the output public key as a "stealth address".

However, when the 18-block reorg occurred, the transaction was expelled from the orphaned chain and started to wait to be included in a later block. In the new chain, index 139,283,631 pointed to the output with public key 61b08cd8a250fd2558cdd1a63ebfa38aeea0c9d4395c9223d315439fbc2e0e68 at block height 3,499,665. Since this was a different public key than the original signature was valid for, the transaction cannot be included in a block in the new chain because the old signature is invalid.

About 36 hours later, a new transaction appeared, 2b02f010b63b7a931eaafc681a1c2d2344ef44bdd0998c4b730663b041b4099c. We know that this transaction is related to the original one because its ring has the same key image: 1792997a43d27bb473605424ff3f1f1e1e69b44fec1ebc59dadba713a22eafa8.

The ring members of this transaction are all different except for one, at index 139,282,277. Both the old and new transactions contained this index. This index points to output public key 75254fa644c59a40eed60ad9bc6d9727a152323ac04069de764b72f9fcf3bd6b in transaction eb4f9e77a031c24fad0bb2abab76302e34e200bd3dff52a9f203fc187e2a4ff8 inside block at height 3,499,628, just a few hours before the 18-block reorg occurred. By process of elimination, this output must be the real spend. The ring signature's privacy protection was defeated.

Double spends and respends

Arguably the greatest negative impact of a deep blockchain reorg is the potential for a "double-spend" attack. In a double-spend attack, a malicious miner uses its hashpower to create an alternative history of the blockchain, then substitutes its history for the honest history. The miner spends the coins to a victim in the honest history, then spends the coins to itself in the attacking chain. Satoshi Nakomoto, creator of bitcoin, described the attack in his 2008 white paper that described the bitcoin protocol:

We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent.

To execute the double-spend attack, a miner would have to send Monero coins to a victim, such as a merchant or centralized exchange. The victim would wait a certain number of block confirmations, depending on the victim's preference, and then send an irretrievable item to the miner, such as a physical good shipped in the mail or coins of another type of cryptocurrency.

Meanwhile, the miner would be mining an alternative chain in secret that contains a transaction that contradicts the "payment" to the victim. Once the malicious miner's chain was long enough and enough blocks on the honest public chain are confirmed, the miner would broadcast the secret chain, which causes a reorg and reverses the payment to the victim.

A successful double-spend requires the intended victim to take some action, such as sending the perpetrator some item of value. Without the intended victim taking action, the attack has no effect.

In the intentional double-spend attack on the bitcoin blockchain, the perpetrator invalidates the first transaction on the honest chain by mining a contradictory transaction on its secret chain. Bitcoin rule #1, "An output that has already been spent cannot be spent again," is the violation that invalidates the transaction. In bitcoin, only the original sender of the transaction can invalidate the transaction because only the original sender can sign a transaction that contradicts the first transaction.

As explained previously, a Monero transaction can become invalidated by a deep reorg even if the original sender did not deliberately attempt a double-spend by producing a contradictory transaction. Qubic invalidated the 115 transaction as a sort of collateral damage of its behavior.

Another difference in Monero, compared to bitcoin, is that it is easy to see if two bitcoin transactions sent the same exact amount of coins to the same address, because of its lack of privacy features. In Monero, addresses are hidden on the blockchain through its stealth address feature and amounts are also hidden with confidential transactions technology. Therefore, it is unknown if the later valid transactions just sent the same coins to the same recipient as the invalidated transactions were trying to send in the first place.

As of release of this post (September 26, 2025), about 74 percent of the 115 invalidated transactions had at least one of its ring's key image confirmed in another transaction after the original transaction had been invalidated. It is maybe better to call these transactions "respends" instead of double-spends because they could have been spent to the original intended recipient. Note that invalidated transactions could have been users sending funds to themselves or users could have completed the original payment to another recipient using a different set of coins or a different wallet. No merchant has yet claimed publicly to be an accidental or deliberate victim of a double-spend as a result of the 18-block reorg.

FCMP transaction invalidation

Full-Chain Membership Proofs (FCMP) is an upcoming upgrade to Monero's privacy features. Instead of having a small "ring size" of 16, FCMP will, in effect, produce a ring that includes all of the hundreds of millions of outputs ever produced on the Monero blockchain. It is a huge improvement in privacy. How would FCMP transactions handle a deep blockchain reorg?

In one way FCMP performs better than ring signatures, but in another way it performs worse. The privacy impact would be eliminated. Since FCMP transactions would include the whole set of previous outputs in their "rings", an observer could not perform the process-of-elimination analysis that defeated the privacy of small rings when transactions are invalidated and need to be reconstructed.

However, since current-version Monero rings only select a limited number of outputs from the reorg zone, there is only a chance, not a guarantee, that the transactions outside of the 10 block lock are invalidated. In the actual 18-block reorg, only about half of transactions that could have been invalidated actually were, because of luck of the ring signature draw. If they were FCMP transactions, all transactions above the 10 block lock would have been invalidated because all of them would reference all transactions from 10 blocks and earlier.

---

anhdres created all diagrams in this post.

Special thanks to DataHoarder for extracting and hosting extended data about the reorg incident here and here.

jeffro256 and DataHoarder reviewed an earlier version of this post and provided feedback.

Open source code used to produce of the empirical analysis in this post is here.

If you enjoyed this article, consider supporting my work with a donation of XMR, BCH, BTC, or WOW.

cross-posted from: https://monero.town/post/6680879

More community input is needed on possible deployment of temporary rolling DNS checkpoints to defend against Qubic attacks: https://github.com/monero-project/monero/issues/10064

Please comment on the GitHub issue and/or click thumbs-up/down emoji reaction.

TL;DR: A malicious mining pool is disrupting the network and could cause deep blockchain re-organizations. DNS checkpoints, which have existed for emergency use in the code since 2014, could prevent deep blockchain re-organizations, but Monero's blockchain consensus protocol would temporarily be less decentralized.

Advantages

Practical advantages

• The code for this countermeasure has been in the Monero codebase for over ten years. The countermeasure is ready to deploy now, once final testing, "procedure smoothing" (see below) and successful outreach to honest mining pools is completed.

• Humans (i.e. the Monero Core Team) could intervene by ceasing or modifying the checkpointing procedure if the checkpointing produces undesirable results.

Principled advantages

• Rolling DNS checkpoints could keep the Monero network working, with minimum disruption, for the thousands of users who depend on it every day for private peer-to-peer electronic cash.

Disadvantages

Practical disadvantages

• Rolling DNS checkpointing has never been deployed on Monero's mainnet before. Something unforeseen could go wrong.

• Successful checkpointing requires most of the major honest Monero mining pools to voluntarily enable DNS checkpointing enforcement. If the mining pools choose not to, rolling DNS checkpoints will likely be unsuccessful.

• Maintaining control of the DNS records would require strict security procedures. Two previous security incidents in 2019 and 2023 involving malicious software hosted on getmonero.org servers and theft of community donated funds should be kept in mind.

Principled disadvantages

• Without a doubt, Monero's consensus mechanism would be less decentralized if rolling DNS checkpoints were enabled.

• Monero nodes would temporarily no longer follow the chain with the most proof of work.

• Mining pools following the DNS checkpoints would be similar to a situation of the majority of mining hashpower coordinating and colluding against a minority hashpower miner. "Majority hashpower cannot collude" may be considered a security assumption of proof-of-work consensus.

cross-posted from: https://lemmy.ml/post/33908014

Hi,

I just discovered that Cryptocurrency ATM exist and since a "while" !

Here, it's a total blackout about it ! see https://coinatmradar.com/ and check how much there is in France Marconie you will get what I'm talking about..

\

So the question, is how it work to buy or sell XMR ?
Is those machine require a ID proof ? If yes it's pointless..

cross-posted from: https://lemmy.zip/post/38867573

When checking in other instances, like lemmy.zip, we can see that monero.town has federation problems. Not all posts are shown (very few).

This is a big problem for the fediverse. My instance admin told me that they contacted the monero.town admin about it but didn’t receive any answer. Monero.town runs an old version of lemmy as well

I’m wondering if we should create a new Monero community on another instance that properly federates. It would bring a lot.

My blockchain is 5 years behind and my friend is bringing over an up to date chain. Can I just rsync lmdb and it adds the new blocks or is it better to just paste the new chain in place of the old one? I don’t think the up to date one is pruned but if it is will that cause problems if I try to rsync it?

On Linux. Thanks.

cross-posted from: https://monero.town/post/5041387

Take a break from Twitter

• If you use the Tor Browser or the Mullvad Browser you will see the popup of NoScript - because your identity at X can be open to other websites in your web browser. Keep your privacy in mind.

• You may leave traces without realizing it. The way you write, what you read about and how much, when you are active, etc. Remember, if you are a Monero XMR user, you may not want this at all!

• Mental hygiene; it feels good not to be at the mercy of the posts there for a while. Try it out!

• It usually takes up a lot of your time without you doing anything productive.

• Elon Musk himself is a major disinformation disseminator on his own platform. But many of the posts there are also questionable.

• X Using Your Tweets to Train Its AI. And even if you have deactivated the artificial intelligence option, the users you interact with probably haven't deactivated it. Because it was introduced without notifying the users.

The Benefits of Exchanging Monero for Cash Face-to-Face: Simplicity, Privacy, and Anonymity

Hey all, Tommy from AllArk here. We are expanding to Peer-to-peer, private, Face to face transactions with zero KYC to exchange XMR for Cash.

In the rapidly evolving world of digital currencies, Monero stands as a pioneer, offering users a decentralized form of money that can be transacted across borders with ease. However, one aspect of trading that has garnered significant attention is the practice of exchanging it for cash in face-to-face transactions. This method, though traditional, offers unique benefits, particularly in the realms of simplicity, privacy, and anonymity.

Simplicity One of the primary advantages of face-to-face exchanges is their straightforwardness. Unlike online exchanges, which often require users to navigate complex platforms, understand varying fee structures, and comply with stringent verification processes, face-to-face transactions are remarkably simple. The process typically involves a direct trade between two individuals, where Monero is transferred from one digital wallet to another in exchange for physical cash. This directness eliminates the need for intermediaries, reducing both the steps involved and the chances of encountering technical difficulties or errors.

Furthermore, this method allows for instant gratification. While online transactions can sometimes take hours or even days to process, especially during periods of high network congestion, face-to-face exchanges are immediate. Once the transfer is confirmed on the network, the cash changes hands, providing instant access to funds.

Privacy Privacy concerns are ever-present in the digital age, and many users value the ability to keep their financial activities discrete. Face-to-face exchanges offer a level of privacy that is hard to match in the digital realm. Unlike online platforms, which often require detailed personal information and financial disclosures, face-to-face trades can be conducted without revealing much more than a pseudonym or a first name.

This level of privacy stems from the nature of the transaction itself. Since the trade is conducted in person, there is no digital record of the exchange beyond the transaction on the blockchain. This drastically reduces the amount of personal data that is shared or stored, minimizing the risk of identity theft or other privacy breaches.

Anonymity Anonymity is closely related to privacy but takes it a step further. Monero is often touted for its anonymous nature, where transactions are recorded on the blockchain but not linked to wallet addresses, or individuals' names. Face-to-face exchanges enhance this anonymity by removing the digital footprint associated with online exchanges.

When trading Monero for cash in person, there is no requirement to provide identification, no KYC (Know Your Customer) checks, and no third-party oversight. This makes it nearly impossible for external entities to trace the transaction back to the individuals involved. For users who prioritize anonymity, this method of exchange is unparalleled.

Conclusion In conclusion, exchanging Monero for cash in face-to-face transactions offers several compelling benefits. The simplicity of the process makes it accessible to users of all experience levels, while the enhanced privacy and anonymity preserve the core values that many Monero enthusiasts hold dear. As digital currencies continue to evolve, face-to-face exchanges remain a valuable and secure method of preserving personal freedom and financial confidentiality.

AllArk goes a step further and can deliver Cash to any of our supported cities with nothing else needed from you. Cash can be delivered at any venue you choose as well. And couriers need nothing other than address, time and any directions you deem fit for your use case. 🙂

Hope this helps some of you out there!

Tommy from AllArk

Clicking these links should let you see and subscribe to them them without leaving your app/home instance:

Top Monero.town instances:

• Monero
• Meta
• moneromining
• MoneroChan
• Monero_memes
• Monerokon

If the link gives a 404, it's because your instance isn't connected to Monero.town or no one on your instance has searched for the Monero.town community yet

Check out !monero@monero.town if you are looking for a more active Monero community on lemmy!

Where can i buy XMR today that wont scam me? Its been a while (2 years) since i bought any and Kraken has supposedly stopped dealing in it, that plus i lost my login deets for that site.

Any alternatives that are safe?

Here’s a recap of what happened this May in the Monero community: Breaking

• tevador released a security advisory for a ‘medium severity’ vulnerability in Monero wallets that can be exploited by malicious remote nodes (1)
  

• jeffro256 posted a vulnerability disclosure highlighting a ‘high severity’ bug that was patched in Monero v0.18.2.2 (2)
  

• KuCoin temporarily suspended XMR deposits and withdrawals due to ‘node maintenance’ (3)
  

• Binance was getting ready to delist XMR in France, Italy, Poland and Spain due to ‘local regulatory requirements’ (4)
  

R&D

• There were 5 Monero Research Lab meetings in May (5,6,7,8,9)
  

• The Seraphis Wallet Workgroup held 3 meetings (10,11,12)
  

• The ETH-XMR atomic swap beta release v0.2.1 was deployed on mainnet (13)
  

• The Nym team announced a new mixnet integration with the Monero network (14)
  

• selsta posted a Monero dev report for April 2023, finalizing their CCS proposal (15)
  

• SChernykh released P2Pool v3.4 with several bug fixes and improvements (16)
  

• m2049r released Monerujo v3.1.3 ‘Fluorine Fermi’ & v3.2.0 ‘Decoy Selection’ (17,18)
  

• LocalMonero/AgoraDesk mobile apps versions 1.1.1-1.1.4 were released with several bug fixes and improvements (19,20,21)
  

• Cake Labs announced the first Cake Wallet beta release for Linux and ‘Cake 2FA’, a new security feature (22,23)
  

• Haveno versions 0.0.5 & 0.0.6 were released with binary installers for live test network and support for gold and silver (24,25)
  

• hinto-janai released Gupax v1.2.2 with fixes, UI improvements and remote node changes (26)
  

• rehrar released Stack Wallet versions 1.7.7-1.7.11 with support for Trocador.app and various fixes and updates (27,28,29,30)
  

• lukeprofits released ‘Monero Subscriptions Wallet’, as promised (31,32)
  

• keef1337 released noderowallet v1.1.0-1.1.2 (33)
  

• pokkst released Mysu Wallet v0.4.3 with ‘high priority’ fixes (34)
  

• tobtoht released Feather Wallet v2.4.9 with security fixes (35)
  

• ANON v0.4.1 updated to Monero 0.18.2.2 (36)
  

Funding

• selsta submitted a new CCS proposal for 3 more months of part-time Monero dev work, which was fully funded (37,38)
  

• valldrac submitted a CCS proposal to develop a Monero Wallet SDK for Android (39)
  

• jeffro256 submitted a CCS proposal for 4 months of full-time Monero dev work (40)
  

• VostoEmisio submitted a CCS proposal to create an animated video explaining Monero’s Tail Emission (41)
  

• john_r365 proposed a bounty for the review of a Trezor PR to the core Monero codebase (42)
  

• plowsof will continue working as CCS coordinator for 3 months after their proposal was fully funded (43)
  

• Justin Berman completed his latest Monero dev work CCS proposal (44)
  

• CryptoGrampy completed his HotShop CCS proposal (45)
  

• Lovera posted a CCS progress report for April 2023 (46)
  

• moneromooo-monero was planning to work on Townforge after completing 520 hours of Monero dev work (47)
  

Culture

• There were 4 MoneroKon 2023 Planning Meetings in May (48,49,50,51)
  

• A Community Workgroup Meeting took place on the 27th (52)
  

• Monero Magazine interviewed ‘Katie The Russian’, Juraj Bednar, Nam Sardar and ‘Mano Crypto’ (53,54,55,56)
  

• Monero Talk interviewed crypto-anarchist Pavol Luptak (57)
  

• rbrunner7 published a new Monero-themed fictional short story titled ‘RingCT’ (58)
  

• rottenwheel published Revuo Monero issues #169-172 (59,60,61,62)
  

• LocalMonero published The Monero Standard issues #52-55 (63,64,65,66)
  

• Ledger came under fire for its controversial ‘Ledger Recover’ firmware update (67)
  

Community Messages (10/51)

• [AFH] Foreign Language Teacher: Spanish and Portuguese (by pedrosfreitas) (68)
  

• [ANN] Rucknium Monerotopia 2023 Presentation (by Rucknium) (69)
  

• [ANN] Results after 4 months of mining (Jan - Apr 2023) (by SeaFailure) (70)
  

• [ANN] Os Moneristas - Brazilian community project (by OsMoneristas) (71)
  

• [ANN] The next nautilus update will remove support for monero (by fossephate) (72)
  

• [LTH] C++ developer to enchant a project (by Nico) (73)
  

• [WTB] [~45 XMR] NLJD (Non-linear Junction Detector) & [1-2.25 XMR] IR Thermal Camera (by freQniK) (74)
  

• [WTB] [US] 1/10oz Gold Coin with crypto (BTC/XMR) (by ValleyEliminator) (75)
  

• [WTS] [~180€ XMR/BTC] OLED PS Vita with Minecraft (by derBehr98) (76)
  

• [WTS] [35 USD] Schmidt Hammer (by burntbooks) (77)
  

[escapethe3RA's] personal contributions

Daily

• published 75 Monero Observer Reports (78) (consult the Archive page for a complete list (79))
  

•  updated Changelog (80) and XMR Stats (81)
  

As needed/On demand

• updated reports, listed 51 Community Messages and 14 Calendar events (82,83) & added 5 new Resources (84)
  

• published Meeting summary: Monero Research Lab, 3 May 2023 (85) and uploaded 13 meeting logs (MRL 2023-05-03, MRL 2023-05-10, MRL 2023-05-17, MRL 2023-05-24, MRL 2023-05-31, Community 2023-05-27, MoneroKon23 2023-05-06, Monerokon23 2023-05-13, Monerokon23 2023-05-20, Monerokon23 2023-05-27, Seraphis 2023-05-15, Seraphis 2023-05-22, Seraphis 2023-05-29) (86,87,88,89,90,91,92,93,94,95,96,97,98)
  

Weekly

• published 4 Monero Dev Activity Reports (Weeks: 18-21, 2023) (99,100,101,102)
  

• published 4 MO Artistic Saturday Top 5 reports (Weeks: 18-21, 2023) (102,103,104,105)
  

Monthly

• published MO Blitz Report: #21 (April 2023) (106)
  

Credits/special thanks to:

• everyone that reported broken links, suggested edits, sent anonymous news tips and shared my reports
  

• the cypherpunks for their encrypted emails and XMPP (OMEMO) messages
  

• gnuteardrops from Monero.Graphics for the amazing art and plowsof for the consistent pings
  

• all anon MO loyal readers and generous CCS contributors
  

• hard working people that keep building and maintaining cool stuff for the Monero community
  

SimpleMobileTools are making simple yet great open source android apps. No ads, no trackers, cheap price or even free. I personnaly love Simple Gallery Pro and have a lot of respect for the devs, I would like to donate since they accept cryptos... unfortunately only BTC, ETH and LTC. Let them heard of the benefits of Monero so I (and maybe you) could donate to them for their work !