How to Shield Your Node in Times of Pressure

By Omar-VgWs

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 requirement
• permitbaremultisig=0 and datacarrier=0 DO 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.
• minrelaytxfee at 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.