Thus solving the problem once and for all! 😂

The good news is that nodes still control the network, despite political games claiming they do not. Time to reassert this forcefully! #bip110

It doesn't: Merely writing a full node client or a fork doesn't give anybody control over anything. People need to voluntarily download and run the code in order for it to matter.

If BIP-110 succeeds that would not indicate Ocean mining or whoever hijacked Bitcoin, but that their vision of what Bitcoin is has wider legitimacy than core's does. I personally think that is the case, but let's see.

I'd recommend using a client that has WoT filters like I.E @Jumble, I hardly ever see clawdbots in replies.

The first clue was that he's in a group that self-titles "The Intellectual Dark Web." 🤡😂

I wondered if you meant to write something like "Lagarde almost sounds like a Bitcoiner when she talks about the need for **nation-states** to reclaim their financial sovereignty".

This would make sense to me because I know the ECB has frequently sold the digital euro as a way to make financial infrastructure independent of US companies.

If you really meant to put "individuals" in that sentence I don't follow your reasoning as I don't think Lagarde has ever expressed much interest in individual financial sovereignty. For European nations certainly, but individual Europeans not so much.

> In fact, Lagarde almost sounds like a bitcoiner when she talks about the need for _individuals_ to reclaim their financial sovereignty.

I assume you meant to write _states_ here? I don't think Madame Lagarde has much regards for individual financial sovereignty.

FWIW I asked Maple about this and here's what it said:

*****

Yes, on all major Linux distributions, package installation is cryptographically signed and verified by default—but the implementation varies by distribution and package format.

## How Major Distros Handle Signing

**Debian/Ubuntu (APT)**
- **Repository metadata** is signed with GPG keys. APT verifies the `Release` file signature before trusting any package lists.
- **Individual packages** are typically signed by the maintainer's key, though APT primarily trusts the repository metadata rather than verifying every package signature independently by default.
- Keys are stored in `/etc/apt/trusted.gpg.d/` or managed via `signed-by` in sources lists.

**RHEL/CentOS/Fedora (RPM/DNF/YUM)**
- **Packages** are GPG-signed by the packager (the `.rpm` file contains the signature).
- **Repository metadata** is also signed.
- DNF/YUM verify package signatures before installation using keys in `/etc/pki/rpm-gpg/`.
- You can check a package's signature with: `rpm -K package.rpm`

**Arch Linux (Pacman)**
- **Packages** are signed by Arch Linux developer or Trusted User keys.
- Pacman has a web of trust model; the `archlinux-keyring` package distributes trusted keys.
- Signatures are stored as separate `.sig` files.

**Alpine Linux (APK)**
- Uses **RSA signatures** (not GPG). Each package has a corresponding `.rsa.sig` file.
- Public keys are stored in `/etc/apk/keys/`.

**openSUSE (ZYpp/RPM)**
- Similar to Fedora: RPM packages are GPG-signed, and repository metadata is signed.

## Universal Package Formats

- **Flatpak**: OSTree commits are signed with GPG; apps are verified against remotes.
- **Snap**: Packages are signed; the snapd daemon verifies signatures from the Snap Store.
- **AppImage**: Generally **not signed** by default (though some projects embed signatures separately).

## Important Caveats

1. **Manual downloads**: If you manually download a `.deb` or `.rpm` from a website and install it with `dpkg -i` or `rpm -i`, signature verification may be skipped or require manual key import. Using the distro's package manager (APT/DNF) enforces verification.

2. **Disabled verification**: You can disable signature checking (e.g., `apt-get --allow-unauthenticated` or `rpm --nosignature`), but this defeats the security model.

3. **Third-party repositories**: When adding a new repo, you must manually import the GPG key. The security depends on whether you verify the key fingerprint through a trusted channel.

4. **Build-from-source**: Compiling from source code (e.g., `make install`) bypasses the package signing system entirely.

## Verification Commands

```bash
# Debian/Ubuntu: Check repository key
apt-key list

# Fedora/RHEL: Verify a package signature
rpm -qi package_name | grep Signature

# Arch: Verify package databases
pacman-key --list-sigs

# Alpine: Check keys
ls /etc/apk/keys/
```

**Bottom line:** Modern Linux distributions treat cryptographic signing as mandatory for their official repositories, protecting against man-in-the-middle attacks and package tampering. However, the security is only as strong as your key management practices and whether you verify keys when adding third-party repositories.

I'm not an expert on this but I know Linux Mint uses APT as the package manager - How APT does things is that each repository has a GPG key that signs each package. The repository itself is imported from a list embedded in the OS. So you really don't need to verify signatures in normal operation. You should mainly do it when downloading the OS itself and making bootable media since this is the start of the trust chain.

Shinobi's running damage control for Epstein associates himself - He sure throws a lot of stones from that glass house. 🤡

I'm more inclined to see it as just hodlers offloading into doing something nice for their life. Just as a personal anecdote I paid off my student loan debt last June with some of my corn. I didn't sell a very large portion of it though, and I plan to stack more.