Coder Social home page Coder Social logo

0xb10c / fork-observer Goto Github PK

View Code? Open in Web Editor NEW
5.0 3.0 2.0 450 KB

WORK-IN-PROGRESS: observe forks on all Bitcoin networks (mainnet, testnet, and [custom] signets)

Home Page: https://fork.observer

License: MIT License

Rust 78.20% CSS 2.10% HTML 3.30% JavaScript 16.04% Nix 0.09% Dockerfile 0.27%
bitcoin forks reorg

fork-observer's Introduction

fork-observer

Connecting to a Bitcoin Core node

For getting a good overview over different chain fork on the Bitcoin network, fork-observer ideally needs access to multiple Bitcoin Core nodes. It was designed work with many nodes on multiple networks in parallel. Additionally, if another party is willing to give you RPC access over e.g., an encrypted channel like wireguard, you can add their node to your fork-observer instance. This requires only access to three RPC calls that can be whitelisted. Note: Don't give anyone RPC access when your node is used to handle real-world funds. Next to Bitcoin Core wallet funds this includes funds in a Lightning node connected to your Bitcoin Core node.

fork-observer uses the Bitcoin Core RPC interface to query information about headers and the chain tips. The REST interface is used to query batches of main chain (the chain leading up to the chain tip) headers. Requesting block header batches via REST is more performant than requesting them individually through RPC. While REST is optional, it's recommended to connect to at least a few nodes that have the RPC interface enabled. The REST interface can be disabled by setting use_rest = false in the per network node configuration in config.toml.

It's recommended to set up a persistent Bitcoin Core RPC user for the fork- observer. A password hash can be generated, for example, with the rpcauth.py script provided by Bitcoin Core or third-party tools like jlopp's online version. Compared to using cookie-based authentication, a dedicated user enables you to limit the allowed RPCs for this user.

fork-observer needs access to the following RPCs:

  • getchaintips: Used to query available chain tips and their status.
  • getblockhash: Used to query a block hash given a specific height.
  • getblockheader: Used to query (stale) block headers.
  • getnetworkinfo (optional): Used once during start-up query the Bitcoin Core version. This RPC could potentially expose private information about your nodes connectivity.
  • getblock (optional): Used for miner identification.

A sample Bitcoin Core configuration could contain the following:

rpcauth=forkobserver:<password generated with rpcauth.py>

rpcwhitelist=forkobserver:getchaintips,getblockheader,getblockhash,getblock
# OR if you're fine with exposing getnetworkinfo
# rpcwhitelist=forkobserver:getchaintips,getblockheader,getblockhash,getblock,getnetworkinfo

# If you want to access *your* node's RPC interface via e.g. a wireguard tunnel
# from some *other host*.
# rpcbind=<your-wireguard-IP> # e.g. rpcbind=10.10.0.3 (local)
# rpcallowip=<other-host-IP> # e.g. rpcallowip=10.10.0.2 (remote)

fork-observer's People

Contributors

0xb10c avatar willcl-ark avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

willcl-ark z1617

fork-observer's Issues

Add randomness to the query-interval timing

I might want to add some randomness to the query interval for each node in fork-observer so you don't end up firing 200 RPC calls exactly ever 60s.

from bitcoin-dev-project/warnet#175

Problem:

  • on large networks, we might query all nodes at the same time
  • this might cause CPU spikes and unnecessary locking of the in-memory block tree

Fix:

  • for each node, add a bit of randomness to the query interval based on the query interval
  • eg with a base interval of 60sec: node A queries every 54sec, node B every 66sec, node C every 61 sec
  • over time, this should smooth out the RPC requests and make sure not all are fired around the same time

Node state

fork-observer should show and alert (RSS?) on nodes that are:

Identify the mining pool, where possible

We can identify the mining pool, if the node downloaded the full block. Sometimes it might only download the header.

This probably needs the getblock RPC added to the whitelist, but this feature can be optional.

Can use https://github.com/bitcoin-data/mining-pools data for the identification.

Can also identify SigNet miners. Needs a per network configure flag for the mining pool tag data to use.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.