[XMR] Monero - A secure, private, untraceable cryptocurrency

[nullius]

Moving this to the top:  How do you want to keep up-to-date with new tor daemon releases?

• The Tor Project forum’s News board announces releases for various projects, and includes the daemon release announcements in the News: Tor Release Announcement subforum.  (Posting on these forums requires JS (fucking discourse), but they can be read with no-js.)
• The Tor Project’s blog (onion) announces Tor Browser, but not tor daemon releases.  So...
• Whenever you get a Tor Browser update, check its release notes to see if it distributes an updated tor daemon!  (I assume that everyone involved here actually uses Tor Browser every day, and keeps it updated.)
• I need to check and see if the Tor release announcement mailing list still works at all.  The hyperkitty archive page requires JS, so fuckit—someone else please tell me?
• Use the power of git.  Keep a local clone up-to-date, and watch for new release tags.  This can be automated, and automation prevents fuckups.  I use the official git onion ← (link will work with git clone, but redirects browsers to the core tor gitlab app page); to “trust but verify” that I’m not phishing you with a trojaned tor, verify from onion.torproject.org that that’s the onion for gitlab.torproject.org.

Hey, welcome back!

Do me a favor an give me your thoughts on that PR.

Ah, php2shell—and now this...   By way of thanks for the warm welcome:

Code:

-$(package)_version=0.4.9.11
+$(package)_version=0.4.9.15

This is a problem.  Tor has had a stack of security advisories since 0.4.9.11.  Never mind 0.4.8.x in the PR itself?  (I didn’t dig into Feather deeply enough to understand this discrepancy; I myself have only ever used monero-wallet-cli for Monero, IIRC since before that was the filename.)

The past few months have been a security shitstorm in the Tor Project, just like everywhere else.  Merely by reviewing the git log, I think it looks like David Goulet and Mike Perry have been using both GPT Codex and Claude to hunt for security bugs before attackers do the same thing.  Not sure where reports come from, I heard somewhere that TPO has also been getting many other reports from bughunters using LLMs; I don’t know if I am giving appropriate credit or not.  Anyway, altogether, the past few months have seen public disclosures of tor daemon security bugs, which have been fixed ASAP in unscheduled releases.

If I were a state-level threat actor, I’d hope that lots of people never update their tor daemons. #justsaying

With my attention elsewhere, I haven’t dug too much into the impact for AP clients; AFAIK, some of the security bugs affect only relays, but some may affect AP also.  Off the top of my head, I don’t know the potential impact on Feather users—if any.  I just keep my own tor daemon up-to-date!

Also due to LLMs, OpenSSL has had several important point releases for security.  I’d suggest double-checking what OpenSSL (system or not) Feather’s redistribution of the tor package uses.  Tor Browser does NOT use system OpenSSL, and the Tor Project has been consistently updating the OpenSSL binaries that they package with Tor Browser’s tor daemon.

Code:

+    if (output.contains(QByteArray("protocol listed as required in the consensus is not supported"))) {

Parsing log output this way is brittle.  A quick grep of my tor tree suggests starting here to look for a better way to detect this condition...

Code:

  if (!protover_all_supported(required, &missing)) {
    tor_asprintf(warning_out, "At least one protocol listed as required in "
                 "the consensus is not supported by this version of Tor. "
                 "You should upgrade. This version of Tor will not work as a "
                 "%s on the Tor network. The missing protocols are: %s",
                 func, missing);
    tor_free(missing);
    return 1;
  }

...but at this particular moment, it seems the effort would be better spent on more reliably keeping Tor up-to-date.

[DireWolfM14]

Consider a path towards integrating Arti.

I read up on Arti when I saw you had mentioned it before.  Definitely a neat project.  As much as I am a fan of Rust, I just don't see much demand for it to supplant C where it's already been entrenched.  For new software, or re-writes of other languages that aren't as practical as C it makes lots of sense.

I run a Tor daemon with my own local patches; their repo and their build/test processes are relatively easy to work with, even just for personal use.

Just curious; what exactly are you patching, why, and how?

[LoyceV]

Are you guys not using the Tor repository to keep your Tor install up to date?

I'm using my Linux distro's default packages.

[nullius]

I read up on Arti when I saw you had mentioned it before.  Definitely a neat project.  As much as I am a fan of Rust, I just don't see much demand for it supplant C where it's already been entrenched.  For new software, or re-writes of other languages that aren't as practical as C it makes lots of sense.

This will make me as popular as a whore in church to mention here, but credit where due:  The big project to rewrite Tor as Arti was funded by Zcash grants for multiple years.  I have mixed feelings about this; I’m not such a fan of rusting all the world’s code, and I kinda dislike Rust, and I know the C daemon like an old friend... sigh.

Besides the whole “memory-safe language” thing, some aspects of Arti’s design are far superior to the C daemon.  That’s a design issue, not a language issue; while rewriting from scratch, the Tor lead devs did their wishlist of “how we should’ve done it”.  (Imagine what Bitcoin Core would do, if they could throw the whole thing out instead of slooooowly refactoring out libbitcoinkernel (a good explanation), etc.)  In particular, Arti is designed from the ground up to work with other programs—either via an RPC protocol much better than the old control socket, or embedding as a crate/library.

Embedding and bundling in other programs has been a major pain point.  Tor always should have been deployable a library—and also, the Tor control port protocol has always been awful.  So...

Switching to Arti would not require Feather to rewrite their own project in Rust!  On the integration page I linked, both FFI and RPC are noted.

The C daemon will someday be phased out.  I haven’t yet tried Arti, but I know I need to dig into it sooner rather than later.

I run a Tor daemon with my own local patches; their repo and their build/test processes are relatively easy to work with, even just for personal use.

Just curious; what exactly are you patching, why, and how?

Occasionally, I’ve fixed bugs.  For instance, I discovered and locally fixed #40739 (clearnet) a few years before the Tor Project’s patch broke my branch with a merge conflict, and I had to revert my patch.  And now, I didn’t help the community, and I didn’t get credit for it, and no one will ever even believe me.  (No, I’ve never found a 0day in Tor!)

Other stuff I do is sensitive; I would prefer not to discuss it publicly.

But most importantly:  I am heavily dependent on Tor.  Some people toss around the terms “free software” and “open source” as buzzwords.  I actually use the source.  If my life is so deeply entwined with a piece of software as it is with Tor, I want to know that code intimately.  The best way to keep in touch with the code is to build from git, spend some time poking around in the code, and customize little things to my satisfaction.

P.S., DireWolfM14, this thread was actually spawned by my alt’s needs, which delayed reply to you until OP’s aneurysm/thread lock cut it off—for now.  XMR got a plug in my artfully slipped-in fungibility manifesto, though the manner thereof probably won’t make XMR people much happier than BTC/AMLed-NFT maximalists.

Are you guys not using the Tor repository to keep your Tor install up to date?

I'm using my Linux distro's default packages.

If that’s Debian or Debian-based, the Tor Project recommends their own .deb instead.  That’s why they make it.  I don’t know how it is now, but in past years the Debian tor package was poorly-maintained.

[DireWolfM14]

No, I’ve never found a 0day in Tor!

Well, that's good news for those of us who are code-illiterate. 

Other stuff I do is sensitive; I would prefer not to discuss it publicly.

Roger that.  Thanks for entertaining the question nonetheless.

Are you guys not using the Tor repository to keep your Tor install up to date?

I'm using my Linux distro's default packages.

If that’s Debian or Debian-based, the Tor Project recommends their own .deb instead.  That’s why they make it.  I don’t know how it is now, but in past years the Debian tor package was poorly-maintained.

I don't recall when or why I started using the Tor repository, but years back I do recall running into an issue on Windows that's similar to what's going on with Feather.  I was in the habit of running a Tor daemon as an NTService so I didn't have to start Tor Browser whenever using Electrum wallet, but I was really lazy about keeping Tor up to date.  Tor's Debian repository makes keeping it up to date super easy.

[Hueristic]

https://github.com/monero-project/monero/pull/11407

Code:

# Security Audit — Monero PR #11407: "FCMP++: verify FCMP++ proofs tooling"

**Artifact reviewed:** `monero-project/monero` PR #11407, head commit `5f4dae2`
(`FCMP++: verify FCMP++ proofs tooling`, author j-berman; milestone `fcmp++ hf`).
**Method:** line-by-line review of the PR diff (C++ consensus entry point, the
Rust FFI verifier, the FFI header, and the unit/performance tests). Every finding
below was independently re-checked against the source text; claims that did not
survive that check were removed (see *Corrections vs. earlier working draft*).
**Scope:** this document covers **only** the verification-tooling PR (#11407).
Carrot (#9559/#9697), the curve-tree DB integration (#11425), consensus wiring
(#11440), and RandomX V2 (#10038) are tracked separately and are **not** cleared
by this review.

**Severity legend:** CRITICAL · HIGH · MEDIUM · LOW · INFO.

---

## 1. Summary verdict

The verification **logic** in #11407 is, as far as the diff shows, sound: it
performs the expected structural checks, rejects malformed proofs and
non-canonical points, and uses the standard probabilistic batch-verification
idiom. The PR is **not** a standalone security blocker.

However it should **not merge as-is**. The material gaps are in **test coverage**
and **error-handling robustness**, not in the cryptographic checks themselves:

- There is **no test that an invalid proof is rejected** (HIGH). The verifier
  could be a no-op and CI would still pass.
- A thread-pool reset path can trigger a **use-after-free** (MEDIUM).
- The verify path **does not enforce the documented input/layer bounds**
  (MEDIUM, defense-in-depth).
- `assert!`/panic inside the consensus verifier **aborts the whole daemon**
  instead of returning an error code (MEDIUM).

A further structural caveat: the **prover and full consensus wiring are absent**
from this PR, so the verification path cannot yet be exercised end-to-end against
real transactions. "Approved by reviewers" here means the isolated verifier code
reads correctly — it is **not** evidence that the integrated FCMP++ consensus
check is correct.

---

## 2. Findings

### F-1 — No negative / rejection tests for the verifier  `[HIGH]`
**Where:** `tests/unit_tests/fcmp_pp.cpp`, `TEST(fcmp_pp, verify_from_file)`
(diff lines 1626–1691).
**What:** the only test that exercises the verification path loads a **valid**
proof and asserts success:
```
L1657  bool verify = fcmp_pp::verify(signable_tx_hash, fcmp_pp_proof, n_layers, tree_root, pseudo_outs, key_images);
L1665  ASSERT_TRUE(verify);
L1688  ASSERT_TRUE(rct::batchVerifyFcmpPpProofs(std::move(fcmp_pp_verify_inputs)));
```
There is **no `ASSERT_FALSE`** anywhere: no bit-flipped proof, no wrong
`signable_tx_hash`, no wrong `tree_root`, no mismatched `n_layers`, no
non-canonical key image, no torsioned point. The 1/2/4/8-input fixtures exist but
are only fed to the **performance** harness, not to a rejection assertion.
**Impact:** a verifier that always returned `true` would pass this suite. The
single most important property of a consensus verifier — *rejecting invalid
proofs* — is untested. This is the highest-value gap in the PR.
**Recommendation:** add negative tests that (a) flip one byte of the proof and
expect `false`, (b) change `signable_tx_hash` and expect `false`, (c) supply a
`tree_root` from the wrong layer/curve and expect `false`, (d) feed a
non-canonical / small-order key image and expect the `-7`/reject path, and (e)
run a **mixed batch** (one valid + one invalid) through `batchVerifyFcmpPpProofs`
and assert the whole batch is rejected.

### F-2 — Use-after-free on thread-pool reset in `batchVerifyFcmpPpProofs`  `[MEDIUM]`
**Where:** `src/ringct/rctSigs.cpp` (diff lines 1137, 1181, 1198–1212).
**What:** `batches` is a function-local `std::vector<ProofBatch>` (1137). Each
submitted job captures it **by reference**:
```
L1198  tpool.submit(&batch_verify_waiter,
L1199    [&batches, &all_valid, i](){ if(!fcmp_pp::verify(batches[i].batch)) all_valid.store(false); }, true);
...
L1212  CHECK_AND_ASSERT_THROW_MES(batch_verify_waiter.wait(), "Failed to batch verify FCMP++ proofs");
```
`wait()` returns `false` when the pool has been reset/aborted; in that case
`CHECK_AND_ASSERT_THROW_MES` **throws**, the exception unwinds out of the
function, and `batches` (and the `FcmpPpVerifyInput` unique_ptrs it owns, whose
deleter frees the Rust-side objects) is destroyed while a dequeued job may still
be dereferencing `batches[i].batch`.
**Impact:** use-after-free / double-free of Rust-allocated verify inputs on the
reset path. Narrow trigger (requires a concurrent pool reset, e.g. shutdown), but
it is a memory-safety violation, not a style issue.
**Recommendation:** do not throw while jobs may be in flight. Either (a) drain
the waiter before any throw and only then inspect the result, or (b) hold
`batches` in a `std::shared_ptr` captured by value by each job so its lifetime is
tied to the jobs, not the stack frame.

### F-3 — Verify path does not enforce `FCMP_PLUS_PLUS_MAX_INPUTS` / `MAX_LAYERS`  `[MEDIUM]`
**Where:** `src/fcmp_pp/fcmp_pp_rust/src/lib.rs`, `fcmp_pp_verify_input_new`
(diff lines 542–552); `src/cryptonote_config.h` (61, 66);
`src/fcmp_pp/fcmp_pp_types.cpp` (765, 806–809).
**What:** the Rust constructor only checks the lower bounds:
```
L544  if n_inputs == 0 || n_tree_layers == 0 { return -2; }
L547  if n_inputs != key_images.len { return -3; }
L550  if proof_len != fcmp_pp_proof_size(n_inputs, n_tree_layers) { return -4; }
```
The documented contract (521–523) says the **caller** must guarantee
`n_inputs <= 128` and `n_tree_layers <= 12`, but the C++ wrapper
`fcmp_pp::fcmp_pp_verify_input_new` (765) passes `n_tree_layers` straight through
without checking. The `MAX_INPUTS`/`MAX_LAYERS` guards (806–809) live **only** in
`membership_proof_len()` / `fcmp_pp_proof_len()`, which are used by the proof-size
**table test**, not by the verify path.
**Impact:** an out-of-range `n_tree_layers`/`n_inputs` reaches
`fcmp_pp_proof_size()` and `FcmpPlusPlus::read()`. The length-equality check at
550 means this is **not** a buffer over-read (the slice at 558 uses the real
`proof_len`), but it pushes unbounded values into the proof parser and the
membership-proof size arithmetic — a robustness/DoS surface and a reliance on an
unchecked caller invariant.
**Recommendation:** enforce `n_inputs <= FCMP_PLUS_PLUS_MAX_INPUTS` and
`n_tree_layers <= FCMP_PLUS_PLUS_MAX_LAYERS` **inside** `fcmp_pp_verify_input_new`
(return a distinct error code), rather than trusting the caller.

### F-4 — `assert!`/panic in the consensus verifier aborts the daemon  `[MEDIUM]`
**Where:** `src/fcmp_pp/fcmp_pp_rust/src/lib.rs` (diff lines 565, 584, 610).
**What:** the per-element null checks use `assert!`:
```
L565  assert!(!x.is_null());          // pseudo_outs element
L584  assert!(!compressed_ki.is_null());  // key_images element
L610  assert!(!input.is_null());      // fcmp_pp_n_inputs
```
`assert!` is compiled in **both** debug and release (only `debug_assert!` is
stripped). A panic inside a plain `extern "C"` function **aborts the process** on
current Rust.
**Impact:** if a null element ever reaches these loops (today the C++ side
guarantees non-null, so this is latent), the node **crashes** rather than
rejecting the transaction. For a consensus-critical path, abort-on-bad-input is a
worse failure mode than a graceful reject — it converts a malformed-input
scenario into a remote crash primitive.
**Recommendation:** replace `assert!` with an explicit null check that returns an
error code (e.g. `-8`), so the verifier rejects the input instead of aborting the
daemon. (This is the *correct* version of a concern that an earlier draft
mis-stated as "checks vanish in release".)

### F-5 — `key_images.clone()` per input in the batch loop  `[LOW]`
**Where:** `src/fcmp_pp/fcmp_pp_rust/src/lib.rs` (diff line 642).
**What:** `fcmp_pp_verify_input.key_images.clone()` allocates a fresh `Vec` for
every input on every `fcmp_pp_verify` call.
**Impact:** bounded (≤128 elements/proof × proofs-per-block) and dominated by the
elliptic-curve work, so this is a minor inefficiency, **not** a practical DoS
amplifier. Worth a follow-up only.
**Recommendation:** if `FcmpPlusPlus::verify` can take `&[EdwardsPoint]` instead
of an owned `Vec`, drop the clone.

### F-6 — OsRng in the verifier: confirm usage, note abort semantics  `[INFO / ADVISORY]`
**Where:** `src/fcmp_pp/fcmp_pp_rust/src/lib.rs` (diff lines 622, 635, 648).
**What:** `fcmp_pp_verify` seeds `multiexp::BatchVerifier` and passes
`&mut OsRng` into `FcmpPlusPlus::verify`, then finalizes with
`ed_verifier.verify_vartime()`.
**Assessment:** this is the **standard probabilistic batch-verification idiom**
(the same pattern Monero already uses for batch signature checking): random
coefficients combine the per-proof equations so that any invalid equation fails
with overwhelming probability, while valid proofs always pass. It is therefore
**not** a consensus-divergence bug — nodes will agree on accept/reject for any
real proof. Two residual notes for the cryptographic audit phase:
1. Confirm `OsRng` is used **only** for batch blinding and not in any way that
   affects soundness or completeness (requires reading `monero-oxide`'s
   `FcmpPlusPlus::verify`, out of scope for this diff-only review).
2. `OsRng` failure (or any panic) aborts the process — see F-4.

---

## 3. What the PR does correctly

Recorded so the findings are read in proportion:
- Entry null-guards on all four pointer args (`signable_tx_hash`, `proof`,
  `tree_root`, `out`) → `-1` (lib.rs 535–540).
- `n_inputs == key_images.len` consistency check → `-3` (547).
- `proof_len` equality check **before** slicing (550) — this is what makes the
  "over-read" concern in F-3 a non-issue.
- Malformed proof → `FcmpPlusPlus::read` `Err` → `-6` (574); non-canonical key
  image → `ed25519_point_from_bytes` `Err` → `-7` (585).
- Ownership discipline: `tree_root` is **copied** (`*tree_root`, 578), not moved,
  so the C++ `shared_ptr`/`destroy_tree_root` deleter stays correct — no
  double-free across the FFI.
- The bin-packing in `batchVerifyFcmpPpProofs` (1141–1177) correctly selects the
  minimum-weight batch; `batches.reserve(n_batches)` keeps references stable.

---

## 4. Cross-PR note (not a defect in #11407)

`CurveTrees::get_tree_root_from_bytes` (`src/fcmp_pp/curve_trees.cpp`, diff
93–104) chooses Helios vs Selene by `n_layers % 2`. The verify tooling receives an
already-typed `TreeRoot` and a separate `n_tree_layers`; nothing here cross-checks
that the enum variant matches the parity of `n_tree_layers`. That invariant is
established by the **callers** in #11425/#11440 — enforce and test it there, not
in this PR.

---

## 5. Corrections vs. the earlier working draft

The following claims appeared in a prior draft of this audit and were **removed or
re-scoped** after line-by-line verification:

| Prior claim | Status | Why |
|---|---|---|
| "`assert!` is compiled out in release → null deref UB" | **False** | Rust `assert!` is always compiled; only `debug_assert!`/C `assert` are stripped. Re-scoped to F-4 (abort-on-panic). |
| "`tree_root` dereferenced with no null check" | **False** | Null **is** checked at lib.rs:535 before the deref at 578. |
| "huge `n_tree_layers` → buffer over-read at `from_raw_parts`" | **False** | The length-equality check (550) precedes the slice; the real issue is the missing upper bound (F-3). |
| "OsRng makes verification non-deterministic → consensus split" (rated CRITICAL) | **Unsupported** | Standard probabilistic batch verify; valid→accept, invalid→reject w.h.p. Downgraded to advisory (F-6). |
| "key_images.clone() = DoS amplification" (rated MEDIUM) | **Overstated** | Bounded and dominated by EC work; minor perf only (F-5). |

Net: the audit's durable findings are **F-1 (no rejection tests)** and **F-2
(UAF on reset)**; F-3/F-4 are real robustness gaps; F-5/F-6 are minor. The two
"CRITICAL" labels in the prior draft were not supported by the source.

---

## 6. Limitations of this audit

- Based on the **PR diff only**. The `monero-oxide` crates
  (`full-chain-membership-proofs`, `monero-fcmp-plus-plus`, `helioselene`,
  `multiexp`, `generalized-bulletproofs`) were **not** inspected here; the
  soundness of `FcmpPlusPlus::verify`/`read`, `read_G` canonicality, and the
  batch-blinding use of `OsRng` are deferred to the cryptographic audit phase
  (seraphis-migration/monero#294, Phase 1a/2).
- The prover is not in this PR, so end-to-end accept/reject behavior against real
  FCMP++ transactions is **untestable** at this stage.

---

*Prepared for the Monero FCMP++ hard-fork security review. Findings F-1..F-6 and
the corrections table were validated by an independent committee review of the
prior draft.*

it should **not merge as-is**. The material gaps are in **test coverage**
and **error-handling robustness**, not in the cryptographic checks themselves:

F1 has been address.

F-1 — No rejection tests HIGH
"Added in the latest."
Status: ✅ If true, this resolves the highest-severity finding. You should verify the new tests actually exercise: (a) bit-flipped proof, (b) wrong signable_tx_hash, (c) wrong tree_root layer/curve, (d) non-canonical key image, (e) mixed valid+invalid batch.

Updated Verdict for F-1
The author's reply ("Added in the latest") is technically true, and adding those 3 tests fundamentally resolves the HIGH severity finding (the verifier is no longer untested against invalid inputs).
However, they did not go the extra mile to test the tree_root or key_image edge cases that the auditor explicitly requested. 

https://github.com/monero-project/monero/pull/11407/changes?spm=a2ty_o01.29997173.0.0.7400c921o8pXhN#r4503249689

Still reviewing F2-F5 (I have limited time and my skills are not up to this so relying heavily on AI.

https://github.com/monero-project/monero/pull/11407#issuecomment-6641679228

[nullius]

I’m shocked at some people’s collective psychological denial about the obvious reality of whether a “currency” is fungible money, or a nonfungible token (NFT).  Then, I’m shocked at myself for being so fucking naïve.

XMR people will get this:  I own a brick-and-mortar bookstore.  A drug dealer or bank robber comes in to buy some books.  I don’t know what they do for their money; it’s not as if they wear a neon sign announcing it.  They’re an erudite drug-dealing bank robber, so they pick up an academic textbook on erotic cryptography.  The cover price is $100.  They hand me a $100 bill, I ring them up, and now, it’s my $100 bill.  And that’s that.

No “AML checkers”.  No “risk scores”.  No “taint doesn’t exist! (except when it does)”.  My $100 bill is worth $100.  If I take it to the bank and deposit it into my KYCed bank account (LOL), neither the bank nor I will ever know that this $100 was recently stolen by h4x0ring a bank vault with kilos of cocaine.

If something doesn’t work that way, it’s not money.  It’s an NFT.  Too bad my failure to blind myself to this reality is making me as popular as a whore in a church.

I will crush the myth that Bitcoin’s fully transparent blockchain has any kind of benefit!

Whereas I’m the only one in this thread who absolutely rejects the concept of taint.  I shall never, ever use an “AML checker”.  I swear on my PGP key.

I could be open-minded about getting my dick stomped on an anvil [sexually explicit link]; I am absolutely closed-minded about “AML checkers”.

Coin taint and blacklisting are what break Bitcoin’s fungibility.  BTC is an NFT:  A non-fungible token, due to coin taint and blacklisting.  The subset of Bitcoiners who refuse to acknowledge this are either living in a Reality Distortion Field, or still under the influence of the blockchain transparency fetishization with which Mike Hearn, et al. poisoned Bitcoin early on.  I identify a lack of fungibility as the biggest long-term economic threat to Bitcoin.

If people start using BTC directly for payments, instead of constantly relying on conversion to fiat currency, we will be reducing the need to resort to intermediaries and, consequently, exposure to some of these restrictions. Because that was the idea behind Bitcoin: to eliminate intermediaries.

Perhaps it would be important to promote more acceptance of BTC as a means of payment by businesses and service providers.

I believe this would be a very important step towards achieving true financial freedom.

The XMR community has done the best of anyone to work towards building exactly what you say, with XMR:  Work for XMR, get paid in XMR, buy everything you need in XMR, live within the XMR economy.  They know this ideal, and they’ve been pushing for it hard.

Well, that's good news for those of us who are code-illiterate.

Hey, don’t sell yourself short.  IMO, the best way to learn is to read code.  But I don’t recommend starting with Monero sources.

Tor's Debian repository makes keeping it up to date super easy.

If you ever exit from Microsoftland, perhaps you may use Debian, perhaps something else.

When you have your system sources and a system developer toolchain right there on your disk,^* it’s like driving a car where you can pop the hood and tinker with it.  Perhaps that way, you may one day learn to be a bit of an auto mechanic.  But it won’t happen if you buy a car that has the hood welded shut.

^* Debian and some other Linux distros don’t provide all of this by default; you need to know what packages to install.  I think it should all be in the default install.

[Hueristic]

If something doesn’t work that way, it’s not money.  It’s an NFT.  Too bad my failure to blind myself to this reality is making me as popular as a whore in a church.

I will crush the myth that Bitcoin’s fully transparent blockchain has any kind of benefit!

Agreed on the fungibility, bitcoins utility has changed to store of value with NGU and is wholly institutional co-opted and owned thanks to blockstream.

But on the bright side it means BTC and Monero will never compete.

Tor's Debian repository makes keeping it up to date super easy.

If you ever exit from Microsoftland, perhaps you may use Debian, perhaps something else.

When you have your system sources and a system developer toolchain right there on your disk,^* it’s like driving a car where you can pop the hood and tinker with it.  Perhaps that way, you may one day learn to be a bit of an auto mechanic.  But it won’t happen if you buy a car that has the hood welded shut.

^* Debian and some other Linux distros don’t provide all of this by default; you need to know what packages to install.  I think it should all be in the default install.

I'm a Artix fanboi myself but if I were to go debian it would be Devuan.

[nullius]

If something doesn’t work that way, it’s not money.  It’s an NFT.  Too bad my failure to blind myself to this reality is making me as popular as a whore in a church.

I will crush the myth that Bitcoin’s fully transparent blockchain has any kind of benefit!

Agreed on the fungibility, bitcoins utility has changed to store of value with NGU and is wholly institutional co-opted and owned thanks to blockstream.

Although I’m a critic of the institutional co-option, this general direction of blame is backwards.  Taint was substantially invented in 2011–2013 by Mike Hearn—one of the most dangerous adversaries of Bitcoin Core and of the Blockstream people.  He and Gavin Andresen poisoned Bitcoin early on.  Whereas in 2013, Hal Finney was discussing with future Blockstreamers Adam Back and Greg Maxwell how to implement Zerocoin for Bitcoin.  Zerocoin was the earliest research antecedent of Zcash—but intended for Bitcoin, not altcoin; if Zerocoin had been implemented as originally planned, Monero would have been obsolete before it existed.

The enemies of Bitcoin privacy and fungibility:

Subject: Freezing BitCoin addresses by regulating miners

From time to time governments freeze the assets of people or organizations they believe to be criminal. [...] BitCoins apparent inability to do this will certainly make law enforcement uncomfortable with the concept.

But in reality, by the time BitCoin is large enough for this to be a real issue it will be quite possible to freeze bitcoins by requiring miners to exclude transactions from blacklisted addresses.

The outer quotes link to posts of mine that provide more historical context:

Subject: Gavin will visit the CIA

I want to get this out in the open because it is the kind of thing that will generate conspiracy theories:  I'm going to give a presentation about Bitcoin at CIA headquarters in June at an emerging technologies conference for the US intelligence community.

One of most commonly raised issues with Bitcoin is that of crime and punishment. Over the past 40 years our societies have, through both fair means and foul, built an integrated anti-money laundering system that attempts to let governments trace the proceeds of crime.

[...] Blacklist providers maintain sets of outputs that are blacklisted or tainted in some way, for instance because the owner reported them stolen or because it’s believed they are owned by some criminal enterprise. [...]

Hal Finney’s third-to-last post discussed one of future Blockstream co-founder and CEO (2014–present) Adam Back’s ideas for doing Zerocoin:

⇾ Re: Zerocoin: Anonymous Distributed E-Cash from Bitcoin
I really like Adam's very creative idea earlier in this thread to have a pure-zerocoin system:

https://bitcointalk.org/index.php?topic=175156.msg2420768#msg2420768

Hal Finney’s second-to-last post discussed Zerocoin with future Blockstream co-founder and CTO (2014–2018) Greg Maxwell:

⇾ Re: Zerocoin when?

[—Greg Maxwell talking about zerocoin.—]

The zerocoin part does more than defend against DOS, doesn't it? It also provides a degree of anyonymity, if I understand it. In the conventional multi-party anti-taint protocol, every participant knows the mapping from inputs to outputs. But in your improved protocol using libzerocoin, nobody sees the mapping. Now, this requires more than two participants, so considerable organization is needed to coordinate.

It’s amazing what one can learn on this forum!

Let’s please also not forget that although I don’t recall off the top of my head exactly who invented what, IIRC, it was basically Blockstreamers who invented CT and Bulletproofs that Monero uses to keep amounts private.

Incidentally, Hearn and Andresen designed the original bigblock fork-attack on Bitcoin in 2015—which later led by various twists and turns to Bitcoin Cash in 2017.  A few relevant news articles about Hearn and/or Andresen:

• https://spectrum.ieee.org/tech-talk/computing/networks/the-bitcoin-for-is-a-coup
• https://www.wired.com/2016/05/craig-wright-privately-proved-hes-bitcoins-creator/

But on the bright side it means BTC and Monero will never compete.

I’m not so happy about that, but I am done making excuses for Bitcoin’s catastrophic lack of privacy and fungibility!  It’s such a shame; Satoshi wanted better, as you know:

First, here, we need to admit that Bitcoin has a problem:  Its transparency is a design flaw, which Satoshi knew about, didn’t know how to fix, and underestimated the impact of.  Mixers are a Band-Aid on a gaping wound.  Bitcoin’s blockchain is like publishing your bank statements in an append-only database on the Internet.

I wouldn't call it a design flat, I'd call it a design choice. It's a choice that brought Bitcoin where we are today.

No.  Satoshi didn’t choose this.  He wanted to build Bitcoin differently, but he didn’t know how.  Not to knock Satoshi!  It’s a hard problem.  In 2008–2010, the needed technology didn’t exist.

This post will eventually have the maximum 100 merits from me.  The list of people who have sent it merit thus far is interesting:  Bitcoin experts and legends, privacy advocates, both Zcash and Monero users.

Merited by nullius (50), garlonicon (20), o_e_l_e_o (4), Foxpup (3), ABCbits (2), Hueristic (1), BitcoinFX (1)
This is a very interesting topic.  If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.

Originally, a coin can be just a chain of signatures.  With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations.  It's the need to check for the absence of double-spends that requires global knowledge of all transactions.

The challenge is, how do you prove that no other spends exist?  It seems a node must know about all transactions to be able to verify that.  If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before.  Do you have any ideas on this?

It's hard to think of how to apply zero-knowledge-proofs in this case.

We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.

[LoyceV]

No “AML checkers”.  No “risk scores”.  No “taint doesn’t exist! (except when it does)”.  My $100 bill is worth $100.  If I take it to the bank and deposit it into my KYCed bank account (LOL), neither the bank nor I will ever know that this $100 was recently stolen by h4x0ring a bank vault with kilos of cocaine.

Now add a few zeros, and your bank is going to ask you where you got that $100,000. That's the reality of regulation, and also the reason why Monero is banned from centralized exchanges here. I like Monero, but if I want to buy anything that's registered, Bitcoin is much easier.
Monero is great for buying VPN services and anything privacy related.

[nullius]

🍿 LoyceV versus Monero! ✊️

Now add a few zeros, and your bank is going to ask you where you got that $100,000.

You’re overtly moving the goalposts from fungibility to another problem, by over-extending my hypothetical example to take it in a different direction. 

I like Monero, but if I want to buy anything that's registered, Bitcoin is much easier.

“I like Bitcoin, but if I want to buy anything that’s registered, fiat currency in bank accounts is much easier.” 

Why do you even bother with Bitcoin?  Only for “number go up” speculation, which I’m much more than beginning to think is a security vulnerability?  It’s a vector of economic attack to co-opt Bitcoin from its purpose of freedom to be a toy for banks and billionaires.

If I were here for something that’s “easier” with regulated finance, then instead, I would’ve gone to work for a financial institution when I was twenty years old.  I had the opportunity.  I’d have much more money than I do now—and I wouldn’t give a fuck about Bitcoin, except maybe as market play like any other thing that can be traded for profit.

Monero is great for buying VPN services and anything privacy related.

So, Monero is only ghetto-money in what I’ve called “the stigmatization and ghettoization of privacy”.  Only useful in the privacy-ghetto.  I prefer the Monero community’s vision of an XMR circular economy.

the reason why Monero is banned from centralized exchanges here.

No, the reason why Monero is banned from your CEX is that Bitcoin set a bad precedent.  It’s Bitcoin’s fault.  More precisely:  It’s the fault of everyone who wanted to keep Bitcoin fully transparent, which inevitably walks Bitcoiners down Mike Hearn’s garden path.

Bitcoin devs were discussing all of this in 2013, right here on this forum; we still don’t have it in 2026.

^^^ The technology wound up in an altcoin, Zcash, when it should have been in Bitcoin.

Now compare Monero, which is banned from centralized exchanges in EU-countries. Owning Monero isn't illegal, but governments don't like privacy and want an ever growing amount of information about everyone. If Bitcoin would offer on-chain privacy, chances are it would be banned, and I'd argue banning Bitcoin doesn't make it better.

You forget the fait accompli factor that I described earlier in the thread.

LoyceV, you’re subtly giving tacit support Mike Hearn’s taint agenda while talking out of both sides of your mouth to try to appease the privacy community.  It’s remarkable that you were in the paid ChipMixer campaign, while I was doing unpaid, unsolicited promotion of ChipMixer—and now, you preach keeping Bitcoin as a taint-enabled system (= fully transparent blockchain) while you urge reality-denial about taint.

I also just noticed a post edit in the other thread that shows you’re really arguing in bad faith, to dodge your own words when I call you on them; I’ll take that up there.

"Taint" only exists if people want it to exist, and the companies who's business model is to sell "the notion of taint" are good at convincing more and more people they need to pay them for their "services".

Please take notice that I’m preparing soon to make a new thread about fungibility—and I will delete any posts, including yours, which spread this Reality Distortion Field misinformation.  I think it’s overall beneficial that you’re airing your views in a thread full of highly experienced Bitcoiners, and now amongst XMR people, where I and others can rebut you on the merits—but in a thread I will intend for the inexpert general public, your taint-denial is misleading and actively dangerous to newbies.

In the other thread, you’re still dodging this:

do you personally guarantee their funds

No. What kind of question is that anyway? I'm not an insurance company, and I'm not earning anything from someone else's coins.

In substantial essence, you’re advising people to stick their heads in the sand about taint.  It’s irresponsible, as people could lose funds.  So, you admit that people who take your advice will be the bagholders if taint causes them financial losses?

[Hueristic]

Interesting conversation and wish I had the time and health at the moment to really participate but I have neither atm so will lurk it until I'm able to participate with the dedication this deserves.