⚠ BITCOIN CORE v30.0, PLEASE READ ⚠
HOW TO INSTALL?
1. Stop Bitcoin.
3. Download "bitcoind.s9pk" from the bitcoin-core-startos Github release page. https://github.com/Start9Labs/bitcoin-core-startos/releases/tag/v30.0
4. In StartOS, navigate to System -> Sideload a Service
5. Upload bitcoind.s9pk
WHY DOWNLOAD INSTEAD OF MARKETPLACE?
Knots and Core share the same ID. This allows dependent services, such as lightning, to use either one. It also allows people to switch between them without needing to resync the blockchain.
Due to a bug in StartOS 0.3.5.1, if either service goes up in version, it will show as an "update" for the other service. This sucks and has caused people to think StartOS is trying to trick them into switching. To minimize confusion and mistakes, we release new versions of Knots and Core in parallel and require explicit action for switching. Not ideal, but a decent stop gap until StartOS 0.4.0.
Because there is no Knots v30.0, listing Core 30.0 on the marketplace would result in Knots users forever seeing Core v30.0 as a "update". As such, we are making Core v30.0 available as a download/sideload instead of listing it on the marketplace.
Login to reply
Replies (26)
Do not update to core v 30
It is malware
Thank you for this.
Don't make the option please.

Installed v30 its and working great
Does start9 ever plan to add support for Home Assistant? I believe I heard recently that Umbrel has an app for it.
Umbrel does, would be nice to see it on StartOS too.
Consider making Knots default Bitcoin client and core as optional.
Do you realize that Increasing the data carrier limit on your local node doesn't disrupt network consensus. Why would I abandon core and run knots? when the change is local and doesn't impact the global network? Filtering out transactions you consider spam, doesn't stop them from being confirmed and propagated.
How much propaganda have you been eating from oceans team?
Let’s wait until the first CSAM content is stored in the blockchain and depending on your legislative location you have to explain why your node contains CSAM. Look for BSV, same happened there.
Because your local relay policy doesn't influence how I can use Bitcoin. If it did you could attack Bitcoin simply by spinning up a bunch of nodes.
Bitcoin is permissionless money, people will use it in ways you don't like and you cant do anything to stop it. That's a feature not a bug.
I don’t care how you or others use Bitcoin, that’s the responsibility of everyone. I don’t want to store illegal content on my own node, that blows up the nodes storage. This will make running a node more expensive over time and can lead to higher centralisation.
I already don’t peer with any knot nodes because knots nodes are unreliable to peer with
Plus why would I want to peer with a node that does not relay my BIP47 or tx0 transaction so my local node just routes around your knot brainwashed propoganda campaign
That’s exactly the point of running your own node, you decide your relay and validation policies, and I decide mine. If my node doesn’t relay your BIP47 or tx0 transactions, it’s because I’ve chosen tighter policies to reduce unnecessary data and long-term storage risk. You can route around it, that’s how Bitcoin’s peer network is designed to work.
Knots isn’t “propaganda.” It’s Bitcoin Core with additional configurability and better defaults for people who take node sovereignty seriously. Both Core and Knots enforce the same consensus rules, neither breaks Bitcoin, and both coexist perfectly fine on the network.
If you prefer to relay every kind of transaction, go ahead. Others choose to run leaner, more conservative nodes to avoid bloat and potential legal or operational risks. That’s not brainwashing, that’s responsible node operation and informed choice.
If knots is a bitcoin core with additional configuration and better results then why not share those settings and I’ll plug them in on my existing node.
Why one must insist on running Luke’s version where there is thousands of lines of code that only one guy approves and pushes to master .
Plus knots nodes are obsolete and not a solution to fight “spam”
- proof sub 1sat summer txn being confirmed and propagated even when they are being filtered.
Ocean template was used by peak mining and mined 2 blocks 92033/34 in the row. it filtered “spam” txn they didn’t like but block 92035 foundry mined them two blocks later
So what has been solved?
Nothing and knots preachers don’t have a solution just gaslighting and misleading people
Regardless of what you may want, you're primary use case is to run a bitcoin node. So users running your software for this use case that are running bitcoin core will not know that they are not running the latest version. Do you have any plan to remedy this situation? I hope it's not to have us just continue waiting for 0.4.0 since we've already been waiting two years since the last update. nostr:nprofile1qqsqfjg4mth7uwp307nng3z2em3ep2pxnljczzezg8j7dhf58ha7ejgpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcprfmhxue69uhhxetwv35hgtnwdaekvmrpwfjjucm0d5hszxthwden5te0wpex2mtfw4kjuurjd9kkzmpwdejhgtcuauf96
Yes, after StartOS 0.4.0. Has networking improvements that were necessary for Home Assistant. Will be amazing.
Both will be on the main registry in 040.
Yes, as stated, this is fixed in StartOS 0.4.0. Until then, we think this is the best solution to a tough predicament.
⚠️not recommended core v30, it's a danger pro spam version released deliberately against community consensus ❗️
check nostr:npub1s33sw6y2p8kpz2t8avz5feu2n6yvfr6swykrnm2frletd7spnt5qew252p 🤙
-> money <-
Once again hard -> money <- one cannot fuck with
The OP_RETURN size remained unchanged; it was the default relay policy that changed in v30. Therefore adjusting relay policy does not constitute a structural network change because relay policy is a locally enforced preference and has no impact on network-wide behavior proof subsat summer to this day
understand that core seeks to synchronize relay policies with consensus rules to maintain node efficiency, as it recognizes that economic incentives and consensus ultimately drive network behavior
Here https://bitcoincore.org/en/2025/06/06/relay-statement/
published June 6,2025 read the blog post where everything is explained and stop listening to propaganda by Ocean team
You’re correct that Core v30 didn’t change the OP_RETURN limit itself, only the default relay policy. However, as a node operator, I’m free to enforce stricter policies locally, and I intend to.
I don’t want to relay or store larger OP_RETURN transactions because:
1. Legal risk: Hosting or relaying arbitrary on-chain data (especially CASM content) is illegal under EU law when it includes copyrighted or illicit material. As a node operator in the EU, I have a legal obligation to minimize exposure to such data.
2. Network efficiency: Larger OP_RETURN payloads bloat the UTXO set and mempool bandwidth without contributing to Bitcoin’s core purpose, financial settlement.
3. Principle of minimalism: Bitcoin’s design goal is censorship resistance for money, not a general-purpose data storage system. Keeping relay policies tight preserves the network’s scalability and neutrality.
So while Bitcoin Core’s position is about maintaining realistic relay behavior, my stance as an operator is simple: my node, my policy. I will not relay or store CASM or any non-financial payloads. Don’t care if it’s Core or Ocean propaganda, try to apply common sense.
How’s progress on 0.4.0 going?
Looking great! Alpha.13 version was released today