I list my contributions to the Bitcoin Core project and detail their context and background. Of course, not all contributions are worth mentioning here.
Contributing to the Bitcoin Core project is not limited to opening pull requests which add or change code. Even more, and arguably most important, is reviewing existing pull requests. The review helps discovering issues and potential problems. Acknowledging a pull request once all issues are addressed helps finding consensus on a proposed change. Bitcoin Core contributor Jon Atack thinks that a good ratio is to review 5 to 15 pull requests for each pull request one opens.
PR #22006: tracing: first tracepoints and documentation on User-Space, Statically Defined Tracing (USDT) by @0xB10C
merged on July 26th, 2021
This PR adds documentation for User-Space, Statically Defined Tracing (USDT) as well as three tracepoints (including documentation and usage examples). We can hook into these tracepoints via a Linux kernel technology called eBPF. The data passed into these tracepoints can then be processed with, for example, bpftrace, or bcc scripts (in Python or Rust).
I add three tracepoints. Two tracepoints for inbound and outbound P2P messages and a tracepoint for the block connection function. The Bitcoin Core USDT support is documented here and tracing script examples are listed here.
A Bitcoin Core node communicates with other nodes over a peer-to-peer network.
Nodes open outbound connections to other nodes, and some nodes allow inbound
connections. The connection management happens under the hood. A user can query
the information about the current peer-to-peer connections with the
getpeerinfo RPC. It returns a JSON formatted response containing detailed
information about the connection to each peer. This JSON response is intended to
be machine-readable and does not provide a quick overview over the open
connections for developers and node operators. A script reformatting the RPC
response would be needed to produce a dashboard like overview out of the JSON
This is where PR #19643 by Jon Atack comes into play.
bitcoin-cli with a
-netinfo command. The command wraps the
getnetworkinfo and the
getpeerinfo RPCs and displays information about the
inbound and outbound connections. In its current form, the command takes a
numerical argument ranging from zero to four. With zero it only displays the
connection counts grouped by in- and outbound connections. Passing one displays
a dashboard with detailed information about the connections, and passing four
extends this information with both the IP address and the version of the
$ ./src/bitcoin-cli -testnet -netinfo 1 Bitcoin Core v0.20.99.0-bf1f913c4 testnet - 70016/Satoshi:0.20.99/ Peer connections sorted by direction and min ping <-> relay net mping ping send recv txn blk uptime id out full ipv4 13 13 13 13 0 16 12 out block ipv4 16 19 35 35 16 15 out full ipv4 16 16 13 23 2 2 17 6 out block ipv4 32 32 36 36 16 14 out full ipv4 33 34 12 28 0 17 4 out full ipv4 34 34 13 25 0 16 10 out full ipv4 34 35 13 28 0 17 1 out full ipv4 38 38 12 25 1 17 5 out full ipv4 158 233 25 8 1 16 13 out full ipv4 174 236 21 12 9 16 7 ms ms sec sec min min min ipv4 ipv6 onion total block-relay in 0 0 0 0 0 out 10 0 0 10 2 total 10 0 0 10 2
This resolves the need for writing a custom script. The change itself only
bitcoin-cli and not
bitcoind, which is neat. By running
watch bitcoin-cli -netinfo 4 a detailed dashboard is shown, which updates
itself every other second. Jon’s PR can only be used with Bitcoin Core
version v0.21.0 or higher as an extra field was added to the response to the
getpeerinfo RPC in an earlier PR. I’ve archived a branch where it’s possible
to use the
netinfo command with older
bitcoind versions. This is available
merged on 18th February 2020
There are multiple reasons a transaction can be removed from the mempool.
The two most common removal reasons are transaction confirmation and transaction replacement.
Transactions that remain in the mempool for a long time are probably not attractive to miners.
By default, these are removed after 336 hours (two weeks).
This default timeout can be overwritten with the
-mempoolexpiry=<n> command-line argument where
<n> specifies the timeout in hours.
This functionality is important as we don’t want our mempool to fill up with transactions that are unattractive to miners (either because they pay a low fee or through other quirks).
Having a test for this behavior is important to make sure that the functionally does not break.
In PR #18172 I’ve added a test for the mempool expiry behavior.
This test tests both the default and the user-definable timeout.
A first transaction called parent is added to our test nodes mempool and its entry time is recorded.
Then the time is forwarded using
This simulates the test nodes time and conveniently allows for testing time-dependent functionality without having to wait until that time passes.
A second transaction called child which spends an output from the first transaction is broadcasted to the test node after the first half of the expiry timeout.
Then the time is forwarded to five seconds before the expiry of the parent transaction.
The parent transaction should still be in our test nodes mempool.
Five seconds after the expiry timeout the parent transaction should not be in our mempool anymore.
As the child transaction depends on the removed parent transaction it becomes invalid and should be removed as well.