Update on my Mining Management System Over the past few weeks, I’ve been working on integrating my Bitaxe miners into my visualization. It wasn’t easy, but I finally got the interface running smoothly, and now I can display live data from each miner. The interface has been redesigned, the core setup is ready. Next comes the fine-tuning: more indicators, cleaner visuals, and some animations I plan to add in the coming weeks. The Project idea: When the solar panel produces excess power and the battery is full, the system automatically switches on more Bitaxe miners via relays. If production drops, it scales them back down. This way, surplus electricity can be put to work for mining and everything can be monitored visually in the interface.

My current position on the Core debate: If Bitcoin is accepted by the broader public, the mining market will become so competitive that it will mainly be viable with excess electricity or by reusing the heat from computers. These applications are distributed worldwide and are most efficient directly at the source where surplus energy or heat exists. Pools will continue to exist, but they will increasingly consist of participants located across many different regions. For Bitcoin’s decentralization it is essential that these different actors have the ability to construct their own blocks. Protocols such as Stratum V2 are important because they give individual miners the power to decide on block content rather than leaving this responsibility entirely to the pool operator, which otherwise strengthens centralization. In my view, the new Core version continues to push Bitcoin in a centralized mining direction even though we already have tools that could make mining more decentralized. With this version, it becomes harder for individuals to mine because running Core alone is no longer enough. A miner also has to worry about which filters to activate in order to avoid legal risks if a block they find were to include illegal content. This raises the barrier for small participants. Until now the OP_RETURN limit has already made it almost impossible for illegal content to slip into a block without being split across multiple transactions. Instead of leaving this safeguard as it is, the new changes create additional complexity and discourage individual miners. The result is that large pools benefit while individuals lose part of their freedom to decide how to run their node, whether they want to mine or simply participate independently in the network. I am aware that settings can still be adjusted, but it is a major pitfall if I want to use my node for mining. What I find troubling is the very assumption that a node is not by default meant to be used for mining and for securing Bitcoin’s decentralization. #mining #core

Okay, fair. One could argue that Core v30 is mainly suitable as node software and less so as mining software, since an inexperienced person might otherwise end up creating blocks that contain illegal content.

So the goal of Bitcoin isn’t to be as decentralized as possible, allowing anyone to run a node and mine? Instead, only large pools that then use their own filters for block production. As an individual person, you’re not allowed to use filters?

I assume that as a public company, they probably have to implement strict filters to ensure they’re not writing any illegal content into the blocks. So maybe yes..

I use Bitcoin Knots because I disagree with Bitcoin Core pushing changes and adjusting default settings despite significant resistance. Having multiple developer groups is crucial for decentralization, security, and diverse perspectives. Whether it’s about differing opinions or preventing unintended bugs. I’ve also come across an even stronger argument: Without proper filters or limits, attackers could push large amounts of illegal data, including pictures or even videos, through the mempool, letting it spread across the network without paying the high fees required to get it into a block. Node operators could unknowingly become legally exposed by relaying such content. Don’t change a running system. Why is it suddenly so important to remove these limits? Are the Bitcoin Core developers fully aware of these potential consequences? #knots #node #spam

Hopefully, not at all. Bitcoin is decentralized, and having a single developer group programming all the nodes is already a risk. If Bitcoin Knots helps form a second developer group, it would actually make Bitcoin much healthier. Both by encouraging diverse opinions and by increasing the network’s robustness against potential bugs.

In my view, Bitcoin is purely about transferring money. Spam will still exist, but it can be made harder to execute. In the past, when a proposed change faced significant resistance, it usually wasn’t integrated. However, in this case, it was implemented anyway. Also, Knots offers more customization options for how I want to run my node. And that’s the simple reason why I use Knots. And if at some point Knots tries to force something on me as well, I can easily switch my node again.

Okay, that actually sounds pretty good.

Hey Jack, you uploaded the same episode as last week on Spotify and Fountain😅 @jack mallers https://fountain.fm/episode/nLUlYDg3g0E8OJM1Lssm

In general, I think it’s a good idea, but it’s also risky if data about an entire nation is stored in one central place. Are there any legal requirements that prevent companies from relying solely on the E-ID for authentication? Unlike, for example, the use of the Swiss ID at SBB or the Post.