From Zero to Scripts: My Bitcoin CLI Learning Journey (Btrust Builders Program)

Muhammad Ademola — Mon, 11 May 2026 23:08:50 +0000

When I joined the Btrust Builders Program, I already had some prior exposure to Bitcoin — having gone through month 1 of the BOSS program and Code Orange's Bitcoin Dojo exercises. What followed was weeks of hands-on work with the Bitcoin CLI, and eventually, real contributions to the Bitcoin open source ecosystem. Here's an account of how it went.

Getting Started

The first two chapters of the material (Learning-Bitcoin-from-the-Command-Line) covered installing Bitcoin Core, configuring a node, and understanding the basics of elliptic curve cryptography and public key cryptography. In practice, setting up the .conf file and deciding which node to run took significantly more time than I expected. Running multiple nodes simultaneously on the same system added another layer of complexity the material didn't fully prepare me for. Still, the conceptual foundation landed well, Bitcoin's value in a trustless environment, how addresses are derived.

First Real Commands: Wallets, Addresses, and Transactions

Chapter 3 was where things got interactive. I set up aliases in .bash_profile to shortcut common bitcoin-cli commands, created a wallet, generated a legacy address, signed a message, and verified it against my signature. Working through this manually made the relationship between private keys, public keys, and addresses concrete rather than abstract.
One early gotcha: the tutorial recommended creating a non-descriptor wallet, but that's an outdated approach. Modern Bitcoin Core only supports descriptor wallets, so I had to adapt. I also sent sats from a testnet faucet and waited for my balance to reflect due to slow sync speeds on my system. Frustrating, but it taught me patience with confirmation times.
By chapters 4 and 5, I was building raw transactions from scratch, signing them, and broadcasting. Getting comfortable with jq to parse JSON output from CLI commands unlocked a lot, especially for constructing transactions from lists of UTXOs and generating change addresses programmatically. Understanding SegWit here was also important: the witness data lives separately from the transaction, and that separation matters for how blocks are structured.
RBF (Replace-By-Fee) and CPFP (Child-Pays-For-Parent) were concepts I'd heard about but never properly tested. Running them hands-on made the mechanics click. CPFP, though, I still haven't implemented fully, that's still on my list.

Multisig, PSBT, and the Private Key Problem

Chapters 6, 7, and 8 introduced multisig and PSBT.
Multisig involves collecting public keys from multiple wallets, using createmultisig to generate a shared address (the resulting 2... address signals P2SH-SegWit), and storing the descriptor for later use. Sending funds to a multisig address is straightforward. Spending from one is where it gets complicated.
Spending requires including the scriptPubKey alongside txid and vout, a step beyond the usual transaction flow. The real blocker was retrieving private keys to sign: dumpprivkey is unavailable in the latest Bitcoin Core versions. I attempted to write a script to extract private keys from wallet.dat, but it didn't produce the expected result. After research, I narrowed it down to two likely causes, the second address I used was generated from bitaddress.org and wasn't testnet-compatible, and the retrieved private key didn't match what the script needed to unlock the funds. The concept was solid regardless.
A cleaner path I also explored uses addmultisigaddress with public keys across both machines, then creates and signs the transaction on each, simpler and more practical.
PSBT (Partially Signed Bitcoin Transactions) built directly on the multisig experience. It formalizes a workflow for transactions requiring multiple signers or external devices, the creator builds it, signers and finalizer process, and extractor finalize. It's particularly powerful for hardware wallet integration, where the private key never touches an internet-connected device, especially in air-gap wallet. The tutorial used HWI to demonstrate this.

Scripting, Timelocks, and the Deeper Picture

The later chapters pulled back the curtain on Bitcoin's scripting system. Transactions are locked and unlocked through scriptPubKey and scriptSig, evaluated on a stack (LIFO). Walking through P2PKH script execution, the unlocking script carrying the signature and public key, the locking script containing the hash and operators, made the security model intuitive.
P2SH emerged as an elegant workaround: instead of embedding a complex locking script directly in the transaction (which most nodes would reject), you hash it and embed only the hash. The full script is revealed only when the recipient spends. The two-round validation, first proving the redeemScript matches the hash, then satisfying the script itself, took a simple OP_ADD example to fully click.
Timelocks rounded things out. nLockTime locks an entire transaction to a block height or UNIX timestamp. CLTV (CheckLockTimeVerify) improves on it by locking individual outputs rather than the full transaction. CSV (CheckSequenceVerify) handles relative timelocks, and understanding how nsequence interacts with these opcodes, particularly needing to be disabled for CLTV to work, was a detail that required careful reading.
The chapters on conditionals (OP_IF/OP_ELSE), OP_VERIFY, and complex multisig scripts with timelocks showed just how composable Bitcoin scripting can be, and gave a meaningful foundation for understanding why the Lightning Network is built the way it is.

Beyond the Curriculum: Contributing to the Ecosystem

Alongside the structured learning, I started contributing to Bitcoin open-source projects — including BDK Wallet, Cove, Floresta, and SeedSigner.
A significant contribution came from investigating a RUSTSEC-2026-0097 security issue in bdk_wallet. I dug into the codebase, traced the vulnerability across multiple layers of dependencies, and attempted a fix, only to discover the real blocker sat upstream in two libraries that haven't had stable releases yet. I opened an issue on the repository. The lead maintainer reviewed it and added it to the official Wallet 4.0.0 milestone. I'm now monitoring the upstream libraries and will open the fix PR once their stable releases land.
Another contribution involved a Cove (a Bitcoin wallet) PR that replaces a direct cbor4ii dependency with minicbor-serde, consolidating all Cove-owned CBOR serialization under the minicbor family.

Contributions:

What's Next

Continuing to contribute to the projects above, while keeping an eye on upstream libraries for further contribution opportunities — rust-bitcoin, rust-miniscript, PSBTv2, and eventually Bitcoin Core itself. I'm also starting a weekly writing series on Bitcoin, building from cryptography fundamentals (Field element, Finite Field, ECC) through to addresses and transactions, and planning to go through the Btrust learning materials again more carefully to look for possible improvements or PRs. On the technical side, deepening my Rust knowledge remains a consistent thread through all of it.

Written as part of the Btrust Builder Program — a Bitcoin developer education initiative.

DEV Community: Muhammad Ademola