Proposal abstract Upon FCMP++ hard fork activation, validators should ignore the unlock_time field retroactively for all non-coinbase transactions posted to the chain after a certain height. This h...
FCMP++ Hard Fork Planning: Discussion Welcomed
Discussion welcomed for discussion of possible future rule to take place upon FCMP++ hard fork activation. This rule would retroactively ignore the unlock_time
field of transactions past some future block height. This would make the migration to FCMP++ tree building easier.
Get a Pixel phone and flash GrapheneOS onto it. Best out-of-box privacy and security experience that currently exists still with great usability IMO. Does not have an advertising ID or even Google Play services by default. Also, it actually has better battery life in my experience.
quite literally a Uniswap clone taking over 2 years without any solid results - how sad!
This is also completely false. Serai is not a "Uniswap clone"; Uniswap only supports ERC20 tokens, where Serai can support almost any coin from any chain, given the right validator setup. Also, there have been "solid results": there was a testnet 5 months ago.
None of those linked articles support the claim that "almost all of Monero’s usage is crime-related".
Chain analysis companies have proved that almost all of Monero’s usage is crime-related darknet activity. Ransomware, drugs, CP, and all the worse things you can imagine are used strictly with Monero in mind.
This is not skepticism. This is bullshit, plain and simple. Unless you have behind-the-scenes knowledge that the public does not currently possess, there is zero evidence to suggest that almost all of Monero's usage is crime-related. As of 2024, the IRS has still not paid out their final bounty for a tool to trace Monero transactions, and almost all spokespeople for chain analysis companies (some of which I have personally talked to) say that Monero is effectively untraceable in the majority of cases. As such, I don't see how you conjured up this statement unless you have a specific distaste for Monero and no sense of obligation to speak truthfully. Please point to a source where chain analysis "proved" the majority of Monero usage is illicit. Even if we take at face value that Monero is the currency of choice for many criminal rings, there still needs to be evidence of actual numbers related to the criminal volume versus total Monero volume. Some organizations have tried scoping this out, but I honestly know of no source that pins it anywhere near that high. Most place it around the same as USD and BTC at ~1-3%, with some going as high 15%. There is a ton of variability in those figures, and all acknowledge that comprehensive data collection is inherently impossible (criminals don't report their transactions, and good financial data is hard to collect even for honest participants), and not a single one has ever claimed to "prove" any of those figures.
Both are bad for privacy, but B is especially horrendous. Every time you consolidate transaction outputs like this, you are yelling at the people you received money from: "HELLO! REMEMBER WHEN YOU SENT ME MONEY? I AM CONSOLIDATING THAT IN THIS TRANSACTION RIGHT NOW". When that transaction is the SAME transaction to actually spend those funds to someone else (AKA scenario B), you lose almost all plausible deniability about the origin of the funds. For the love of everything holy, PLEASE do not "churn" like this. I don't mean to sound harsh, but since you do not know anything about coin control yet, I would recommend staying away from churning and consolidations at the moment. The most private way to send money to someone is NOT to consolidate ever. Sweep each output to them individually, one at a time, in separate transactions over multiple hours with random timings. However, if you insist on consolidating everything into one output before sending it to them, there's a couple rules to live by: A) NEVER consolidate outputs AND spend them in the same transaction (i.e. only ever consolidate to an output address that you own), B) never consolidate more than 2 outputs at a time, C) use random delays when churning, D) if you are trying to keep different receiver identities (subaddresses) unlinked from one another, don't consolidate outputs from those different identities in the same transaction E) once everything is in one output, do at least one extra 1-input tx churn to yourself before spending (after a random delay of course).