The Assault on Individual Sovereignty: How to Shield Your Node in Times of Pressure
The pattern is clear: centralisation advances with every crisis. Here are concrete steps to fortify your sovereignty, your infrastructure, and your node in uncertain times.
August 18, 2026 | By Omar-VgWs
Table of Contents:
- The Assault on Individual Sovereignty: How to Shield Your Node in Times of Pressure
- StartOS Configuration
- 🛡️ Bitcoin Core as a Pure Monetary System (StartOS)
- Configuration Adjustments to Restrict Arbitrary Data (OP_RETURN, Inscriptions, NFTs, etc.)
- 📌 Fundamental Principle
- 🔴 HIGH PRIORITY — Anti-Spam / Bitcoin as Money
- ⚡ MEDIUM PRIORITY — Stability and Performance
- 🔧 OTHER SETTINGS — Indexing and Wallet
- 📋 Visual Summary of Applied Configuration
- 🎯 Benefits of This Configuration
- 📝 Note on Bitcoin Core 31.1:7
- 🛡️ Bitcoin Core as a Pure Monetary System (StartOS)
- Umbrel Configuration
- 🛡️ Bitcoin Core on Umbrel — Pure Monetary Focus
- Configuration Adjustments to Restrict Arbitrary Data (OP_RETURN, Inscriptions, NFTs, etc.)
- 📌 Fundamental Principle
- 🔴 HIGH PRIORITY — Anti-Spam / Bitcoin as Money
- ⚡ MEDIUM PRIORITY — Stability and SSD Longevity
- 🔒 MEDIUM PRIORITY — Peer Settings (Network and Privacy)
- 🔧 INTERFACES — Security
- 📋 Advanced Configuration Block (
bitcoin.conf) - ⚠️ Important Warnings
- ✅ Final Checklist — Applied Configuration (User-Confirmed State)
- 🎯 Benefits of This Configuration
- 📝 Note on LND Compatibility
- Closing
- 🛡️ Bitcoin Core on Umbrel — Pure Monetary Focus
The pattern repeats itself
Whatever the situation presenting itself today —political, economic, regulatory, or social— the diagnosis is relatively clear for those who observe carefully: individual sovereignty, genuine civic participation, and support for decentralisation are under siege.
The free individual, financial peace, the ability to decide over one's own assets without coercive intermediaries… all these principles appeared vulnerable. And, as occurred during the COVID season (2020–2023) —when the health emergency served as a pretext to restrict fundamental liberties and accelerate centralised control— that perceived “vulnerability” was exploited. The excuse changes; the mechanism remains the same.
Now, those very pillars are being assailed head-on.
What can be observed
Recognising the pattern is the first step towards responding with intelligence:
- Progressive centralisation. Every crisis becomes the perfect justification to concentrate power, regulate what was once free, and shackle what was once autonomous.
- The narrative of fear. The idea takes hold that decentralisation is dangerous, that the individual requires guardianship, that “someone” must manage what we once managed for ourselves.
- Silent suffocation. Sometimes all it takes is an ambiguous regulation, a selective tax, an access restriction, or a smear campaign to erode the ground beneath our feet.
The lesson of 2020–2023 is valuable and clear: what you defend in calm times, you preserve in times of urgency. What you neglect, is taken from you.
Adjustments and procedures: strengthen your node
Faced with this landscape, the diagnosis finds its purpose when translated into action. Below, I share a series of adjustments and procedures so that you may strengthen your node —your space of autonomy, your personal infrastructure, your sphere of sovereign decision-making— to the extent that is possible.
1. Review your sovereignty infrastructure
- Diversify the custody of your assets: avoid depending on a single intermediary.
- Seek redundancy for your node (network, information, communication).
- Self-custody, self-responsibility, self-verification.
2. Reduce your exposure surface
- Minimise the surrender of unnecessary personal data.
- Review permissions, subscriptions, and digital dependencies you can simplify.
- Every point of dependency you remove is a door you reclaim.
3. Strengthen your decentralised network
- Support local, community-driven, open-source projects.
- Forge bonds with people who share these principles. Decentralisation is distribution, connection, community.
- Share knowledge. A node that communicates multiplies.
4. Document and back up
- Make backups of everything you consider essential: information, keys, documents, projects.
- Preserve your memory on your own terms.
5. Keep a cool head
- The assault seeks impulsive reaction, panic, paralysis. You can choose strategic calm.
- Inform yourself through diverse sources. Question with genuine curiosity.
- Act from serenity and clarity.
Practical configurations: StartOS and Umbrel
For those who run their own node and wish to bring these principles into concrete infrastructure, I share two specific breakdowns depending on the configuration you use.
StartOS Configuration
🛡️ Bitcoin Core as a Pure Monetary System (StartOS)
Configuration Adjustments to Restrict Arbitrary Data (OP_RETURN, Inscriptions, NFTs, etc.)
Below, is the consolidated summary of every adjustment applied to Bitcoin Core with the objective of focusing your node exclusively on Bitcoin as sound money, rejecting the propagation and storage of non-monetary noise.
📌 Fundamental Principle
An individual node cannot prevent miners from including inscriptions in blocks, but it can ensure that your node does not propagate, does not prioritise, and does not store that type of data. This reduces your exposure to spam and improves node efficiency.
🔴 HIGH PRIORITY — Anti-Spam / Bitcoin as Money
| # | Setting | Action | Final Value | Rationale |
|---|---|---|---|---|
| 1 | Relay OP_RETURN Transactions | ❌ DISABLE | false |
The most critical adjustment. OP_RETURN is the primary vector for inscriptions (Ordinals), on-chain NFTs, token metadata (BRC-20, ARC-20), and arbitrary blockchain messages. Disabling it means your node ceases to retransmit these transactions. |
| 2 | Max OP_RETURN Size | ✅ MAINTAIN | 83 bytes |
Limits the maximum size of OP_RETURN data your node will accept. |
| 3 | Max Mempool Size | ✅ REDUCE | 100 MiB |
Restricts the space available for large transactions (typical of inscriptions). 100 MiB is sufficient for normal personal use. |
| 4 | Blocks Only | ✅ DISABLED | false |
Allows receipt of mempool transactions (not only blocks). |
⚡ MEDIUM PRIORITY — Stability and Performance
| # | Setting | Action | Final Value | Rationale |
|---|---|---|---|---|
| 5 | Database Cache | ✅ CONFIGURE | 5000 MiB |
Optimal for 16 GB RAM (~31%). Improves validation and queries, leaving ~11 GB free for the system and other services. |
| 6 | Database Batch | ✅ INCREASE | 67108864 Bytes (~64 MB) |
More efficient disk writes → fewer I/O operations → greater SSD longevity. |
| 7 | Use V2 P2P Transport Protocol | ✅ ENABLE | true |
Encrypts inter-node communication (BIP324); more efficient and modern. |
| 8 | Onlynet | ✅ MAINTAIN | onion (Tor) |
Maximum privacy. Tor connections only. |
| 9 | Work Queue | ✅ INCREASE | 256 requests |
Improves capacity to handle multiple RPC connections (LND, BTCPay, Fulcrum). |
| 10 | Threads | ✅ MAINTAIN | 16 threads |
Appropriate for the hardware. |
| 11 | RPC Server Timeout | ✅ MAINTAIN | 30 seconds |
Suitable standard value. |
🔧 OTHER SETTINGS — Indexing and Wallet
| # | Setting | Action | Final Value | Rationale |
|---|---|---|---|---|
| 12 | ZeroMQ Enabled | ✅ ENABLED | true |
Critical for Lightning (LND). Real-time notifications of blocks and transactions. |
| 13 | Transaction Index | ✅ ENABLED | true |
Essential for Lightning, wallets, and BTCPay. Enables lookup of any transaction by TXID. |
| 14 | Coinstats Index | ❌ DISABLED | false |
Consumes unnecessary resources. Only useful for specific UTXO set queries. |
| 15 | Pruning | ✅ MAINTAIN | 0 MiB |
Full node without pruning. Maximum security and validation. (2.88 TB free space available.) |
| 16 | Serve Bloom Filters (BIP37) | ❌ DISABLED | false |
BIP37 is vulnerable to DoS attacks. Electrs/Fulcrum already provide efficient filters (BIP158). |
| 17 | Persist Mempool | ✅ ENABLED | true |
Recovers transactions after restarts. |
| 18 | Avoid Partial Spends | ✅ ENABLED | true |
Improves privacy. |
| 19 | Compute Compact Block Filters (BIP158) | ✅ ENABLED | true |
Required for SPV wallets. |
| 20 | Download UTXO Snapshot (assumeutxo) | ❌ DO NOT USE | — | Do not enable if the blockchain is already synchronised. May compromise full validation. |
| 21 | Enable IPC | ❌ DISABLED | false |
Not required unless local services need a Unix socket. |
📋 Visual Summary of Applied Configuration
┌─────────────────────────────────────────────────────┐
│ BITCOIN CORE 31.1 — MONETARY NODE │
├─────────────────────────────────────────────────────┤
│ │
│ 🚫 ANTI-SPAM: │
│ • Relay OP_RETURN: OFF │
│ • Max OP_RETURN Size: 83 bytes │
│ • Max Mempool: 100 MiB │
│ │
│ ⚡ PERFORMANCE: │
│ • Database Cache: 5000 MiB │
│ • Database Batch: 64 MB │
│ • Work Queue: 256 requests │
│ • V2 P2P Transport: ON │
│ │
│ 🔒 PRIVACY: │
│ • Onlynet: onion (Tor only) │
│ │
│ 🔗 LIGHTNING-READY: │
│ • ZeroMQ: ON │
│ • Transaction Index: ON │
│ • BIP158 Filters: ON │
│ │
│ 🗑️ WITHOUT EXCESS: │
│ • Coinstats Index: OFF │
│ • Bloom Filters (BIP37): OFF │
│ • Pruning: OFF (full node) │
│ │
└─────────────────────────────────────────────────────┘
🎯 Benefits of This Configuration
| Benefit | Detail |
|---|---|
| 🎯 Rejection of inscriptions/NFTs | Does not propagate arbitrary OP_RETURN data |
| ⚡ High performance | Cache optimised for 16 GB RAM |
| 💾 SSD longevity | Larger batch size = fewer writes |
| 🔒 Maximum privacy | Tor connections only |
| ⚡ Stable Lightning | ZeroMQ + txindex + BIP158 enabled |
| 🧹 Efficient resources | No unnecessary indexes |
| 🛡️ Security | Full node, no pruning, no assumeutxo |
📝 Note on Bitcoin Core 31.1:7
This configuration is 100% compatible with version 31.1:7. The update includes:
- ✅ Fix for excessive chainstate rewriting → reduced SSD wear
- ✅ Fix for IP leak in
-privatebroadcast→ enhanced privacy over Tor - ✅ Regular chainstate compaction → reduced RAM usage
No additional adjustments are required following the update.
Umbrel Configuration
🛡️ Bitcoin Core on Umbrel — Pure Monetary Focus
Configuration Adjustments to Restrict Arbitrary Data (OP_RETURN, Inscriptions, NFTs, etc.)
Below, is the consolidated summary of every adjustment applied to Bitcoin Core 31.0.0 on Umbrel (8 GB RAM / 2 TB SSD) with the objective of focusing your node exclusively on Bitcoin as sound money, rejecting the propagation and storage of non-monetary noise.
📌 Fundamental Principle
An individual node cannot prevent miners from including inscriptions in blocks, but it can ensure that your node does not propagate, does not prioritise, and does not store that type of data. This reduces your exposure to spam and improves node efficiency.
🔴 HIGH PRIORITY — Anti-Spam / Bitcoin as Money
| # | Setting | Action | Final Value | Rationale |
|---|---|---|---|---|
| 1 | Relay OP_RETURN (datacarrier) |
❌ DISABLE | 0 |
The most critical adjustment. OP_RETURN is the primary vector for token metadata, stamps (SRC-20), runes, and similar "non-monetary data" protocols. Disabling it means your node neither accepts nor propagates those transactions. |
| 2 | Relay Bare Multisig (permitbaremultisig) |
❌ DISABLE | 0 |
"Bare" multisig is used to embed arbitrary data on-chain. Disabling it restricts another vector of non-monetary spam. |
| 3 | Max Allowed Size of Arbitrary Data (datacarriersize) |
⬜ INERT | (83000 by default) | Only takes effect when datacarrier=1. With datacarrier=0, it becomes irrelevant. Should you prefer an intermediate stance, the classic value would be 80 bytes. |
| 4 | Maximum Mempool (maxmempool) |
✅ MAINTAIN | 300 MB |
A good balance for 8 GB RAM. During spam/inscription storms, it caps your RAM and CPU exposure. |
| 5 | Min Fee to Relay (minrelaytxfee) |
⚠️ OPTIONAL | Default (0.1 sat/vB) or 1–2 sat/vB | Makes witness-embedded inscriptions (ordinals) more costly when the mempool is empty. Raising it is the only partial means of slowing ordinals, since they do not use OP_RETURN but rather the taproot witness. |
⚡ MEDIUM PRIORITY — Stability and SSD Longevity
| # | Setting | Action | Final Value | Rationale |
|---|---|---|---|---|
| 6 | Cache Size (dbcache) |
✅ MAINTAIN | 450 MiB |
With 8 GB RAM and other apps running (Electrs, Mempool), do not inflate it. Raise to 1024–2048 only during a reindex. |
| 7 | Prune Old Blocks (prune) |
✅ MAINTAIN | 0 GB |
With 2 TB, full chain: maximum sovereignty, zero prune/re-download cycles (better for the SSD). |
| 8 | Transaction Indexing (txindex) |
✅ ON (final decision) | 1 |
Initially recommended OFF, but upon confirming the future use of LND, it was left ON because LND requires txindex=1 to function correctly. |
| 9 | Persist Mempool (persistmempool) |
✅ ON | ON |
Recovers transactions after restarts. Write cost only on restarts. |
| 10 | Memory Expiration (mempoolexpiry) |
✅ MAINTAIN | 336 h (14 days) |
Tested and stable default. |
🔒 MEDIUM PRIORITY — Peer Settings (Network and Privacy)
| # | Setting | Action | Final Value | Rationale |
|---|---|---|---|---|
| 11 | Peer Bloom Filters (BIP37) | ❌ DISABLE | OFF |
BIP37 carries DoS and privacy risks; it is not recommended. |
| 12 | Peer Block Filters (BIP157) | ❌ DISABLE | OFF |
If you are not serving BIP157 light clients, you save writes and several GB of indexing. |
| 13 | Block Filter Index | ❌ DISABLE | OFF |
Dependent on the above. Switch it off after disabling Peer Block Filters. |
| 14 | Outgoing Peers | ✅ Clearnet + Tor ON, I2P OFF | — | I2P provides very few peers and adds latency. Tor preserves privacy. |
| 15 | Clearnet over Tor (proxy) | ❌ OFF | OFF |
Routing everything through Tor noticeably degrades performance. |
| 16 | Incoming Peer Connections | ❌ OFF | OFF |
Saves bandwidth and CPU. |
| 17 | Max Peer Connections | ✅ MAINTAIN | 125 (default) |
Works well with 8 GB. |
🔧 INTERFACES — Security
| # | Setting | Action | Final Value | Rationale |
|---|---|---|---|---|
| 18 | Public REST API | ❌ OFF | OFF |
No authentication = DoS/privacy risk. |
| 19 | IPC Mining Interface | ❌ OFF | OFF |
Only required if mining with Stratum V2. |
| 20 | RPC Work Queue | ✅ MAINTAIN | 128 (default) |
Sufficient for personal use. |
📋 Advanced Configuration Block (bitcoin.conf)
# ===== Monetary focus: restrict non-financial data (relay policy) =====
datacarrier=0 # Do not relay OP_RETURN (tokens, metadata, stamps)
permitbaremultisig=0 # Do not relay bare multisig (another data vector)
# ===== Optional: make witness-embedded inscriptions (ordinals) more costly =====
# minrelaytxfee=0.00002 # 2 sat/vB (unit in conf is BTC/kvB)
# incrementalrelayfee=0.00002
⚠️ Important Warnings
| # | Warning |
|---|---|
| 1 | This is relay policy, not consensus. Your node will continue to validate blocks containing inscriptions (miners decide what enters the chain); your node will simply cease to propagate them actively. Your wallet and apps will function as normal. |
| 2 | Ordinals do NOT use OP_RETURN; they embed data in the witness (taproot). Standard Bitcoin Core cannot block them entirely; raising minrelaytxfee only makes their creation more costly. datacarrier=0 does halt OP_RETURN-based protocols (runes, stamps, token metadata). |
| 3 | datacarrier=0 also affects your own transactions containing OP_RETURN should you issue them from your node. |
| 4 | If you raise minrelaytxfee, also adjust incrementalrelayfee, and bear in mind that during periods when the mempool is empty, your node will not relay transactions below that threshold. |
| 5 | Upon saving, Umbrel restarts bitcoind. Disabling indexes is immediate; re-enabling them afterwards may require a reindex. |
✅ Final Checklist — Applied Configuration (User-Confirmed State)
Peer Settings
- Outgoing: Clearnet ON + Tor ON, I2P OFF
- Proxy (clearnet via Tor): OFF
- Incoming: OFF
- Peer Block Filters: OFF → Block Filter Index: OFF
- Peer Bloom Filters: OFF
- Relay Bare Multisig: OFF ✅ (confirmed by user)
- Defaults: bantime, maxconnections, buffers, timeouts, maxuploadtarget
Optimisation
- dbcache: 450 MiB
- prune: 0 GB
- txindex: ON (final decision, justified by LND)
- datacarrier: OFF
- datacarriersize: inert (datacarrier=0)
- maxmempool: 300 MB
- minrelaytxfee: default
- mempoolexpiry: 336 h
- persistmempool: ON
Interfaces / Version / Advanced
- rest OFF · rpcworkqueue 128 · ipcbind OFF
- "Always use the latest version"
- Overrides:
datacarrier=0,permitbaremultisig=0
🎯 Benefits of This Configuration
| Benefit | Detail |
|---|---|
| 🎯 Rejection of inscriptions/NFTs | Does not propagate arbitrary OP_RETURN or bare multisig data |
| 💾 SSD longevity | No unnecessary indexes, no pruning cycles |
| ⚡ Stability | Conservative cache for 8 GB shared RAM |
| 🔒 Privacy | Tor active, no unnecessary I2P |
| ⚡ Lightning-ready | txindex ON for future LND use |
| 🧹 Efficient resources | No BIP37/BIP157 filters consuming writes |
📝 Note on LND Compatibility
Upon confirming that the user would open Lightning channels with LND:
txindex ON✔ satisfies LND's requirementpermitbaremultisig=0anddatacarrier=0DO NOT affect Lightning: channels are opened with standard P2WSH outputs (multisig within the witness), not with bare multisig or OP_RETURN. Your funding transactions and channel closures will relay normally.minrelaytxfeeat default ✔: advisable so that your own channel transactions (sometimes low-fee during quiet periods) propagate without friction.
Closing
Individual sovereignty is the living foundation upon which all possible liberty is built. Financial peace, the ability to participate without guardianship, to create without asking permission… all of this is cultivated in the everyday, in small decisions, in the architecture of our own lives.
A well-anchored node holds its structure firmly and remains operational even when the environment exerts pressure. Adjust yours. Now.
This article is an invitation to informed, serene action. The finest response to forced centralisation is conscious decentralisation.
⚠️ Disclaimer: The adjustments and procedures shared in this article are based on testing carried out in my own environment. As every setup is unique, I accept no responsibility for configurations, misconfigurations, or circumstances that may arise in the reader's own environment, or in that of anyone who applies these recommendations. Back up your data and verify each step before making changes.
🌐 This piece is shared via the Nostr protocol 🔗. For the best reading experience, please use a client that supports Long-form Content (NIP-23).
💛 If you wish to support this work and the cause, you are welcome to visit the “Donations” section on my personal website 🔗
Thank you for your time, your attention, and your support. 🕊️