3

I would like to dig into the open Taproot PR (PR #19953) to understand it, test it and possibly even review it. Any advice or recommendations?

5

Previous Bitcoin Core PR review club sessions

A good starting point is the various Bitcoin Core PR review club sessions that have been held thus far on specific commits of the Taproot PR. The latest one was on "Implement Taproot validation" (hosted by John Newbery) and there are various notes and a transcript of the meeting there. There are also links to the previous review club sessions on the Taproot PR on that page.

Build the PR

When reviewing a PR it is always a good idea to build the PR. For simplified guidance on building a PR see this StackExchange question. For more detailed guidance see this resource from Jon Atack.

Obviously the fork of Bitcoin Core you will want to clone is sipa's (Pieter Wuille's) and the branch you will want to check out is taproot.

There is no GUI or wallet support in this Taproot PR so you will want to use the following flags when configuring to save time.

./configure --without-gui --disable-wallet

Understand what the PR does (and what it doesn't)

On the PR Pieter Wuille states:

No signing or wallet support of any kind is included, as testing is done entirely through the Python test framework.

This is pretty limited scope. All signing and validation of (Schnorr) signatures is already handled by the libsecp256k1 library which has its own separate repo. But what Pieter is saying here is that with the current Taproot branch you can't create a Taproot (pay-to-taproot or P2TR) address or Taproot spend from your Bitcoin Core wallet or using bitcoin-cli. The only way you can create Taproot transactions is using the Python code in the functional test framework. So if you know some Python you can adjust the Python code to create different Taproot transactions but other than that you can't create Taproot UTXOs or spend from them.

Once Taproot transactions are created from the Python functional test framework this PR branch will allow you to validate Taproot spends with the C++ validation code.

Functional tests

Given the only Taproot transactions that are validated by your Bitcoin Core full node are coming from the functional test framework it is a good idea to start your code review there. Some existing functional tests are edited in this PR but there is a new functional test added called feature_taproot.py. This test generates random Taproot transactions and verifies they are accepted into the mempool (when appropriate) and accepted (when appropriate) into Python-constructed blocks.

You can run this new functional test directly by running:

test/functional/feature_taproot.py

After a few minutes this test will very likely pass. So here is where you can be creative in making changes to the test or the C++ code it is testing before running the test again to see what you need to do to make this test fail.

What to avoid

There are a few things to avoid on this PR. It is still possible that there is a conceptual problem with the Taproot design but at this stage it is unlikely. There was an in depth discussion of the evolution of the conceptual design of Taproot at this Socratic Seminar at London BitDevs covering years of discussions. I would recommend watching that or reading the transcript of that if you think you have discovered a conceptual problem. Alternatively, you are free to ask questions on the ##taproot-bip-review channel on IRC.

Another thing to avoid on this PR is discussion of activation (or deployment). This PR completely avoids any decision on activation method and so there should be no discussion of activation on this PR. If you look at the commit on Activate Taproot/Tapscript on regtest (BIP 341, BIP 342) there is a deployment date set of January 1 2008 for regtest but other than that no activation or deployment parameters are set. If you would like to discuss activation there is another IRC channel ##taproot-activation for that purpose.

// Deployment of Taproot (BIPs 340-342)
    consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].bit = 2;
    consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nStartTime = 1199145601; // January 1, 2008
    consensus.vDeployments[Consensus::DEPLOYMENT_TAPROOT].nTimeout = 1230767999; // December 31, 2008

The PR is at a reasonably advanced stage and what it is really seeking is code review, testing and (maybe!) additional tests.

For guidance on debugging Taproot functional tests see this other StackExchange question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.