Testing blockchain examples

[evanlinjin]

In the future, the examples will become individual modules/packages within the BDK repository. We want to test the functionally of the {}_example::Client methods to ensure the outputs is expected given different scenarios.

Although we want to test the Clients under the same set of scenarios, the syncing/scanning logic of each example is unique, so we want to check the outputs individually. Additionally, we may change the API of these Clients so we do not want to deal with the hassle of maintaining additional generic/wrapper code.

We will provide the Clients real blockchain data via the bitcoind and electrsd crates.

We will maintain a list of scenarios in this ticket description (I will update it via suggestions in the comments below).

Scenarios

• Ensure stop_gap functions correctly. Does the methods correctly process a transaction history with self-sends right at the boundaries of the input stop_gap?

• If we provide the methods with "already-reorged" data, is the output as expected? I.e. Does the returned SparseChain/ChainGraph contain checkpoints at agreement_point and invalid_from indexes.

[rajarshimaitra]

Removing myself as I will only be able to focus on testing for one example and preferably RPC.

I am not fully clear on some points like If we provide the methods with "already-reorged" data as there doesn't seem to be any method taking in any blockchain-related data. But looking forward to seeing the full scenario list, and I will try to reproduce them with RPC example and bitcoind.

[evanlinjin]

Removing myself as I will only be able to focus on testing for one example and preferably RPC.

I am not fully clear on some points like If we provide the methods with "already-reorged" data as there doesn't seem to be any method taking in any blockchain-related data. But looking forward to seeing the full scenario list, and I will try to reproduce them with RPC example and bitcoind.

No worries Raj.

Methods take in checkpoints. That is "Blockchain-related" data. We emulate a situation when we already have pre-existing data existing before call to the methods.

[rajarshimaitra]

Methods take in checkpoints. That is "Blockchain-related" data. We emulate a situation when we already have pre-existing data existing before call to the methods.

Okay. If I am thinking right, then we can also do the same by reorging bitcoind and resanning with the previous chain-state of the tracker. Won't that be a more "real" scenario than trying to feed the data manually in the wallet_txid_scan function?

Anyway, I think it will be clearer to talk over code than words. I will try to sketch up something by the end of the week.

[notmandatory]

Hey all just a reminder that @danielabrozzoni and I are in Nashville so may not get too much testing done this week, but I propose to help us divide and conquer we each focus on one of the blockchain clients and do at least one or two manual + integration tests .. and as we go along we can compare approaches and results. Would this division work for everyone?

• electrum: @notmandatory
• esplora: @vladimirfomene
• rpc: @rajarshimaitra
• cbf: @danielabrozzoni

[LLFourn]

I think esplora, electrum and the bitcoin rpc wallet are ready to test. What it exactly means to test CBF is not really clear to me. The only thing I can think of is that there is a API in CBF that when given a list of checkpoints (block height and hash) returns a stream of blocks starting at the block after the last checkpoint it found that is still in the chain.