Making Bitcoin Core relay like Bitcoin Knots (pre-RDTS)
Bitcoin Knots pre-RDTS is finished. It is pinned to the last Knots release without RDTS, it lives in the Community Registry (for now at least), and it will probably never get another update.
If you would rather be on Bitcoin Core but keep the relay policy you had on Knots with no bare multisig, OP_RETURN capped at 80 bytes of data, nothing under 1 sat/vB then three fields in the StartOS UI get you most of the way. Some Knots filters have no equivalent in Core at all, in the UI or in bitcoin.conf.
What this does, and what it doesn’t
These are relay policy settings. They decide what your node lets into its own mempool, what it passes on to its peers, and what it would put in a block if it mined one. They do not stop anyone else mining those transactions, and a block that is full of them is exactly as valid to your node as any other block. What you change is the traffic your node carries and forwards, nothing else about the chain. That was true on Knots too.
The catch is that the policy also binds everything that broadcasts through your node like a Lightning node, an Electrum server, BTCPay, any wallet on the RPC. A transaction that your node’s policy refuses is rejected with an error and never leaves your server and you might be confused as to why. Knots users have been living with that and if you tighten Core to match, you have it.
- If a wallet or service on your server reports a transaction rejected for
datacarrier,bare-multisigormin relay fee not met, it is your policy doing its job, you’ve hit this.
What this does do is allow you to have the Knots relay policies while also running other StartOS services and being able to update them to the latest versions.
Steps
1. Open Bitcoin Core in StartOS and go to Actions → Mempool Settings.
2. Max OP_RETURN Size → 83.
83 bytes is 80 bytes of data plus the three bytes of script around it. It is the limit every Bitcoin Core before 30 enforced and the one Knots (pre-RDTS) ships with. On 30.x and 31.x the footnote under the field says the default is 100,000, which is the change Core 30 made, and this field is how you undo it.
One difference you cannot close: since Core 30 a transaction may carry several OP_RETURN outputs, and the 83 applies to their total. Knots allows exactly one. Two small OP_RETURN outputs whose scripts add up to 83 bytes or less pass a Core node; Knots refuses the second.
If you want Core to carry no OP_RETURN at all, set Relay OP_RETURN Transactions to ✗ Off. That is stricter than Knots, which relays 80-byte OP_RETURNs, and it breaks anything that uses an OP_RETURN through your node, however small. Most people want the 83, not the off switch.
3. Permit Bare Multisig → ✗ Off.
Core relays bare (non-P2SH) multisig outputs by default; Knots does not. Bare multisig is the old way of stuffing data into outputs and almost nothing legitimate uses it.
4. Min Transaction Relay Fee → 0.00001.
The field is in BTC/kvB, so 0.00001 is 1 sat/vB, which is Knots’s floor. Core dropped its own floor to 0.1 sat/vB (0.000001) in version 30, and that change is in the 28.4 and 29.4 releases as well, so every Core line Start9 ships now defaults to the lower number. With this set, nothing under 1 sat/vB gets into your node or out of it. Knots has had that floor all along, so anything that worked through a Knots node works through this.
5. Leave the rest at Default.
Bytes Per Sigop is 20 on both; Persist Mempool, Max Mempool Size and Mempool Expiration have the same defaults on both. Blocks Only is not a Knots setting: it stops your node relaying transactions altogether, and it disables fee estimation and wallet broadcast with them. Leave it alone unless relaying nothing is actually what you want.
6. Save. Bitcoin Core restarts on its own.
What Core cannot do
Most of what “spam filtering” meant on Knots is not the OP_RETURN limit – it is Knots looking inside transactions in ways Core never has. None of the following exists in Bitcoin Core 31, in the UI or in bitcoin.conf:
- Counting data hidden in witness scripts against the limit. Knots (
datacarrierfullcount, on by default) finds theOP_FALSE OP_IF … OP_ENDIFenvelopes that inscriptions live in,<data> OP_DROPstuffing, and data disguised as P2WSH outputs, and counts all of it against the same 83 bytes. Core’s limit looks at OP_RETURN outputs and nothing else. An inscription reveal — the data sits in a tapscript — passes a Core node set to 83 untouched, because Core puts no size limit on a tapscript at all below the 400,000-weight-unit cap on the whole transaction. This is the big one. - A cap on script size. Knots refuses to relay any script over 1,650 bytes, witness included (
maxscriptsize). That is the other half of what keeps large inscriptions out of a Knots mempool. - Charging data full weight. Knots counts the data it finds — OP_RETURN payloads and the witness envelopes above — at 1 vbyte per byte for fee purposes (
datacarriercost), four times what Core charges for witness bytes, so a data-heavy transaction needs four times the fee to clear the same floor. - The parasite and token filters.
rejectparasites(on by default) refuses transactions marked as CAT-21;rejecttokens(off by default) refuses Runes OP_RETURNs and the OLGA output trick. - The smaller rules. No bare pubkey outputs, no transactions whose only output is an OP_RETURN, one OP_RETURN per transaction — all on by default in Knots — plus dust thresholds that follow fee conditions and treating address reuse as a conflict, which Knots offers but ships off. Core has none of them.
- Block templates. Knots builds 300 kB blocks by default. Only relevant if you mine from this node; Core’s
blockmaxweightis abitcoin.confkey, not a form field.
If you need any of that, the only way to have it is the Bitcoin Knots (pre-RDTS) service. Going forward, this may mean running older versions of other services on StartOS to maintain compatibility, How wise that might be is a decision you’d have to make.