Output script descriptor are a language for describing individual
scriptPubKeys or HD chains of scriptPubKeys. See the Bitcoin Core
documentation.
PR 15368 added checksums
to descriptors. Since descriptors contain private or public keys where a
transcription error can lead to loss of funds, having to checksum to ensure
correct transcription is a sensible precaution.
Those checksums are based on a similar BCH encoding scheme as the bech32
address format. There are very detailed
comments
in the implementation explaining how the checksum is calculated.
The PR also added a new RPC method getdescriptorinfo that can be called
with a descriptor to analyse the descriptor and add the checksum. That RPC
method:
is a pure function. It has no side effects.
doesn’t need access to any blockchain or mempool data
doesn’t have access to the wallet.
The PR also added unit
tests
and updated several functional tests to use the checksums. A python
implementation
of the checksum was also added.
PR #15443 adds functional tests specifically for the new getdescriptorinfo RPC method.
Questions
What type of testing is used in Bitcoin Core?
What are the uses for unit tests and functional tests?
What is meant by solvable when talking about a descriptor?
Why are address and raw type descriptors always unsolvable?
<jnewbery> I thought this one was interesting because it gives us a chance to look at output script descriptors, which are going to be important in the Bitcoin Core wallet
<jnewbery> ok, great. digi_james: I know you had some questions about solvability and spendability this week. Can you state what your question was and what you learned?
<jnewbery> digi_james: that's right. So if the descriptor allows us to derive the scriptPubKey but not the scriptSig to spend it, then it's not solvable
<jnewbery> fjahr: ccdle12: yeah, that's right. Functional tests spin up one or more full running instances of the bitcoind node, so they test the full functional behaviour, but are much slower to execute
<ccdle12> maybe unit for the core logic? the descriptors seem to be almost "standalone" meaning the rpc calls don't touch any other part of the codebase/affect other parts of the running daemon
<hugohn> RE: disadvantages of functional/integration testing. If I might add, besides the fact that it's slow, IMO it might not be possible to have full 100% test coverage with functional/integration testing (unlike unit testing), because your functional tests usually test things in very specific orders and not all the possible ways the components can react. So it's helpful but, shouldn't be relied on exclusively.
<jnewbery> These tests call `getdescriptorinfo` to get the checksum from the bitcoind node, and also call descsum_create() to get the checksum from the python implementation
<lightlike> jnewbery: but doesn't this reasoning apply to basically everything (e.g. all kind of cryptographic functions)? I'm not sure why it is worth reprogramming function in python just for testing purposes and then keep it in the codebase.
<digi_james> jnewbery: Is there an formal/informal roadmap for descriptors? Whist there are very neat, I wonder if they could exist in PBSTs? I suppose they will play a larger role in wallets managing taproot paths?
<wumpus> jnewbery: I think the reasoning is that RPC is a separate 'subsystem' from whatever is being tested (it needs to be specifically initialized/torn down), so anything testing RPC *and something else* is already a functional/integration test
<wumpus> the internal functions used by RPC methods can of course, independently, be tested in unit tests, especially if they're pure utility functions