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.

PR #19643: Add -netinfo peer connections dashboard by Jon Atack

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 response.

This is where PR #19643 by Jon Atack comes into play. It extends 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 connected peer.

$ ./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 affects 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 here.

PR #18172: test: Transaction expiry from mempool by @0xB10C

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 setmocktime(). 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.