0xb10c / miningpool-observer

Transparency for Mining Pool Transaction Selection

miningpool-observer

Transparency for Mining Pool Transaction Selection

The miningpool-observer project compares block templates produced by a Bitcoin Core node to blocks produced by mining pools to provide insights about:

• Shared, missing, and extra transactions per template and block pair
• Transactions missing from multiple blocks they should have been included in
• Template and block transactions conflicting with each other
• Blocks not including transactions to or from OFAC sanctioned addresses

This project is inspired by BitMex Research: Bitcoin Miner Transaction Fee Gathering Capability and motivated by 9f6f1a8e55623aa320f430f9e3c6dc762c147035e713b96d72c20a58cf45fbbf.

Self-Hosting

The miningpool-observer project is built with self-hosting in mind. Both private and public instances, like e.g. miningpool.observer, are supported. Requirements are a Bitcoin Core node v22.0 and a PostgreSQL database.

See docs/self-hosting.md for more information.

Development

This repository is organized as follows:

├── artwork                         # Inkscape sources for the icons and images
├── contrib                         # e.g. Dockerfiles
├── daemon                          # Rust crate for the miningpool-observer-daemon
├── daemon-config.toml.example      # Example configuration file for the miningpool-observer-daemon
├── docs                            # Documentation
├── migrations                      # SQL files automatically ran by the miningpool-observer-daemon on startup
├── shared                          # Rust crate for code shared between the miningpool-observer-daemon and miningpool-observer-web
├── web                             # Rust crate for the miningpool-observer-web (web-server)
├── web-config.toml.example         # Example configuration file for the miningppool-observer-web
└── www                             # Static resources and HTML page templates used by the miningpool-observer-web web-server

See docs/development.md for more information.

License

This work is licensed under the MIT License.

See LICENSE for more information.

miningpool-observer's Issues

block feerate graph not shown on blocks containing zero fee transactions

Only the template graph is show as it does not contain zero-fee transactions. The log-scale on the y-Axis doesn't like the zero values and the SVG path breaks.

Error: <path> attribute d: Expected number, "….98823529411766,NaNL162.16321691…".

Test sanctioned transaction detection in blocks vs templates

Detecting censorship is one of the main purposes of miningpool-observer. The code detecting a sanctioned transaction not making it into a block is however currently not covered by unit tests. It should probably be covered by unit tests better sooner than later.

add: tag for extra transactions that would have been a good fit for the block; but we didn't know about

add: detect manual mining pool prioritizations

Pools, like for example ViaBTC, are known to manually prioritize transactions based on out-of-band payments.

For example https://miningpool.observer/template-and-block/00000000000000000005bc18c9903efcd39f6a972fb1df4eb843617f6af71b90

This can be detected and annotated with, e.g. block tags.

Observe full RBF

It would be useful to observe which pools (don't) include fee bumped transactions that are compatible with the new -mempoolfullrbf setting. I suppose this detection would be more useful on top of a node with this setting enabled, because otherwise you can't see how long such a fee bump has been in the mempool.

If we can sort the list by amount-bumped we can also see if @petertodd's bounty program is working.

bug: robots.txt returns 404

Requesting https://miningpool.observer/robots.txt should respond with a robots.txt file. Currently, 404 Not Found is returned.

document retag-transactions feature

• run only once after new tags have been added, probably mentioned in a release note
• requires txindex, non-pruned
• might take a while
• uses current sanctioned address list, but only updates TO SANCTIONED and not FROM SANCTIONED
• ...

doc: link to docker images

The documentation mentions the docker images, but doesn't link to them.

add: xchain.io blockexplorer for missing CounterParty transactions

Should be a default explorer for missing transactions. Enables checking if a missing transaction is a CounterParty transaction.

Can't see list of transactions from block

I can't see the missing or extra transaction of this one.

https://miningpool.observer/template-and-block/00000000000000000000b6387788d6bc5f3f3662739f6fc9977ad0a54d084d7e

What might've happened here?

add: try rebroadcasting Missing Transactions to the network and record result

Many Missing Transactions can be explained by e.g. conflicts with other transactions. Other times, the transaction might genuinely not be known to the network.

Transactions not included in 10 or more blocks could be rebroadcast with the sendrawtransaction RPC. The result, either success or error (e.g. this transaction conflicts), could be recorded and displayed on the Missing Transactions page.

UTXO set scan for sanctioned UTXOs times out - list to large

The scan for sanctioned UTXOs has been timing out with the error. JSON-RPC error: transport error: Didn't receive response data in time, timed out. The list grew to large at some point.

The timeout should be increased.

Build warnings

cargo 1.63.0 on Ubuntu 22.04.1 on master @ 39c4803

cargo build --release --bin miningpool-observer-daemon

...

   Compiling miningpool_observer_shared v0.1.0 (/home/miningobs/miningpool-observer/shared)
warning: derive helper attribute is used before it is introduced
  --> shared/src/model.rs:16:3
   |
16 | #[primary_key(hash)]
   |   ^^^^^^^^^^^
17 | #[derive(Queryable, Serialize, Identifiable)]
   |                                ------------ the attribute is introduced here
   |
   = note: `#[warn(legacy_derive_helpers)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #79202 <https://github.com/rust-lang/rust/issues/79202>

   Compiling migrations_macros v1.4.2
   Compiling diesel_migrations v1.4.0
warning: `miningpool_observer_shared` (lib) generated 1 warning
warning: unused import: `std::convert::TryFrom`
 --> daemon/src/main.rs:2:5
  |
2 | use std::convert::TryFrom;
  |     ^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unused imports: `PackedLockTime`, `Sequence`, `Witness`
  --> daemon/src/processing.rs:20:74
   |
20 | use bitcoin::{network::constants::Network, Address, Amount, Transaction, Sequence, PackedLockTime, Witness};
   |                                                                          ^^^^^^^^  ^^^^^^^^^^^^^^  ^^^^^^^

warning: unused `Result` that must be used
   --> daemon/src/main.rs:905:21
    |
905 |                     db::update_transaction_tags(&new_tags, &tx_in_db.txid.clone(), &conn);
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(unused_must_use)]` on by default
    = note: this `Result` may be an `Err` variant, which should be handled

warning: `miningpool-observer-daemon` (bin "miningpool-observer-daemon") generated 3 warnings
    Finished release [optimized] target(s) in 1m 03s

[Feature Request] Include block that missing transaction was included in

On https://miningpool.observer/missing, list the block and mining pool that the transaction was finally included in.

Show sigops for template

This should be a matter of summing the sigops field for each transaction in the template.

Clippy has some suggestions on how to improve the code

cargo clippy

add: Dark Mode

https://twitter.com/benthecarman/status/1390354253789683716

bug: transaction position for missing transactions uses the number of transactions in the block

add: detection of conflicting BIP-125 replaced and replacement transactions

Note: Usually, many of the conflicting transactions listed below are not properly propagated BIP-125 (Opt-in Full Replace-by-Fee Signaling) replacement transactions.

This can be detected and the information about the RBF event can be displayed. Additionally, users should be able to filter the conflicting transaction page to hide these RBF conflicts. The non-RBF conflicts are of higher interest.

Example

https://miningpool.observer/conflicting/0000000000000000000d1f2794b964c83b86586e83898aa0a9a7e5e66daa186a

The template transaction 49090b.. and the block transaction 12e154.. conflict. Both signal for RBF replaceability. 49090b.. pays a higher fee and thus a higher feerate than 12e154... The template transaction 49090b.. is very likely an RBF replacement for the replaced block transaction 12e154...

The template transaction 49090b... might not have propagated to the mining pool in time. The pool did issue work to mine on 12e154...

add: tag for seldom used output and input types to missing transactions

e.g.

• P2MS
• P2PK

reload Bitcoin Core cookie if RPC auth fails

Currently, if cookie-authentication is used for RPC and Bitcoin Core is restarted, the old cookie fails to authorize (reported in #48). If this happens, it might be worth trying to reload the cookie file once to see if that helps. I'm not sure if that's doable within the current rust-bitcoincore-rpc setup, but it can't hurt to try.

RPC users and password auth is not affected and should work across restarts.

Missing entry for blockheight 784211

The following block is missing entirely from miningpool.observer:
Blockheight 784211
Blockhash 00000000000000000001c20c14a52b5ae7c6ca385c58943c82ce8b0a76893b68

The url returns msg Record not found:
https://miningpool.observer/template-and-block/00000000000000000001c20c14a52b5ae7c6ca385c58943c82ce8b0a76893b68

The block was mined just a few seconds after the prev block 784210. Is it possible that 784211 was mined before miningpool.observer's Bitcoin node knew about the prev block, and therefore it didn't have a new template?

If my assumption is correct, is this expected behavior? I would humbly suggest that it might be better to display some data about the block, with a disclaimer that it didn't have time to create a template to compare against. Thanks!

add: Bitcoin Core version used to create block templates

One thing I couldn't find on the pages was the software version you used to generate the templates, since that can also be a source of differences. (E.g., imagine taproot activates; Bitcoin Core 0.21.0 won't mine taproot transactions; 0.21.1 will. Although not related to your primary goal of detecting censorship, comparing different version's templates against blocks may tell you what software miners are running.)

via https://x0f.org/web/statuses/106189627623104063

auto-update list of sanctioned transactions from GitHub

Currently, the list of sanctioned transactions is baked into the binary during compilation. While this is nice for performance, it also means that I need to pull the list from GitHub, commit it to the repo, do a minor release, notify users, and users need to recompile and redeploy every time the list changes. This works when I'm the only one running miningpool-observer, but doesn't really scale.

An auto-update list feature could help here. One option could be to just download the list from time to time in the daemon. However, web needs the list too (to show e.g. https://miningpool.observer/faq#sanctioned-tx-addresses).

Loading the list from GitHub (or any other configurable URL), and then saving it to the database should work. Both, web and daemon can load and reload it when they need it.

As GETing things from URLs requires new dependencies, an alternative solution could be to have something that does this externally, e.g. a cron script. This comes with extra setup-work for users and might not be worth it.

setup: create docker compose file

Missing Transactions section takes too much time to load

I've been serching for txId a832c2fe8c8bda177eb26dbd032879e208074780bb485dbe96104922d8c5f5f6 (as it has been missing from templates 96 times in my mempoolexplorer.com node) in your web, and I've realized that it takes a lot of time to load the missing transactions section.

Not sure why, other times I've visited the page, it has been much faster.

https://miningpool.observer/missing

When blocks arrive in rapid succession, the first block (which we have templates for) isn't processed.

AJ noted this on twitter for the blocks 684266 and 684267.

Hmm, https://miningpool.observer/template-and-block/ is missing blocks at height 684266 and 684267 (267 was only 3s after 266, so fair enough, but not seeing why 266 would be missing).

The daemon skipped the block 267 as it couldn't request a template before the block was found. The daemon had templates for the the block 266, but currently does not process it. This should be improved.

Logs

INFO  [stats] New Template based on 684265 | 620 tx | coinbase 7.36356666 BTC
INFO  [stats] New Template based on 684265 | 627 tx | coinbase 7.36383182 BTC
INFO  [stats] New Template based on 684267 | 777 tx | coinbase 7.26011534 BTC
WARN  [processing] Can't compare the previous_template to the new block. Was there a reorg or multiple blocks found in rapid succession?
INFO  [stats] New Template based on 684267 | 777 tx | coinbase 7.26011534 BTC
INFO  [stats] New Template based on 684267 | 775 tx | coinbase 7.26158040 BTC
INFO  [stats] New Template based on 684267 | 765 tx | coinbase 7.26284898 BTC
INFO  [stats] New Template based on 684267 | 749 tx | coinbase 7.26845930 BTC

(I've replaced the block header hashes with block heights here)

Over the last 7 days, we saw 10 "Blocks skipped"-events, that means at-least 20 unprocessed blocks, 10 of which we could have processed.

Steps:

• refactor: split the processing_loop() function into a loop+check and a processing function. The processing function takes the templates and block as arguments. This enables us to process the block we have templates for even if it's not the newest.
• for new templates, log the height as well (easier to reason about than the block hash only)
• get block we have templates for and pass it into the new processing function
• improve the wording in this comment

add: RSS feed for missing transactions

useful for alerts and similar