Feat/btcd nodes - #810
Conversation
fc8c6fc to
39279eb
Compare
|
Added a lint commit and rebased on main to run CI |
pinheadmz
left a comment
There was a problem hiding this comment.
This is really great work, thank you! I'm so glad you're using Warnet for the fountain codes research. The PR is coming along great, I have some feedback. The biggest blocker being the hard coded configuration values in _rpc(). I think everything else should work but could be cleaner. I also left some notes about abstracting the node implementation even further to make it easier for the next one we add ;-)
Also, the scenario and network you added are great but I'd like to see an extra test added to the CI that deploys the network, runs the two scenarios, then sends some commands to assert the expected values (like block height, wallet balance, etc). See the test/ directory for examples, and add your new test to .github/workflows/test.yml
p.s. seeing a ton of these log messages from all the btcd nodes, all with unique port numbers:
2026/06/29 17:59:46 http: TLS handshake error from 10.1.0.1:60012: EOF
| restartPolicy: Never | ||
|
|
||
| image: | ||
| repository: lucasdbr05/btcd |
There was a problem hiding this comment.
Anything special about this image? do the lightning labs / roasbeef / btcsuite repository images on docker hub work as well?
| chain: regtest | ||
|
|
||
| implementation: btcd | ||
| restartPolicy: OnFailure |
There was a problem hiding this comment.
Is this required for btcd? For lnd for example we expect it to crash and restart a few times on deployment while it waits for the bitcoin core node to come up. However, for bitcoin core itself we usually don't want this, because if bitcoin core crashes we don't want it to silently restart, we want to know why it crashed.
| "commander.py", | ||
| "test_framework", | ||
| "ln_framework", | ||
| "btcd_framework", |
There was a problem hiding this comment.
This is ok for now, obviously we do the same thing for LN. But if we keep adding dependencies to the commander it'll get bloated. No need to change anything now but it might be time to start thinking about how to filter out unneeded stuff.
| restartPolicy: OnFailure | ||
|
|
||
| # TODO: find a better approach to can mine blocks (this address is just for tests) | ||
| config: | |
There was a problem hiding this comment.
We have ensure_miner() in the bitcoin test framework. Then in the mining scenario we call that and then getnewaddress
| class BtcdRpcTest(Commander): | ||
| def set_test_params(self): | ||
| self.num_nodes = 1 | ||
| self.mining_addr = "Sh6VJ4TabWtfBm9kvLWPzj8WGNsMmtyaGF" |
There was a problem hiding this comment.
I assume these coins go nowhere? Or is the btcd wallet deterministic?
39279eb to
07e99e8
Compare
|
rebased on main to include #812 CI fix |
07e99e8 to
ba751a7
Compare
|
For testing, you can move |
Add a new Helm chart for btcd nodes, including: - Chart.yaml with chart metadata and dependencies - values.yaml with default configuration values - Configmap template for btcd node configuration - Pod template for running the btcd container - PVC template for persistent volume claims - Service template for exposing the btcd node - ServiceMonitor template for Prometheus scraping - _helpers.tpl with reusable template helpers - NOTES.txt with post-install instructions
Add example network configurations for btcd nodes, including: - 6_node_btcd: a 6-node btcd-only network topology
Extend warnet to support btcd nodes alongside Bitcoin Core
Add a lightweight JSON-RPC client for btcd nodes. It handles HTTPS communication with self-signed TLS certificates. It exposes standard Bitcoin RPC methods alongside btcd-specific extensions.
ba751a7 to
d473f09
Compare
Add btcd node support to Warnet
This PR integrates btcd as a first-class node implementation in Warnet
What's Changed
To enable btcd support, we added a new Helm chart under
resources/charts/btcdalong with a 6-node simnet example network underexamples/networks/6_node_btcd.Configuration and Helpers: updated constants.py and added btcd.py to manage implementation constants, detect pod chains/ports, and format credential flags for the
btcctlCLI.RPC and Log Routing: modified
bitcoin.pyto dynamically route RPC calls (using bitcoin-cli or btcctl accordingly) and stream logs from the correct active container.Deployment: updated
deploy.pyto spin up the appropriate Helm chart based on the node's configured implementation and collect port definitions for the fork observer.Testing