I recently went down a rabbit hole that every serious Bitcoiner eventually stumbles into:

“What exactly is my node doing, and do I actually agree with it?”

If you’re running Bitcoin Core out-of-the-box, the answer is:
you’re participating in a broadly permissive relay policy that accepts a lot of modern transaction activity — including things that, frankly, I have zero interest in supporting.

I’m talking about:

• inscription-style data stuffing
• token protocols riding on Bitcoin
• arbitrarily large witness payloads
• and generally anything that treats Bitcoin like a cheap data warehouse instead of a monetary network

That’s not what I’m here for.

So I decided to take control.

Step 1: Switch to Bitcoin Knots

Bitcoin Knots is where things get interesting.

It’s still Bitcoin. Still consensus-compatible. Still validating the same chain.

But it exposes policy knobs — the ability to decide what your node:

• accepts
• relays
• stores
• and even includes in block templates

In other words:

Knots lets you stop being a passive participant and start being opinionated.

Step 2: Define a Policy — What Do I Actually Want?

My goals were simple:

• Allow standard monetary transactions
• Allow small OP_RETURN usage (reasonable financial metadata)
• Reject:
  • token nonsense
  • inscription spam
  • arbitrary data stuffing
• Avoid building bloated, oversized blocks
• Prefer a ~1 MB block footprint, not maxing out 4 MB weight every time

So I started tightening the screws.

Step 3: Initial Strict Filtering (Too Strict)

I began with:

rejectparasites=1
rejecttokens=1
acceptnonstdtxn=0
acceptnonstddatacarrier=0
maxscriptsize=1650
datacarrier=1
datacarriersize=83

What happened?

• My mempool collapsed to a few hundred transactions
• My block template was only ~17% full by weight

That was a wake-up call.

I had gone too far.

Step 4: Measure, Don’t Guess

Instead of guessing, I started measuring:

bitcoin-cli-knots getmempoolinfo
bitcoin-cli-knots getblocktemplate '{"rules":["segwit"]}'

This is critical.

Not:

“How many transactions do I see?”

But:

“How much weight can I actually build into a block?”

Step 5: Loosen the Right Constraint

I removed:

#maxscriptsize=1650

Result:

• Mempool jumped to ~3,000+ transactions
• Block template barely changed

So that wasn’t the bottleneck.

Step 6: Discover the Real Limiter — Block Template Size

Then I noticed something subtle but important:

currentblocksize ≈ 300 KB

That’s nowhere near a modern block.

So I tested template overrides:

bitcoin-cli-knots getblocktemplate '{"rules":["segwit"],"blockmaxsize":1000000}'

Boom.

Block weight jumped significantly.

That’s when it clicked:

My node wasn’t constrained by mempool — it was constrained by template construction limits.

Step 7: Set an Intentional Block Size Policy

I added:

blockmaxsize=1000000
blockmaxweight=4000000

This is where philosophy meets engineering.

I am explicitly choosing:

• Not to build max-weight 4 MB witness-heavy blocks
• To build ~1 MB serialized blocks
• To prioritize signal over noise

Step 8: Final Result — A Clean, Full Block Template

After restart and letting the mempool settle:

bitcoin-cli-knots getmininginfo

Result:

{
  "currentblocksize": 999984,
  "currentblockweight": 2433064,
  "currentblocktx": 1931
}

This is exactly what I wanted.

Let’s break that down:

• ~1 MB block size ✔
• ~2.4M weight (~60% of max) ✔
• ~1900 transactions ✔
• no garbage-heavy mega-transactions dominating space ✔

This is a healthy block.

What This Means

This block is:

• not empty
• not bloated
• not dominated by junk
• not artificially constrained

It is:

A clean, efficient, monetary-focused block template.

The Reality Check

Let’s be clear:

• I am not changing Bitcoin consensus
• I am not forcing the network to follow me
• I am not “fixing Bitcoin”

What I am doing is:

Choosing how my node participates in the network

And that matters.

Because relay policy shapes:

• what propagates
• what miners see
• what becomes economically relevant

My Opinion (And I’ll Say It Plainly)

There is a lot of garbage being pushed through Bitcoin right now.

Not all of it is malicious.
Not all of it is useless.

But a significant portion of it is:

Bloated, inefficient, and completely unrelated to Bitcoin’s primary purpose as money.

And I’m not interested in subsidizing that with my node.

Final Configuration — The Balanced Solution

Here’s where I landed:

rejectparasites=1
rejecttokens=1
acceptnonstdtxn=0
acceptnonstddatacarrier=0

datacarrier=1
datacarriersize=83

blockmaxsize=1000000
blockmaxweight=4000000

This is the key insight:

The goal is not to blindly exclude all large transactions — it’s to exclude the worst offenders while preserving legitimate monetary use.

Because not all large transactions are “spam.”

This configuration still allows:

• Lightning channel opens and closes
• CoinJoin transactions (privacy-preserving batching)
• Exchange batch payouts
• Multisig transactions (enterprise custody, escrow, etc.)
• Complex but legitimate scripts used in real financial workflows

These can be larger in size — and that’s fine.
They serve real economic purpose.

What this setup does reject is:

• inscription-style witness stuffing
• token protocols parasitizing Bitcoin
• arbitrary data embedding schemes
• non-standard data-carrier tricks

In other words:

It filters out parasitic noise, not legitimate complexity.

What’s Next

Now comes the most important part:

Observation over time

I’m going to watch:

• multiple block templates
• mempool behavior across fee environments
• how often the template fills to ~1 MB
• whether legitimate transactions are being excluded

If needed, I’ll tweak further.

But for now:

This is a node that behaves the way I believe Bitcoin should behave.

Closing Thought

Running a Bitcoin node is not just about verification.

It’s about participation.

And for the first time:

I feel like I’m actually participating — not just passively accepting whatever the network throws at me.

And that’s the whole point.