I took the time to write up some of my Taproot activation monitoring efforts last year and what we saw. I think it's important to document this for future Bitcoin developers and future soft-fork activations.


Ran full-IBD benchmarks for PR #20827.

Measured a ~4% IBD speed-up with -prune=550 and default dbcache and a whooping 17.4% (!!) speed-up using -prune=8800 and -dbcache=4000.

Full results:

Show thread

I solved @robot__dreams first Bitcoin-flavored cryptography challenge (gist.github.com/robot-dreams/6) with the help of @kalle Schnorr Basics explainer (popeller.io/schnorr-basics).

Here's a write-up (and spoiler).


I'm currently running IBD benchmarks for @lukedashjr 's #20827 on a dedicated benchmarking machine. I expect them to finish next week.


I've rented the machine till end of the month. Any other PRs that need IBD benchmarks?

@kalle Thanks for writing this up!

I've dm'd you a few days ago on the birdsite, but I think it doesn't show a notification for you. Would you be interested in cross-posting your Schnorr Basics post to bitcoin-dev.blog ?

@jb55 IIRC you were working on a self-hostable LN+on-chain payment processor in Rust a few months ago? I'm looking for something more lightweight than BTCPayServer for my nix-bitcoin node... It's overkill for just receiving the occasional donation. Is project an option?

0xB10C boosted

pretty easy to send everyone on the lightning network 1 satoshi:

$ lightning-cli listnodes | jq -r '.nodes[].nodeid' > nodes.txt

$ echo 'lightning-cli keysend "$1" 1sat | jq -c .' > dosend && chmod +x ./dosend

$ <nodes.txt parallel ./dosend | tee res.json

Show thread

All pools that mined ten or more blocks since taproot activation have now included at least one P2TR spend.

0xB10C boosted

RT @0xb10c
Looking at the pools that mined more than 3 blocks since taproot activation or included a P2TR spend, it's clear that F2Pool and AntPool are, very likely, NOT including P2TR spends. F2Pool already mentioned that they will upgrade their infrastructure soon.

I'm streaming the Bitcoin Taproot soft-fork activation.

Join me for sound notifications and a real-time feed of blocks and taproot transactions!

Twitter: twitter.com/i/broadcasts/1Mnxn
Twitch: twitch.tv/0xb10c
YouTube: youtube.com/watch?v=YihYNYFdXs

We have been working on making reorgs on SigNet a reality and are looking for feedback on approach and parameters. If you want to test the reorg handling of your app, please let us know!


@michaelfolkson Yes, debugging is definitely one of the USDT applications. Also developers can be use the tracepoints to evaluate/review changes like I do with the erlay vs master nodes dashboard. Or for general monitoring, anomaly detection, benchmarking, and testing.

Additionally, I think 'tracing' via USDT and debugging are two very different things. You can use tracing via USDT as part of the search for a bug, but you can't replace debugging with tracing.

Sometimes debugging, as in stepping through code and looking at state with e.g. GDB, is something you do manually.

The tracing done with USDT allows you to use internal state programatically. You can automatically react to some state.

@michaelfolkson I'm not sure if I'd see reading "BPF Performance Tools" as a requirement. The tools are very specific for tracepoints in the Linux kernel. We don't use any of these tools or tracepoints.

We just implement our own tracepoints in our userspace application (Bitcoin Core) and write custom scripts to get insights into the parts we find important.

@michaelfolkson Yes! I've been thinking about some kind of USDT workshop for CoreDev too.

A Socratic might be better once we have more tracepoints merged and people building tools/using the tracepoints? Maybe sometime between CoreDev and 23.0. release?

I've summarized my work on Userspace, Statically Defined Tracing support for Bitcoin Core in my Coinbase grant half-time report.


0xB10C boosted

[bitcoin] Merged PR from 0xB10C: tracing: first tracepoints and documentation on User-Space, Statically Defined Tracing (USDT) github.com/bitcoin/bitcoin/pul

If future tracepoints for e.g. peer dis / connections, addrman, UTXO set changes, etc get merged, this might be an alternative to
's Statoshi.info which requires a rebase on each Bitcoin Core release. I'd also argue that the bitcoind-observer setup is easier.

Show thread

And block connection timings during IBD and data about validated blocks/second, transactions/second, inputs/second, and sigops/second.


Show thread
Show older
unidentified instance

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!