This is a copy of the 1st work-log I sent to OpenSats for my LTS grant.

How did you spend your time?

Publications

• ViaBTC’s mutated blocks without witness data: Last year, errors like ERROR: AcceptBlock: bad-witness-nonce-size in the Bitcoin Core debug.log caused confusion. As these were coming up again, I took a look into why they’re happening. Turns out this is a problem with ViaBTC’s pool implementation and nothing to be done on the Bitcoin Core side.
• Vulnerability Disclosure: Wasting ViaBTC’s 60 EH/s hashrate by sending a P2P message: While looking at the code of the ViaBTC pool server to learn more about the mutated blocks, I noticed a security vulnerability and responsibly disclosed it.
• Update on LinkingLion: Reduced activity and a statement by LionLink Networks: LionLink, the ISP where the LinkingLion connections originate from, issued a statement and subsequently the connections from LinkingLion dropped for a couple of hours before starting again. LinkingLion is still active and possibly linking IP addresses to Bitcoin transaction broadcasts.
• Invalid F2Pool blocks 783426 and 784121 (April 2023): F2Pool mined two invalid blocks in early April 2023. I still had notes from looking into these and decided to publish them.
• Following mononauts post about major mining pools sharing a custodian and directly mining to that custodian, I looked into the stratum jobs they send and found that the BTC.com pool, Binance pool, Poolin, EMCD, Rawpool, and possibly Braiins have exactly the same template and custom transaction prioritization as AntPool.
  • https://twitter.com/0xB10C/status/1780611768081121700
  • https://twitter.com/0xB10C/status/1783126815822717080
• During the halving, I ran a Bitcoin Halving Monitoring Stream with the goal to keep track of possible selfish mining and reorgs due to the anticipated high reward of mining block 840000. While there weren’t any reorgs, there was a possible reorg attempt.

Projects

peer-observer & infrastructure

To monitor for Bitcoin P2P anomalies and attacks, I now run 12 Bitcoin Core “honeynodes” (honeypot nodes) on four continents across three different hosting providers. All nodes have additional monitoring attached that is used to record data and metrics. As leaking the node IP addresses would defeat the purpose of the honeypot, the public interface https://public.peer.observer/ is redacted. I’ve been providing access to interested and trusted developers and community members on an ad-hoc basis.

I’ll be mentoring someone as part of my Summer of Bitcoin project “peer-observer: Anomaly detection and alerting for Bitcoin Core P2P events”. The goal is to extend peer-observer with proper alerting and to experiment a bit with proper anomaly detection.

The infrastructure work for peer-observer includes (but not limited to):

• Setting up four low powered ARM nodes in a new datacenter.
• Decommissioning of two nodes used during early development in 2022 and 2023
• Enabling detailed debug logging on the nodes and daily log rotation of debug.log files
• Automated FTP backup of old debug.log files for future use
• Use client certificate authentication instead of basic auth
• Update nodes to Bitcoin Core 27.0rc1 release candidate as well as 26.1 and 25.2 release candidates
• Rework Grafana dashboards and add a dashboard playlist for TV mode

fork-observer

After noticing and reporting an issue with a stuck btcd node connected to my fork-observer instance, I added an RSS feed for lagging nodes (to be able to easily alert on stuck nodes) and added an RSS feed for offline nodes. Also, exposed and started showing node implementation along with some general refactoring. For the halving stream, I added a fullscreen mode.

Bitcoin Core

• I tested hebasto’s proposed Bitcoin Core build system change from CMake to autotools on NixOS: https://github.com/hebasto/bitcoin/issues/121
• I opened PR #29636, #29877, #29549, have been keeping #26593 and #25832 up-to-date and 28998 was merged.
• I’ve also been experimenting with a possible continuous benchmarking solution for the Bitcoin Core CI. See 27284.
• I attended the CoreDev meeting in Berlin in early April and presented my peer-observer work. I also offered to help other developers with data/stats/insights for their proposals or PRs. This resulted in five developers reaching out during and after the event requesting data (mempool data, network-adjusted time data for 29623, benchmarking #29491, non-standard tx stats for the great consensus cleanup, orphan transaction stats and tooling, …).
• GUIX builds and hash mismatch tooling: After submitting my reproducible GUIX build signatures for Bitcoin Core 25.2rc2, 27.0rc1, and 27.0 a binary hash-mismatch was noticed. This could be tracked down to me switching to a new build setup. As we don’t have any alerting for hash-mismatches, I PR’d a CI job that comments a summary of the hashes on each PR. The goal is to learn about future mismatches as early as possible to be able to investigate them.

misc

• I’ve been keeping my collection of Nix modules and packages for software I’ve written up-to-date. I use this for my own setups. However, till I get around to adding tests and further service hardening, I don’t recommend anyone else using it.
• I need a quick and dirty transaction dependency visualization and build tx-family-tree. A live version can be found here: https://0xb10c.github.io/tx-family-tree/ (this loads quite slow and isn’t really meant to be used)
• I’ve started a dataset of non-standard transactions I’ll sporadically update. Generated with https://github.com/0xB10C/find-non-standard-tx.

Plans for Next Quarter?

• continue to work on the projects mentioned above
• build out a stratum job monitoring tool to provide everyone access to the pool’s job information (inspired by https://twitter.com/0xB10C/status/1780611768081121700)
• Start to work with my Summer of Bitcoin mentee on peer-observer alerts and anomaly detection