satd_btc

tech

bitcoin

bitcoin_Mining

satd 0.6.0 is released, supporting direct Stratum V1/V2 connections from your mining device directly to the running node. No pools or proxies needed. Control your own block template using satd's transaction policy filtering language.

On top of that, we've cut chainstate disk usage by 50%, and we now publish appliance images to get your own satd up and running in a few minutes in a VM. Umbrel (and soon, StartOS) also supported.

Check it out: https://github.com/epochbtc/satd/releases/tag/v0.6.0

satd 0.6.0: solo mine directly to your node

bitdevs

satd 0.5.2 is released, with a large number of Bitcoin Core-compatibility fixes exposed by the new functional test harness we ported from Core (thanks to rbitcoin for inspiration). We now have 40 passing functional tests from Core against satd.

In addition to that, we now have a reference stack implemented including validated packages for Umbrel and StartOS (Start9), and VM images for quick demos. VM image with --fast-start (assumeutxo) should give you a fully synced node in an hour or so.

Download at https://github.com/epochbtc/satd/releases/tag/v0.5.2

Feedback or questions welcome!

satd 0.5.2 release: Core compatibility fixes + appliance images

satd (full Bitcoin node in Rust): Guided Code Tour

Chain split due to consensus bugs is the biggest risk for any alt implementation, in my view. So I think it pays to be conservative initially. I don't have an exact timeline but I would likely keep dual validation for quite a while. On most modern machines it has no runtime wall clock cost--the dual validation is done async and non-blocking--so there's not much downside.

If you've ever tried to integrate with Bitcoin Core (bitcoind) you know how annoying it is to either poll the legacy JSON-RPC API, or set up a ZMQ listener. Satd provides a modern, strongly typed streaming event consumption API (with gRPC and JSON websocket transports) with features like the full event firehose, narrowly-scoped watches (for wallet backends, for example), privacy-preserving prefix matching, etc.

There's also a Rust SDK (Go SDK coming next release): [https://epochbtc.github.io/satd/rust-sdk.html](https://epochbtc.github.io/satd/rust-sdk.html)

Comments or feedback welcome!

satd: Bitcoin Streaming Event Consumption API

I just released [satd](https://github.com/epochbtc/satd) 0.4.0 which has some major new features. If you aren't familiar with satd, it's a completely new, ground-up implementation of the Bitcoin node protocol in Rust with a lot of operational and ergonomic improvements. More info in the [README](https://github.com/epochbtc/satd/blob/master/README.md).

One of the headline new features in 0.4.0 is the [transaction filtering policy language](https://epochbtc.github.io/satd/policy.html). This is a maximally flexible, fixed cost language that allows node operators to express exactly which transaction types they want their node to participate in relay and block construction. Given all the controversy about BIP-110, this filtering policy allows node owners to completely control which transactions consume resources on their node, but **without affecting consensus**. I have no interest in changing what Bitcoin is, and Bitcoin is defined by consensus rules. However we can give node operators maximum sovereignty and ability to control their node behavior, as long as consensus rules are maintained.

Here's an example policy:

```
# Resource protection: cheap, oversized generic OP_RETURN
# eg, bulk data that doesn't pay its way. Small markers
# and well-paying data both pass freely.
quarantine cheap-bulk-opreturn when
    any output (out.script_type == op_return and out.op_return_size > 83)
    and tx.fee_rate < node.min_relay_fee * 3
```

There are more examples in the operator manual. You can be as strict or permissive as you want and your node will respect your wishes and decline to relay transaction types you filter. You can't prevent consensus-valid transactions from appearing in blocks (that requires consensus changes), but you **can** control what your node spends resources on.

Bitcoin Core has nothing like this. There's little indication that they will ever have interest in implementing something like this. Why should **your** node be captive to the arbitrary decisions hard-coded in C++?

Download and install satd here: [https://github.com/epochbtc/satd/releases/tag/v0.4.0](https://github.com/epochbtc/satd/releases/tag/v0.4.0)

satd 0.4.0 released - Bitcoin node software with transaction filtering language

Quick update on my Canaan Avalon 3s miner after 15 months of use

siggy47

Mine died a few weeks after setting it up, unfortunately. I don't know if it was the power supply or the unit but it's totally bricked.

satd: a Bitcoin full node in Rust with batteries included

Thank you! If you try it out, let me know if you run into any issues.

Yes, it can use existing block flat files downloaded by core. Use the --reindex config option on startup to avoid redownload (it will still have to rebuild the RocksDB chainstate from the blocks, so it can take a while).

Thanks! If you are able, please try it out and file any bug reports you come across.

It should run in constrained environments like Rasp Pi, etc, but I haven't actually tested that yet. On my current machine right now, mainnet is using ~4GB RAM, signet 1.6GB, testnet4 0.6GB.

Yes, there is fee rate estimation that you can see in the TUI and also via the API surfaces like Esplora.

@satd_btc's bio

I posted an introduction to satd: https://stacker.news/items/1506524

happy to hear any feedback!

Hey stackers. I'm Ben. I've spent the last year building `satd`
([https://github.com/epochbtc/satd](https://github.com/epochbtc/satd)), a Bitcoin Core-compatible full node in Rust,
aimed at self-custodians and people running nodes at home. v0.3.0 just shipped.

The problem I kept running into: if you want a node your wallets can actually
talk to, you end up babysitting a stack of processes. `bitcoind`, then `electrs`
or `Fulcrum`, then `esplora`, then `nginx` for TLS, then Prometheus, then some
ZMQ glue to tie it together. satd folds all of that into one daemon. One
process, one RocksDB, one systemd unit.

What's in the box:

**Wallets connect with no sidecars.** The Electrum protocol (1.4), an
Esplora-style REST API, and BIP 157/158 filters are all built in, with TLS, so
Sparrow, Nunchuk, BlueWallet, and Zeus just connect. The indexes live in the
same RocksDB as the chainstate and get written in the same batch as each block,
so they can't fall behind or race the tip the way a separate indexer can.

**You can change relay policy without restarting.** satd exposes the same
mempool/relay flags Core does (`-datacarrier`, `-datacarriersize`,
`-permitbaremultisig`, `-dustrelayfee`, ancestor and descendant limits). The
real difference from Core is that you edit `bitcoin.conf`, run `systemctl reload
satd` (SIGHUP), and the new policy takes effect live, no restart, without
dropping your peers. A programmable policy engine (filter by script type
or fee logic without waiting on a release) is on the roadmap
([https://github.com/epochbtc/satd/blob/master/ROADMAP.md](https://github.com/epochbtc/satd/blob/master/ROADMAP.md)).

**The status quo is the default.** The BIP policy is written down in the
MANIFESTO: satd won't unilaterally activate a consensus change, and if an
upgrade is contentious it stays on the existing rules. Your node, your veto.

**Why a second implementation, and how it avoids forking you off.** This is
really the reason I started satd. Almost the whole network runs on one C++
codebase, which means a single bug in Core is a bug for nearly everyone at the
same time. The Core maintainer group is a single point of failure. More than one serious implementation makes the network more resilient. That's the longer argument in the MANIFESTO
([https://github.com/epochbtc/satd/blob/master/MANIFESTO.md](https://github.com/epochbtc/satd/blob/master/MANIFESTO.md)). The risk is that a
second implementation is also exactly how you accidentally split consensus, so
satd is built specifically not to. It runs two script engines at once, an
independent Rust verifier and Core's actual C++ `libbitcoinconsensus`, and
checks them against each other at runtime. Zero divergence so far on every
script from genesis to the tip on mainnet, testnet4, and signet. Block
acceptance gets held to Core too, with fixtures ported from Core's own test
suite plus a fuzzer that throws adversarial blocks at both satd and a live
bitcoind and flags any disagreement. That said, obviously it's young software not
yet proven over many years. I use satd as my primary bitcoin node and backend for
wallets, but treat it as beta software.

**You can see what it's doing.** There's a built-in TUI (`sat-tui`) with an IBD
bitmap, a peer table, and a mempool view, plus a Prometheus `/metrics` endpoint
and a persistent reorg log you can point a webhook at. There's an optional MCP server if you want
to connect your node to AI tooling for block exploration or transaction automation.

GitHub: [https://github.com/epochbtc/satd](https://github.com/epochbtc/satd)
Core differences: [https://github.com/epochbtc/satd/blob/master/CORE\_DIFFERENCES.md](https://github.com/epochbtc/satd/blob/master/CORE_DIFFERENCES.md)
Operator manual: [https://epochbtc.github.io/satd/](https://epochbtc.github.io/satd/)

Happy to answer anything, especially on the consensus testing or how the
indexing works.

satd developer and bitcoin enthusiast
https://github.com/epochbtc/satd