26.0 Release Candidate Testing Guide

Testing Guide: Bitcoin Core 26.0 Release Candidate

For feedback on this guide, please visit #2xxxx

This document outlines some of the upcoming Bitcoin Core 26.0 release changes and provides steps to help test them. This guide is meant to be the starting point for experimentation and further testing, but is in no way comprehensive! After running through the steps in this guide, you are encouraged to do your own testing.

This can be as simple as testing the same features in this guide but trying it a different way. Even better, think of features you use regularly and test that they still work as expected in the release candidate. You can also read the release notes to find something not covered in this guide. This is a great way to be involved with Bitcoin's development and helps keep Bitcoin running smoothly and bug-free! Your help in this endeavour is greatly appreciated.

Overview

Changes covered in this testing guide include:

RPC: add getprioritisedtransactions (PR)
RPC: Importmempool (PR)
V2 Transport - BIP 324 (PR)
TapMiniscript (PR)
macOS zip packaging PR
Ancestor Aware Funding (PR)
Outbound connection management (PR)

For a comprehensive list of changes in Bitcoin Core 26.0, check out the release notes.

Preparation

1. Grab Latest Release Candidate

Current Release Candidate: Bitcoin Core 26.0rc2 (release-notes)

There are two ways to grab the latest release candidate: pre-compiled binary or source code. The source code for the latest release can be grabbed from here: latest release source code

If you want to use a binary, make sure to grab the correct one for your system.

2. Compile Release Candidate

If you grabbed a binary, skip this step

Before compiling, make sure that your system has all the right dependencies installed. Since descriptor wallets are now the default, it is recommended that you compile with sqlite(--with-sqlite=yes), so make sure you have installed the sqlite3 dependency.

For more information on compiling from source, here are some guides to compile Bitcoin Core for UNIX/Linux, macOS, Windows, FreeBSD, NetBSD, and OpenBSD.

3. Setting up command line environment

First, create a temporary data directory

export DATA_DIR=/tmp/26-rc-test
mkdir $DATA_DIR

Next, specify the following paths. For source compiled, start from the root of your release candidate directory and run:

export BINARY_PATH=$(pwd)/src

For the downloaded binary, start from the root of the downloaded release candidate (cd ~/bitcoin-26.0rc2, for example) and run:

export BINARY_PATH=$(pwd)/bin

To avoid specifying the data directory (-datadir=$DATA_DIR) on each command, below are a few extra variables to set.

alias bitcoind-test="$(echo $BINARY_PATH)/bitcoind -datadir=$DATA_DIR"
alias bcli="$(echo $BINARY_PATH)/bitcoin-cli -datadir=$DATA_DIR"

The commands throughout the rest of the guide will look like:

bcli [cli args]

Start node

echo "regtest=1" >> $DATA_DIR/bitcoin.conf

 bitcoind-test

2023-11-05T13:42:54Z Bitcoin Core version v26.0rc2 (release build)
2023-11-05T13:42:54Z Using the 'x86_shani(1way,2way)' SHA256 implementation
2023-11-05T13:42:54Z Using RdSeed as an additional entropy source
2023-11-05T13:42:54Z Using RdRand as an additional entropy source
2023-11-05T13:42:54Z Default data directory /home/max/.bitcoin
2023-11-05T13:42:54Z Using data directory /tmp/26-rc-test/regtest
2023-11-05T13:42:54Z Config file: /tmp/26-rc-test/bitcoin.conf (not found, skipping)

Stop the daemon

Ctrl + C

Look at the logs and ensure you are running the correct version.

4. Reset testing environment

Between sections in this guide, it's recommended to stop your node and wipe the data directory. You can use the commands provided below.

Stop node

bcli stop

Wipe and recreate the directory

rm -r $DATA_DIR
mkdir $DATA_DIR

RPC: add getprioritisedtransactions

The RPC prioritisetransaction allows you to "prioritise" a transaction in the mempool by treating it as if it had a higher fee than it actually does. This new RPC allows you to see which transactions have been prioritised and if they are in your mempool.

Before beginning make sure you have already stopped your node and cleaned the datadir.

We can test this RPC on regtest:

echo "regtest=1" >> $DATA_DIR/bitcoin.conf
bitcoind-test -daemon

Let's create a wallet

bcli createwallet test-wallet

{
  "name": "test-wallet"
}

And generate some blocks so that we have some funds

bcli -rpcwallet=test-wallet -generate 101

Get an address

bcli -rpcwallet=test-wallet getnewaddress

bcrt1q24zllzdy3shs72hc9dq4kaegrjhe5gnhe5r4z4

Send a transaction to yourself with a 10 sat per vbyte fee

bcli -rpcwallet=test-wallet send '{"bcrt1q24zllzdy3shs72hc9dq4kaegrjhe5gnhe5r4z4": 1}' null "unset" 10

{
  "txid": "2f22473070db30ab29b16a17f31d1fedd07c018639752430c2f265641c277149",
  "complete": true
}

Let's prioritise this transaction and give it a boost of another 10 sats per vbyte

bcli prioritisetransaction <txid from tx above> 0 10

And finally call the getprioritisedtransactions RPC to see that it's prioritised, what the fee delta is and if it's in the mempool.

bcli getprioritisedtransactions

{
  "2f22473070db30ab29b16a17f31d1fedd07c018639752430c2f265641c277149": {
    "fee_delta": 10,
    "in_mempool": true
  }
}

Once the test is successful, don't forget to stop your node and clean the datadir.

RPC: Importmempool

A new RPC is available to import a mempool.dat file without having to restart the node.

Before beginning make sure you have already stopped your node and cleaned the datadir.

This change allows for import of a mempool.dat file using an RPC which previously had to be put in a specific directory when starting bitcoind. To test this, we will run two bitcoinds on regtest initially connected and then disconnect them and move a mempool over manually.

To support running two bitcoinds we will need to add a few extra variables and aliases into our shell.

mkdir ${DATA_DIR}2
alias bitcoind-test2="$(echo $BINARY_PATH)/bitcoind -datadir=${DATA_DIR}2"
alias bcli2="$(echo $BINARY_PATH)/bitcoin-cli -datadir=${DATA_DIR}2"

Configure the first bitcoind

echo "regtest=1" >> $DATA_DIR/bitcoin.conf

Configure the second bitcoind (on different ports to prevent port conflict on the host)

echo "regtest=1" >> ${DATA_DIR}2/bitcoin.conf
echo "[regtest]" >> ${DATA_DIR}2/bitcoin.conf
echo "port=12340" >> ${DATA_DIR}2/bitcoin.conf
echo "rpcport=10340" >> ${DATA_DIR}2/bitcoin.conf

Start both bitcoinds

bitcoind-test -daemon
bitcoind-test2 -daemon

Connect the two nodes together

bcli addnode localhost:12340 add

Check they are connected

bcli getpeerinfo

[
  {
    "id": 0,
    "addr": "localhost:12340",
    "addrbind": "127.0.0.1:63880",
    "network": "not_publicly_routable",
    ...
    "connection_type": "manual",
    "transport_protocol_type": "v1",
    "session_id": ""
  }
]

Create a wallet

bcli createwallet test-wallet

{
  "name": "test-wallet"
}

Generate some blocks

bcli -rpcwallet=test-wallet -generate 101

Check both nodes saw the blocks

bcli -getinfo
bcli2 -getinfo

Chain: regtest
Blocks: 101
Headers: 101
Verification progress: 100.0000%
...

Let's disconnect the nodes

bcli addnode localhost:12340 remove
bcli disconnectnode localhost:12340

Check they have been disconnected. Note, this can take a few seconds. Retry check until it's confirmed they are no longer connected.

bcli getpeerinfo

[
]

Get an address from the test wallet on the first bitcoind

bcli -rpcwallet=test-wallet getnewaddress

bcrt1qyxe8cgrn6cvqjgpu9vux6m8rlddxgxx5rgms08

Send a transaction on the first bitcoind, leave it as unconfirmed

bcli -rpcwallet=test-wallet send '{"<address from above command>": 1}' null "unset" 10

Check mempool on the first bitcoind, we should see one transaction

bcli getmempoolinfo

{
  "loaded": true,
  "size": 1,
  "bytes": 141,
  "usage": 1136,
  "total_fee": 0.00001410,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00001000,
  "minrelaytxfee": 0.00001000,
  "incrementalrelayfee": 0.00001000,
  "unbroadcastcount": 1,
  "fullrbf": false
}

And because the two nodes are now disconnected, the second node won't have this in it's mempool

bcli2 getmempoolinfo

{
  "loaded": true,
  "size": 0,
  "bytes": 0,
  "usage": 0,
  "total_fee": 0.00000000,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00001000,
  "minrelaytxfee": 0.00001000,
  "incrementalrelayfee": 0.00001000,
  "unbroadcastcount": 0,
  "fullrbf": false
}

Let's export the mempool from the first bitcoind

bcli savemempool

{
  "filename": "/tmp/26-rc-test/regtest/mempool.dat"
}

And import it on the second bitcoind

bcli2 importmempool /tmp/26-rc-test/regtest/mempool.dat

Now we should see that the mempool on the second node has this one transaction in it

bcli2 getmempoolinfo

{
  "loaded": true,
  "size": 1,
  "bytes": 141,
  "usage": 1136,
  "total_fee": 0.00001410,
  "maxmempool": 300000000,
  "mempoolminfee": 0.00001000,
  "minrelaytxfee": 0.00001000,
  "incrementalrelayfee": 0.00001000,
  "unbroadcastcount": 0,
  "fullrbf": false
}

For this test we need to not only cleanup the original datadir but also we need to cleanup the second one:

bcli2 stop
rm -r ${DATA_DIR}2

V2 Transport - BIP 324

V2 transport if supported by both sides of a connection encrypts peer traffic. In this guide, we will test this on signet by connecting to nodes that are known to support V2 transport but please feel free to run this on a different network.

Before beginning make sure you have already stopped your node and cleaned the datadir.

Add signet=1 and v2transport=1 in the bitcoin.conf to use the signet network for testing.

echo "signet=1" >> $DATA_DIR/bitcoin.conf
echo "v2transport=1" >> $DATA_DIR/bitcoin.conf

bitcoind-test -daemon

Connect to a signet node supporting V2. Two nodes on signet that should support V2 Transport are:

bitcoin.achow101.com:38333
175.45.182.145:38333.

bcli addnode <node ip or hostname>:38333 add true

The true at end of the previous command instructs the addnode RPC to us V2 transport.

Check that you have successfully connected using V2 Transport:

bcli getpeerinfo

[
  ...
  {
    "id": 15,
    "addr": "bitcoin.achow101.com:38333",
    ...
    "connection_type": "manual",
    "transport_protocol_type": "v2",
    "session_id": "7c081213779063150191fe0295da0dd18d95c9b4dc67809cc4ed9fb9e112ca71"
  }
]

This successfully tested manual v2 connections. To see more logging consider enabling net logging with:

bcli logging "[\"net\"]"

To view anything related to V2 Transport the logs:

cat $DATA_DIR/signet/debug.log | grep v2

Please check to see if you have also connected to an automatic v2 peer which is one that you didn't explicitly try to connect but your node would have become aware of via gossip.

Once the test is successful, don't forget to stop your node and clean the datadir.

TapMiniscript

Miniscript is now supported inside a taproot descriptor. To test, we will use a simple miniscript using fragment or_b which allows one of two keys to be used to spend.

Before beginning make sure you have already stopped your node and cleaned the datadir.

We can run this test on regtest:

echo "regtest=1" >> $DATA_DIR/bitcoin.conf

bitcoind-test -daemon

Create two wallets

bcli -named createwallet wallet_name=taproot-wallet blank=true descriptors=true
bcli createwallet legacy-wallet

To use this feature we will use a taproot + miniscript descriptor:

tr(<Taproot Internal Key>,or_b(pk(<key A>/*),s:pk(<key B>/*)))

Breaking down this descriptor we can see that it uses tr() to denote it's taproot, it has one script leaf which uses the miniscript fragment or_b which means one of two keys will be provided.

Take a look at https://bitcoin.sipa.be/miniscript/ to learn about other valid miniscript fragments and scripts.

If we use the following keys:

Internal Key: tprv8ZgxMBicQKsPerQj6m35no46amfKQdjY7AhLnmatHYXs8S4MTgeZYkWAn4edSGwwL3vkSiiGqSZQrmy5D3P5gBoqgvYP2fCUpBwbKTMTAkL
Key A: tprv8ZgxMBicQKsPd3cbrKjE5GKKJLDEidhtzSSmPVtSPyoHQGL2LZw49yt9foZsN9BeiC5VqRaESUSDV2PS9w7zAVBSK6EQH3CZW9sMKxSKDwD
Key B: tprv8iF7W37EHnVEtDr9EFeyFjQJFL6SfGby2AnZ2vQARxTQHQXy9tdzZvBBVp8a19e5vXhskczLkJ1AZjqgScqWL4FpmXVp8LLjiorcrFK63Sr

The full descriptor becomes:

tr(tprv8ZgxMBicQKsPerQj6m35no46amfKQdjY7AhLnmatHYXs8S4MTgeZYkWAn4edSGwwL3vkSiiGqSZQrmy5D3P5gBoqgvYP2fCUpBwbKTMTAkL,or_b(pk(tprv8ZgxMBicQKsPd3cbrKjE5GKKJLDEidhtzSSmPVtSPyoHQGL2LZw49yt9foZsN9BeiC5VqRaESUSDV2PS9w7zAVBSK6EQH3CZW9sMKxSKDwD/*),s:pk(tprv8iF7W37EHnVEtDr9EFeyFjQJFL6SfGby2AnZ2vQARxTQHQXy9tdzZvBBVp8a19e5vXhskczLkJ1AZjqgScqWL4FpmXVp8LLjiorcrFK63Sr/*)))

Lets work out the checksum for this descriptor:

bcli getdescriptorinfo "tr(tprv8ZgxMBicQKsPerQj6m35no46amfKQdjY7AhLnmatHYXs8S4MTgeZYkWAn4edSGwwL3vkSiiGqSZQrmy5D3P5gBoqgvYP2fCUpBwbKTMTAkL,or_b(pk(tprv8ZgxMBicQKsPd3cbrKjE5GKKJLDEidhtzSSmPVtSPyoHQGL2LZw49yt9foZsN9BeiC5VqRaESUSDV2PS9w7zAVBSK6EQH3CZW9sMKxSKDwD/*),s:pk(tprv8iF7W37EHnVEtDr9EFeyFjQJFL6SfGby2AnZ2vQARxTQHQXy9tdzZvBBVp8a19e5vXhskczLkJ1AZjqgScqWL4FpmXVp8LLjiorcrFK63Sr/*)))"

{
  "descriptor": "tr(tpubD6NzVbkrYhZ4YKSWzQhgCCiD9oBFZxvSgUJ85HdBhpLFxvK865U9jF82xCoBAn9nwNZ4uwX7ZKhZbh2iZRPa5s3UHXg3v7d1srFY44SFJVt,or_b(pk(tpubD6NzVbkrYhZ4WWePjyPpUfyRsMjAsxtoZk3Yg1vjpFbgEkanxxkeLUW1qw7Q8k1n9asHy7yC9fJtQmYhAZLFvFr2iYUa2Lv8YWgtcPahTow/*),s:pk(tpubDEw9eT9USAAumgsw7uKZf94QpMcNpbnsbUPLKSSTrEFo7tnjnHTakQo3fxhoD41o5Lq25J64D4DYjPQZMPmVa5xvNX8qP1z19uMPRaGd9Uc/*)))#a78h9fyu",
  "checksum": "sek2wh9v",
  "isrange": true,
  "issolvable": true,
  "hasprivatekeys": true
}

And import the descriptor into our wallet named taproot-wallet

bcli -rpcwallet=taproot-wallet importdescriptors '[{"desc": "tr(tprv8ZgxMBicQKsPerQj6m35no46amfKQdjY7AhLnmatHYXs8S4MTgeZYkWAn4edSGwwL3vkSiiGqSZQrmy5D3P5gBoqgvYP2fCUpBwbKTMTAkL,or_b(pk(tprv8ZgxMBicQKsPd3cbrKjE5GKKJLDEidhtzSSmPVtSPyoHQGL2LZw49yt9foZsN9BeiC5VqRaESUSDV2PS9w7zAVBSK6EQH3CZW9sMKxSKDwD/*),s:pk(tprv8iF7W37EHnVEtDr9EFeyFjQJFL6SfGby2AnZ2vQARxTQHQXy9tdzZvBBVp8a19e5vXhskczLkJ1AZjqgScqWL4FpmXVp8LLjiorcrFK63Sr/*)))#sek2wh9v","timestamp": "now","active":true,"internal": true, "next": 0}]'

Next we can give this wallet some funds by generating blocks and then try and spend back to our wallet named legacy-wallet.

Get an address:

bcli deriveaddresses "tr(tprv8ZgxMBicQKsPerQj6m35no46amfKQdjY7AhLnmatHYXs8S4MTgeZYkWAn4edSGwwL3vkSiiGqSZQrmy5D3P5gBoqgvYP2fCUpBwbKTMTAkL,or_b(pk(tprv8ZgxMBicQKsPd3cbrKjE5GKKJLDEidhtzSSmPVtSPyoHQGL2LZw49yt9foZsN9BeiC5VqRaESUSDV2PS9w7zAVBSK6EQH3CZW9sMKxSKDwD/*),s:pk(tprv8iF7W37EHnVEtDr9EFeyFjQJFL6SfGby2AnZ2vQARxTQHQXy9tdzZvBBVp8a19e5vXhskczLkJ1AZjqgScqWL4FpmXVp8LLjiorcrFK63Sr/*)))#sek2wh9v" "[0,0]"

[
  "bcrt1pysnlw6me7prca487trt305dzymxzhkknj834j320cq2krrzl4g8se36kq5"
]

Generate a block to this address:

bcli generatetoaddress 1 bcrt1pysnlw6me7prca487trt305dzymxzhkknj834j320cq2krrzl4g8se36kq5

Then generate 100 other blocks:

bcli -rpcwallet=legacy-wallet -generate 100

Now we should be able to see that our taproot wallet has a UTXO ready to be spent:

bcli -rpcwallet=taproot-wallet listunspent

[
  {
    "txid": "92d4cdf376db2a3b1315d7e9b39700b6ad43b731014b2e0fcea342d7f6e07be3",
    "vout": 0,
    "address": "bcrt1pysnlw6me7prca487trt305dzymxzhkknj834j320cq2krrzl4g8se36kq5",
    "scriptPubKey": "51202427f76b79f0478ed4fe58d717d1a226cc2bdad391e359454fc015618c5faa0f",
    "amount": 50.00000000,
    "confirmations": 101,
    "spendable": true,
    "solvable": true,
    "desc": "tr([00a8d74e]dfb6959ac8931e834c89d8acba84f96e6b1b0034f9ec618d1dffb0f30d579956,or_b(pk([b1841e27/0]02688b79e683b532b1a02ed023c3610bbefb959654bc5069b5e44875712aa0fdf2),s:pk(02ead2ef0977391544379ac093f29675fc2607e7648519d586c7d6f32b7c10985f)))#zss56xjz",
    "parent_descs": [
      "tr(tpubD6NzVbkrYhZ4YKSWzQhgCCiD9oBFZxvSgUJ85HdBhpLFxvK865U9jF82xCoBAn9nwNZ4uwX7ZKhZbh2iZRPa5s3UHXg3v7d1srFY44SFJVt,or_b(pk(tpubD6NzVbkrYhZ4WWePjyPpUfyRsMjAsxtoZk3Yg1vjpFbgEkanxxkeLUW1qw7Q8k1n9asHy7yC9fJtQmYhAZLFvFr2iYUa2Lv8YWgtcPahTow/*),s:pk(tpubDEw9eT9USAAumgsw7uKZf94QpMcNpbnsbUPLKSSTrEFo7tnjnHTakQo3fxhoD41o5Lq25J64D4DYjPQZMPmVa5xvNX8qP1z19uMPRaGd9Uc/*)))#a78h9fyu"
    ],
    "safe": true
  }
]

To spend this, lets construct a payment using that output to a new address.

First get a new address to send funds to:

bcli -rpcwallet=legacy-wallet getnewaddress

bcrt1qe47y9uckcgyssqzltj5djn4dp3kfmdm2tuxznd

Send 49.9BTC to this address

bcli -rpcwallet=taproot-wallet send '{"bcrt1qe47y9uckcgyssqzltj5djn4dp3kfmdm2tuxznd": 49.9}' null "unset" 1.1

{
  "txid": "385504b1379770e6b3b8da1e07faf81cd36cd066f84fac33f14b61367608cd2e",
  "complete": true
}

Mine a block

bcli -rpcwallet=legacy-wallet -generate 1

{
  "address": "bcrt1qygad7v49uql5kgqpp6navxxj2g2pw34w0g6n0d",
  "blocks": [
    "15bf3c15480ed033c993c9dda85c9fdc84e4cec0ca9cc1bd191c9fa112a1332a"
  ]
}

Check our transaction id returned from the send command is in the block:

bcli getblock 15bf3c15480ed033c993c9dda85c9fdc84e4cec0ca9cc1bd191c9fa112a1332a

And check out unspent outputs for the taproot wallet:

bcli -rpcwallet=taproot-wallet listunspent

[
  {
    "txid": "385504b1379770e6b3b8da1e07faf81cd36cd066f84fac33f14b61367608cd2e",
    "vout": 0,
    "address": "bcrt1pv3r0mpgnsufprtdh9yyag9rqh3k4ysd0fcn48vwslyfamhfd2l4qckam67",
    "scriptPubKey": "51206446fd8513871211adb72909d41460bc6d5241af4e2753b1d0f913dddd2d57ea",
    "amount": 0.09999842,
    "confirmations": 1,
    "spendable": true,
    "solvable": true,
    "desc": "tr([00a8d74e]dfb6959ac8931e834c89d8acba84f96e6b1b0034f9ec618d1dffb0f30d579956,or_b(pk(02cf390b69d48bdf855eca713527f1665ac4bf746d5dfaf579321e6fe0c2819084),s:pk([341b3bbc/1]02a110286ad8c309b8376c68dc9c0036d7de3d02a4de426abff7a818790ab1fc4f)))#fnfrp4ax",
    "parent_descs": [
      "tr(tpubD6NzVbkrYhZ4YKSWzQhgCCiD9oBFZxvSgUJ85HdBhpLFxvK865U9jF82xCoBAn9nwNZ4uwX7ZKhZbh2iZRPa5s3UHXg3v7d1srFY44SFJVt,or_b(pk(tpubD6NzVbkrYhZ4WWePjyPpUfyRsMjAsxtoZk3Yg1vjpFbgEkanxxkeLUW1qw7Q8k1n9asHy7yC9fJtQmYhAZLFvFr2iYUa2Lv8YWgtcPahTow/*),s:pk(tpubDEw9eT9USAAumgsw7uKZf94QpMcNpbnsbUPLKSSTrEFo7tnjnHTakQo3fxhoD41o5Lq25J64D4DYjPQZMPmVa5xvNX8qP1z19uMPRaGd9Uc/*)))#a78h9fyu"
    ],
    "safe": true
  }
]

The tooling around TapMiniScript is a little limited at the moment but some ideas on how to take this further could be:

Try more complex miniscript scripts
Implement a 2of2 between a Coldcard and a Ledger which decays into a 1 of 2 after -say- 6 blocks (be cautious with real funds)

Once the test is successful, don't forget to stop your node and clean the datadir.

MacOs zip packaging

This one should be relatively straightforward to test if you are on MacOS.

Either:

Compile from source on a mac

Or

Download MacOs Zip from bitcoincore.org

It should be possible to extract the Bitcoin application, drag it to the Applications directory and run it. For the first run you may need to right click the application and click run to give MacOS permissions to run the downloaded app.

Remember to shut bitcoin down as it will start running the initial block download on mainnet if you haven't configured a config file instructing it to do otherwise.

Ancestor Aware Funding

Transactions that use unconfirmed UTXOs as their input will now calculate the effective fee for all the transactions together and increase the fee on the child transaction to hit the desired fee.

Before beginning make sure you have already stopped your node and cleaned the datadir.

Run on regtest:

echo "regtest=1" >> $DATA_DIR/bitcoin.conf

bitcoind-test -daemon

Create a wallet

bcli createwallet test-wallet

{
  "name": "test-wallet"
}

Mine yourself some block rewards

bcli -rpcwallet=test-wallet -generate 1

Make another wallet to mine to to get previous transaction confirmed

bcli createwallet another-wallet

{
  "name": "another-wallet"
}

bcli -rpcwallet=another-wallet -generate 100

Create an address with test wallet

bcli -rpcwallet=test-wallet getnewaddress

bcrt1qwqnjhrp535gxul8rry2jg4xv4rq26ptlg9xqkg

Send a 1BTC, 10 sat per vbyte transaction to yourself using your 50btc block reward

 bcli -rpcwallet=test-wallet send '{"bcrt1qwqnjhrp535gxul8rry2jg4xv4rq26ptlg9xqkg": 1}' null "unset" 10

This transaction will remain unconfirmed unless we mine a block (which we wont)

Get another address:

bcli -rpcwallet=test-wallet getnewaddress

bcrt1qzwd6gz6dvu6yeh9cl6vdky4a2qszrmlymkugp5

Now send a 2BTC, 20 sat per vbyte transaction to yourself

 bcli -rpcwallet=test-wallet send '{"bcrt1qzwd6gz6dvu6yeh9cl6vdky4a2qszrmlymkugp5": 2}' null "unset" 20

As this second transaction will use the original 1BTC, 10 sat per vbyte transaction's output it would require both transactions to be included in a block. The PR tries to ensure that this child transaction is aware of that ancestor and sets it's fee sufficiently high so that when you average both transactions' fees out they hit your new target (20 sats per vbyte in this case).

Let's look at the transactions on this test wallet and their fees:

bcli -rpcwallet=test-wallet listtransactions

[
  {
    ...
    "category": "generate",
    "amount": 50.00000000,
    "label": "",
    "vout": 0,
    "abandoned": false,
    "confirmations": 101,
    "generated": true,
    ...
  },
  ...
  {
    "address": "bcrt1qwqnjhrp535gxul8rry2jg4xv4rq26ptlg9xqkg",
    "category": "send",
    "amount": -1.00000000,
    "label": "",
    "vout": 1,
    "fee": -0.00001410,
    "confirmations": 0,
    "trusted": true,
    "txid": "3c6f4e09becd0ba3c586535b6e3abdafd766c0e2fc1df5f24c162c60a88dc3e9",
    "wtxid": "de4b240151e07120cae459e40e24b6b2d71d11bd769e6a698741c1b23ce9cf96",
    ...
  },
  ...
  {
    "address": "bcrt1qzwd6gz6dvu6yeh9cl6vdky4a2qszrmlymkugp5",
    "category": "send",
    "amount": -2.00000000,
    "label": "",
    "vout": 0,
    "fee": -0.00004230,
    "confirmations": 0,
    "trusted": true,
    "txid": "3b22b7c7e78f4369177109437bbafe0be47393a12b637c1ac506fa9283fd774e",
    "wtxid": "050e8332d302578cf0c3f3019454d4ab921aeed36ff6ba498b52ad6b2c60b7eb",
    ...
  }
]

Pay attention to the fees paid. The fee on the first transaction was 1410 sats and the fee on the second was 4230. If we add these two fees together we get 5640 sats but that's obviously paying for two transactions. So if we assume equal weight and divide by two we get an average of 2820 paid per tx. This is double the 1410 sats we paid when we asked for 10 sats a vbyte. So the average across both appears to be 20 sats per vbyte as requested by our second transaction.

This test only used one ancestor but automatic bumping should affect all ancestor transactions. Try to make one or two more transactions at a different feerate and consider which transactions were bumped or not bumped.

Once the test is successful, don't forget to stop your node and clean the datadir.

Outbound connection management

The motivation behind this PR is to try to maintain at least one connection per network type (IPV4/6, tor, I2P, CJDNS).

Before beginning make sure you have already stopped your node and cleaned the datadir.

How to test this improvement:

Run on mainnet
Configure multiple networks (IP4/6, tor, I2P, CJDNS)
Observe that node connects to at least one peer in all of these networks
As you are on mainnet remember to shutdown bitcoind when you are finished

The problem with the above test is that it is entirely possible you would have had connections to all of those networks by chance. We can't prove the PR helped in this regard. It is beyond the scope of this testing document but one idea for how we could try to have more confidence that the PR is working is to setup a contrived network, perhaps using the Warnet tool.

Alternative testing idea using warnet

Run warnet with hundreds of IPV4 nodes and a handful of tor/i2p/cjdns nodes
Observe that the multi network nodes all find and connect with each other

The idea is that before the PR a multi network node would be happy just connecting to the plentiful IPV4 nodes.

Once the test is successful, don't forget to stop your node and clean the datadir.

Kudos if you make it this far 👏🎉

Thanks for your contribution and for taking the time to make Bitcoin awesome. For feedback on this guide, please visit #2xxxx

Many thanks to stickies-v, Pieter Wuille, murchandamus, Antoine Poinsot and Abubakar Sadiq Ismail for their input and review on this document.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

26.0 Release Candidate Testing Guide

Testing Guide: Bitcoin Core 26.0 Release Candidate

Overview

Preparation

1. Grab Latest Release Candidate

2. Compile Release Candidate

3. Setting up command line environment

4. Reset testing environment

RPC: add getprioritisedtransactions

RPC: Importmempool

V2 Transport - BIP 324

TapMiniscript

MacOs zip packaging

Ancestor Aware Funding

Outbound connection management

Clone this wiki locally