Learning Bitcoin

Learning Bitcoin from the Command Line (GitHub guide) — my honest review, setup tips, and FAQ

Ever wanted to actually useBitcoin Core, run real commands, and see what’s going on under the hood—but keep bouncing off tutorials that either hand-wave the hard parts or drown you in code?

Same. I’ve tested a lot of paths, and the GitHub project Learning Bitcoin from the Command Line is one of the few that turns curiosity into real, repeatable skills. If you want hands-on practice with bitcoin-cli, transactions, and modern wallet concepts (without risking coins), this is the path I recommend.

Describe problems or pain

Most Bitcoin “guides” fall into two buckets: too high-level to be useful or too code-heavy to be practical. The result? You aren’t building confidence—you’re tab-hopping and guessing.

• Setup confusion: Full node, pruned node, testnet, regtest—what’s safe to use while learning? What if you mess up a mainnet config?


• Out-of-date commands: Bitcoin Core evolves. A tutorial written for 0.20 might fail on 24.x or 26.x. PSBT and descriptors changed a lot of workflows.


• No context, just commands: You copy–paste something that “works,” but you don’t know why. Next time you’re stuck, you’re back at zero.


• Tool mismatch: One guide uses Electrum’s GUI, another uses a random library, then someone throws in a node-in-a-box script. You never learn the core tooling.


• Time sink: Full mainnet syncs take ages. If you’re just trying to learn, that’s not a good first step.

There’s a better way than chasing videos and Discord posts.

Promise solution

Learning Bitcoin from the Command Line teaches by doing. You’ll:

• Run bitcoind the right way and talk to it with bitcoin-cli


• Craft, inspect, and verify transactions so you understand every input and output


• Practice with regtest and testnet so it’s fast, safe, and free


• Get hands-on with modern concepts like PSBT, descriptors, and multisig—skills that transfer to real wallets and audits

Why this method works: Active, hands-on learning outperforms passive reading. A large meta-analysis in STEM found that students in active learning settings improved exam performance and reduced failure rates versus traditional lectures (Freeman et al., PNAS).

And yes—this approach fits how developers learn too. Most engineers live in the terminal daily (see the Stack Overflow Developer Survey), so building Bitcoin muscle memory on the command line just makes sense.

Who this outline is for

• Builders and tinkerers: You want to learn Bitcoin Core the real way—no black boxes.


• Self-custody learners: You want to understand what your wallet is actually doing before you trust it.


• Auditors and power users: You care about PSBTs, descriptors, and proper verification.


• Curious beginners with grit: No heavy coding required, but you’re comfortable trying commands and reading outputs.

What you’ll take away

• A clear starting plan: Which OS setup to use, when to pick regtest vs. testnet, and how to avoid mainnet risks while learning.


• Realistic expectations: Hardware and time requirements, plus what you can accomplish in a weekend vs. over a few focused sessions.


• Core skills that stick: RPC basics, bitcoin-cli fluency, fee sanity checks, PSBT workflows, descriptors for portable wallet definitions, and a sane approach to multisig.


• Confidence, not copy–paste: You’ll understand what you’re signing and broadcasting—and how to verify it.

Here’s the plan: I’ll show what this GitHub guide actually covers, who gets the most out of it, and how to get your first successful run without wasting a week on setup. Ready to see what’s inside and why it matters in 2025?

What is “Learning Bitcoin from the Command Line” and why it matters

“Learning Bitcoin from the Command Line” is a community-driven curriculum on GitHub led by Christopher Allen and contributors, built around the real tools that power Bitcoin. It’s not a flashy course or a series of slides. It’s a practical walk-through of Bitcoin Core—the software that secures the network—so you build skills you can actually use.

“Don’t trust, verify.” — Bitcoin ethos

I like this project because it respects that ethos. You don’t just read about wallets or transactions—you run commands, inspect the results, and prove to yourself what’s happening. That’s exactly how you avoid hand-wavy myths and start making confident decisions with your own keys and your own node.

What exactly is inside this GitHub guide?

The guide is organized into chapters you can follow at your own pace. You start simple and gradually take on real Bitcoin operations. Expect to work with:

• Environment setup and running bitcoind, so you control a local node


• bitcoin-cli and RPC basics, so you can ask your node anything and get structured answers


• Addresses, scripts, and SegWit, so you understand what your wallet actually creates


• Raw transaction construction and inspection, so fees, inputs, and outputs stop feeling mysterious


• PSBT (Partially Signed Bitcoin Transactions), so you can separate building and signing safely


• Descriptors, so wallets become precise, portable definitions rather than magic folders


• Multisig patterns, so collaboration and recovery are clear—not scary


• Safe practice on regtest/testnet, so you never risk real coins while you learn

If you like to see what you’re getting into before you begin, the repo is here: Learning Bitcoin from the Command Line.

Who is it for: beginner, dev, or power user?

It fits motivated beginners through intermediate users. You don’t need to be a programmer to start. Comfort with a Unix shell helps because you’ll be running commands, editing simple configs, and reading JSON.

• Beginners: You’ll finally understand the basics without guessing.


• Builders and power users: You’ll tighten up your transaction, PSBT, and descriptor workflows.


• Auditors and security-minded users: You’ll gain the vocabulary and checks to verify what software claims to do.

Is it up to date in 2025?

The fundamentals don’t go stale—RPCs, PSBT, descriptors, SegWit, multisig, and Taproot concepts all hold up. What does change are a few command details and defaults between Bitcoin Core releases. That’s normal. My practical tip:

• Pin a specific Bitcoin Core version while you work through the chapters.


• Check the repo’s recent commits and issues for notes on PSBT, descriptors, and Taproot-related tweaks.


• If a command’s output looks different, run the built-in help (for example, bitcoin-cli help send) and adjust—this is part of the learning.

Staying nimble here actually makes you better. Real-world node operators deal with version differences all the time.

How this guide teaches (and why it sticks)

It teaches by doing. You type commands, read responses, validate results, and fix small mistakes. That hands-on approach works. A well-known meta-analysis of active learning in STEM found that practical, engaged methods improve performance and reduce failure rates versus passive lectures (Freeman et al., PNAS).

In plain English: when you build a PSBT yourself, you remember it. When you decode a transaction and see the exact inputs, scripts, and witness data, the theory stops feeling abstract. That confidence is the whole point.

What you will and won’t learn

• You will learn how Bitcoin Core actually behaves: starting and querying a node, creating and funding transactions, fee reasoning, PSBT workflows, descriptors, and the mechanics behind multisig. You’ll also learn to test ideas safely on regtest and testnet.


• You won’t learn copy-paste trading “strategies,” hype, or a shortcut to a certificate. This is about fundamentals, security, and repeatable workflows—skills you can prove by what you run and what you ship.

Here’s the emotional kicker: once you see that you can build and verify your own transactions—no black boxes—you’ll feel a shift. Things click. You stop outsourcing trust and start verifying for yourself. That feeling is why this guide matters.

Ready to see the first “it works!” moment on your own machine? I’ll walk you through the setup next—OS choices, quick installs, and a simple milestone where your node answers back. Want that fast win?

Setup, system requirements, and your first successful run

I want you to hit your first “it works” moment fast. No rabbit holes, no risky coins, no mystery errors you can’t fix. Here’s exactly how I set up Bitcoin Core for hands-on learning, what hardware really matters, and how to run your first commands on a safe local network.

“Tell me and I forget, teach me and I remember, involve me and I learn.”

Do I need Linux for this?

Short answer: no—but it helps. Here’s what I recommend, in order of smoothest experience:

• Linux (Ubuntu/Debian): The path of least resistance. Package managers, sane defaults, and file paths that match most Bitcoin docs.


• macOS: Works great. Use Homebrew for quick installs. Keep your data dir in the default place for sanity.


• Windows: Use WSL2 (Ubuntu). It’s stable and fast enough for practice. Important: keep your Bitcoin data inside the Linux filesystem (e.g., ~/.bitcoin)—writing to /mnt/c is much slower.

If you like clean separation, a VM or Docker container is fine too. For containers, remember to persist your data directory with a volume, or you’ll lose your chainstate and wallets when the container stops.

Do I need a full sync?

Not to learn. You’ll get more and learn faster with the built-in testing networks:

• regtest: Your own private blockchain. You mine instant blocks on demand. Perfect for practicing transactions safely.


• testnet: Public test network with “play” coins. Feels closer to mainnet behavior (confirmation times, mempool, peers).

If you later want a mainnet node, consider pruned mode to save disk space. You can keep only recent blocks while still verifying your own transactions. A practical prune target is 10–20 GB. Details: Bitcoin Core docs.

Minimum hardware and time

• For regtest/testnet: Any modern laptop with 8 GB RAM is fine. SSD helps, but not mandatory for regtest.


• For a future mainnet sync: Plan for a lot of disk and time. Think 500–600+ GB if unpruned, an SSD strongly recommended, and dozens of hours for the initial sync. Bandwidth usage is significant; plan ahead.

My advice: start on regtest today, learn the ropes, then graduate to testnet. You’ll move faster and avoid the “waiting days to sync” trap.

First successful milestone

Here’s the exact sequence I use when I want to know a setup is rock solid. You’ll be mining blocks to yourself on regtest within minutes.

1) Start the node (regtest, backgrounded)

• Linux/macOS:
  
  
  
  • bitcoind -regtest -daemon
  
  
  
  


• Windows (WSL2):
  
  
  
  • bitcoind -regtest -daemon
  
  
  
  

2) Confirm it’s talking to you

• bitcoin-cli -regtest getblockchaininfo


• You should see "chain": "regtest" and block height 0.

3) Create a wallet and get an address

• bitcoin-cli -regtest createwallet "lab"


• ADDR=$(bitcoin-cli -regtest -rpcwallet=lab getnewaddress)

4) Generate funds instantly

• bitcoin-cli -regtest generatetoaddress 101 "$ADDR"


• Why 101? Coinbase rewards mature after 100 blocks, so this gives you spendable balance right away.

5) Check your balance

• bitcoin-cli -regtest -rpcwallet=lab getbalance


• Seeing a positive balance here is the “I can build from this” moment.

If this worked, you’re set to practice real Bitcoin operations without risking a sat of mainnet value.

Common setup errors and quick fixes

• “Couldn’t connect to server”:
  
  
  
  • Is bitcoind running? Check with bitcoin-cli -regtest getnetworkinfo.
  
  
  • Double-check you’re passing -regtest to both bitcoind and bitcoin-cli.
  
  
  
  


• RPC auth errors:
  
  
  
  • By default, bitcoin-cli uses cookie auth. It just works if both processes share the same datadir.
  
  
  • If you set manual creds in bitcoin.conf, ensure server=1, and the credentials match exactly. Cookie location:
    
    
    
    • Linux: ~/.bitcoin/regtest/.cookie
    
    
    • macOS: ~/Library/Application Support/Bitcoin/regtest/.cookie
    
    
    • Windows (WSL2 inside Linux): ~/.bitcoin/regtest/.cookie
    
    
    
    
  
  
  
  


• “Method not found” or wallet-related RPC failures:
  
  
  
  • You likely didn’t select the wallet. Add -rpcwallet=lab.
  
  
  • Create one if needed: bitcoin-cli -regtest createwallet "lab".
  
  
  
  


• Fee estimation not available on regtest/testnet:
  
  
  
  • For simple sends that rely on fee estimation, set a fallback fee in bitcoin.conf:
    
    
    
    • fallbackfee=0.0002
    
    
    
    
  
  
  • Or use PSBT flows and specify fees directly when funding the transaction.
  
  
  
  


• Firewall/port conflicts:
  
  
  
  • You don’t need inbound ports open for regtest, but if you use testnet or mainnet p2p:
    
    
    
    • Mainnet p2p: 8333, testnet: 18333, regtest (local): 18444
    
    
    • Default RPC ports: mainnet 8332, testnet 18332, regtest 18443
    
    
    
    
  
  
  
  


• Path confusion on macOS/Windows:
  
  
  
  • Linux: ~/.bitcoin/bitcoin.conf
  
  
  • macOS: ~/Library/Application Support/Bitcoin/bitcoin.conf
  
  
  • Windows: %APPDATA%\Bitcoin\bitcoin.conf (for WSL2, use the Linux path inside Ubuntu).
  
  
  
  


• Mismatched Core versions:
  
  
  
  • Keep bitcoind and bitcoin-cli from the same install. If you have multiple versions on PATH, call them with absolute paths to avoid weird errors.
  
  
  
  

A minimal bitcoin.conf that just works

Create or edit your config at the default datadir path (above). This keeps your commands short and repeatable:

• regtest=1


• server=1


• daemon=1 (Linux/macOS)


• fallbackfee=0.0002 (useful on regtest/testnet)

Start once with bitcoind, and from then on bitcoin-cli will find your node and wallet automatically.

Real-world OS notes I’ve learned the hard way

• WSL2: Install with wsl --install, choose Ubuntu, and install Bitcoin Core inside Ubuntu. Keep your datadir in ~/.bitcoin for fast I/O.


• macOS: Use Homebrew:
  
  
  
  • brew install bitcoin-core
  
  
  • Then start with brew services start bitcoin (for mainnet) or run binary manually with -regtest.
  
  
  
  


• Linux: Prefer the official binaries or trusted repos; verify signatures when you can. On Ubuntu:
  
  
  
  • Download from bitcoincore.org, verify, extract, and add to PATH.
  
  
  
  

When that first getblockchaininfo returns healthy data and you watch your wallet balance appear after generatetoaddress, you’ll feel it—the “I can build with this” switch flips. That confidence matters.

Now that your node answers you, how about using it to construct something real? Want to create, fund, and inspect your first transaction—seeing exactly what you’re signing and why the fee is what it is? That’s where we’re headed next.

Key skills you’ll build, step by step

There’s a real shift that happens when you stop reading about Bitcoin and start shaping transactions yourself. The guide makes that shift feel natural. You type a command, see a result, and your mental model tightens. It’s learning you can feel.

“What I cannot create, I do not understand.” — Richard Feynman

Will I learn to construct and inspect transactions?

Yes—and you’ll do it safely on regtest/testnet so there’s zero risk. You’ll go from blank terminal to a signed, broadcast transaction you fully understand.

• Find and prepare inputs: Create a wallet (createwallet), get a SegWit address (getnewaddress "" bech32), mine funds on regtest (generatetoaddress), then list spendable UTXOs (listunspent).


• Craft the transaction: Build a skeleton with createrawtransaction or let Core do the funding with fundrawtransaction. Decode it with decoderawtransaction to check the inputs, outputs, and change.


• Control your fees: Set fee_rate in fundrawtransaction (sat/vB), or confirm via estimatesmartfee. Validate policy rules with testmempoolaccept before you send.


• Sign and send: Use signrawtransactionwithwallet and then sendrawtransaction. Track it with getmempoolentry and confirm with generatetoaddress (regtest) or by waiting on testnet.

Example flow you’ll actually run:

Pick a UTXO, create a raw tx, fund it, decode to verify outputs and fee, sign, then broadcast. You’ll see the exact sats moving and why they move—that clarity is the payoff.

What about PSBT and descriptors?

This is where the guide really levels you up. You’ll practice the PSBT lifecycle and learn descriptors so your wallets are portable and recoverable anywhere that speaks the same language.

• PSBT (Partially Signed Bitcoin Transactions):
  
  
  
  • Create a PSBT with walletcreatefundedpsbt.
  
  
  • Inspect it using decodepsbt; understand inputs, scripts, and what’s still needed.
  
  
  • Update with utxoupdatepsbt if an external signer needs UTXO metadata.
  
  
  • Sign in one or more places with walletprocesspsbt or hardware tools.
  
  
  • Finalize with finalizepsbt, then broadcast.
  
  
  
  


• Descriptors (wallet blueprints):
  
  
  
  • Create descriptor-based wallets (createwallet "name" true true "" true sets descriptors=true).
  
  
  • Work with common forms: wpkh([fingerprint/84h/0h/0h]xpub/0/*), wsh(sortedmulti(2,xpub1/0/*,xpub2/0/*,xpub3/0/*)), tr(xpub/86h/0h/0h/0/*).
  
  
  • Export with listdescriptors true and re-import anywhere via importdescriptors.
  
  
  
  

Why it matters: descriptors describe your wallet precisely, not just vaguely. That precision makes recovery and cross-tool compatibility sane, especially for multisig. And PSBT keeps private keys off your online machine without slowing you down.

Does it cover Taproot and SegWit?

SegWit is standard throughout, and you’ll get practical Taproot awareness too, depending on your Core version.

• SegWit in practice: Create bech32 addresses (getnewaddress "" bech32), fund with sendtoaddress, and watch fee savings in decoderawtransaction as vbytes drop.


• Taproot (bech32m): Generate getnewaddress "" bech32m, confirm with getaddressinfo (witness_version: 1), and build PSBTs that spend to/from Taproot. You’ll see how key-path spends simplify life for single-sig while staying future-proof for script-paths.

Reality check: some Taproot scripting examples may evolve with Core releases, but the guide shows you how to confirm capabilities at the command line so you always know what your node can actually do.

Is there multisig and wallet management?

Yes, and it’s taught the right way—with descriptors and PSBT so you’re not stuck inside one wallet forever.

• Build a 2-of-3 the modern way:
  
  
  
  • Derive three xpubs (often on separate machines or hardware).
  
  
  • Compose a descriptor: wsh(sortedmulti(2,xpubA/0/*,xpubB/0/*,xpubC/0/*)).
  
  
  • Distribute that descriptor to each cosigner using importdescriptors.
  
  
  • Create a PSBT on one wallet, pass it around for signatures, finalize, broadcast. Every cosigner can verify exactly what they’re signing—addresses, change, fee, everything.
  
  
  
  


• Backups you can trust: Export descriptors (and if used, miniscript policies) so another tool—or even another machine—can recreate the same address space. No opaque magic; it’s all explicit.

It feels great to look at a PSBT and say, “I know where every sat is going.” That’s the point.

Do I need to code?

No heavy coding. You’ll use commands and a few simple shell tricks. If you like, you can script repetitive tasks and query responses with jq to keep things clean:

• bitcoin-cli listunspent | jq '.[0].txid' to grab a txid


• bitcoin-cli -named walletcreatefundedpsbt inputs='[]' outputs='{"addr":0.001}' for readable named args

If you get curious, you can automate a full PSBT flow in under 30 lines of bash. But you don’t need to write a program to succeed here.

How long will this take?

Plan for focused sessions, not endless weekends. Based on my pacing and what readers report:

• Core basics (wallet, UTXOs, sends): 3–4 hours


• Raw tx and fee control: 2–3 hours


• PSBT + descriptors: 3–5 hours


• Multisig (2-of-3) the right way: 2–4 hours


• Taproot touchpoints: 1–2 hours

Why this method sticks: active, hands-on learning boosts understanding and retention compared to passive reading. That’s not just a feeling—it’s been shown across fields, including a well-known meta-analysis on active learning in STEM classrooms showing significant gains in performance (Freeman et al., PNAS).

There’s a moment when you press enter, your handcrafted transaction confirms, and the fear disappears. You don’t just “trust the wallet” anymore—you verify. So, is this approach perfect, or are there trade-offs you should know before you jump in? Let’s talk about that next—what’s amazing about this guide, and what might trip you up if you rush…

Pros, cons, and who should use this guide

Biggest wins

It builds real skill, fast. This isn’t theory. You’re on the keyboard, using bitcoin-cli, inspecting UTXOs, and crafting transactions the way real wallets do. That active, hands-on approach matters—research on “active learning” in technical fields shows better outcomes and fewer failures compared to passive lectures (see: Freeman et al., PNAS 2014). In plain English: doing the work makes it stick.

• Confidence with Bitcoin Core: You won’t just “have a node running.” You’ll understand what’s happening—RPC calls, mempool behavior, fees, change outputs, and why descriptors and PSBT exist.


• Safe practice environment: Regtest lets you print blocks on command and test transactions without risking a sat. That feedback loop is addictive and productive.


• Modern wallet skills: You’ll learn descriptors, PSBT, and multisig workflows that map to how serious wallets operate today. That means fewer black boxes and fewer scary unknowns during recovery.


• Portable knowledge: Once you can build, sign, and verify transactions at the command line, you can evaluate any wallet or tool with clarity. You’ll catch “gotchas” others miss.

One quick example from my own notes: I used the guide’s flow to create a 2-of-3 multisig on regtest with descriptor-backed wallets, funded it, then made a PSBT, passed it between two separate signers, and finalized. Later, I wiped one wallet and restored it using only the descriptor and keys. Seeing the change output land exactly where expected felt like flipping on a light switch—you stop guessing, start verifying.

Where it might frustrate you

The command line is honest—but unforgiving. It rewards attention and punishes haste. A few places learners stumble:

• Version wrinkles: Bitcoin Core evolves. Descriptor wallets are the default in recent versions, PSBT fields have matured, and Taproot added new descriptor types like tr(). If the guide screenshots or commands were written for an older release, you’ll want to pin a version or adapt commands. It’s not hard—just be consistent.


• RPC typos and quoting errors: JSON is picky. A missing quote or comma breaks a command. The fix is simple: slow down, keep a scratchpad of “known good” calls, and compare output carefully.


• Copy-paste traps: Line wraps, shell history, or a hidden character can derail a transaction build. I keep commands in a clean text file, not a browser, and I annotate each line so I know why it’s there.


• Concept jumps: Moving from legacy addresses to SegWit to Taproot can feel like a lot at once. The guide’s pace is reasonable, but if you rush, your brain will push back. Quick breaks pay dividends.

Field note: When in doubt, run a read-only RPC first. For example, list UTXOs or decode a PSBT before you broadcast anything. “Measure twice, send once.”

None of these are deal-breakers. They’re signals that you’re working with the real thing—and that mastery is a weekend and a few careful sessions away.

Who should take this path (and who shouldn’t)

• Great fit: Builders, security-minded self-custodians, node runners, technical auditors, and curious users who want to understand what wallets and nodes actually do. If you like to verify, not trust, this is your lane.


• Also great for: Educators and support pros. If you help others with Bitcoin, being able to inspect transactions and explain change/fees with authority is a superpower.


• Maybe not for you: If you only want a glossy GUI walkthrough or you absolutely refuse to touch a terminal. No shame—there are easier paths. But this guide’s magic is that it removes the mystery by showing you the moving parts.

A quick personal sample: a friend who manages family funds used this path to set up a descriptor-based 2-of-3 vault for inheritance planning. No coding background, just determination. The breakthrough came when they could decode every transaction and see exactly where change was going. Fear dropped, fluency rose.

Light resource mention before you wrap up

Keep a second screen open with the Bitcoin Core documentation for RPC details, and a solid, readable reference like “Mastering Bitcoin” for context. The trick is to use them as companions—not detours—so you stay in the command line doing the work.

Want my streamlined, 5-step plan to start in under 15 minutes—and the blunt answers to the questions I get every week? Ready when you are.

Quick-start plan, FAQs, and what to do next

Your 5-step quick-start

Here’s the fastest way to get momentum without getting stuck on setup.

• Pick your environment. Linux or macOS keeps things simple. On Windows, install WSL2 and use Ubuntu.


• Install Bitcoin Core. Grab it from bitcoincore.org. For consistency, pin a version (e.g., 26.x/27.x) so commands match the guide.


• Run Core on regtest. Start with: bitcoind -regtest -daemon. Then confirm it’s alive: bitcoin-cli -regtest getblockchaininfo.


• Prove your setup “end to end.” Make a clean practice wallet and some blocks:
  
  
  
  • bitcoin-cli -regtest createwallet "learn"
  
  
  • ADDR=$(bitcoin-cli -regtest getnewaddress)
  
  
  • bitcoin-cli -regtest generatetoaddress 101 "$ADDR"
  
  
  • bitcoin-cli -regtest getbalances (you should see spendable balance)
  
  
  
  


• Graduate to testnet when ready. Switch to -testnet, repeat the basics, and try broadcasting a transaction to the public network (test coins only).

FAQ: fast answers to common questions

• Is it free? Yes. The GitHub curriculum is open and community-maintained: Learning Bitcoin from the Command Line.


• Will I risk real coins? Not if you stay on regtest/testnet. Keep mainnet funds far away until you’re confident.


• Windows or Mac okay? Yes. Linux is the smoothest path. On Windows, use WSL2. macOS works well natively.


• Do I need a full node? For learning, no. Regtest is instant; testnet is public but lightweight. Mainnet (pruned if needed) can come later.


• Is there a certificate? No. Show your work with a public repo, notes, or a small project. That’s more meaningful anyway.


• Can I use this for Lightning later? Absolutely. These fundamentals (RPCs, PSBT, descriptors) make Lightning setup and tooling far easier.


• Can I use Docker? Yes. Containerizing bitcoind is fine; just mount persistent volumes for your data directory and wallet files.


• What if my commands don’t match? Check your Bitcoin Core version. Some RPCs evolve. Pin a version or read the matching docs: Core RPC docs.


• How do I avoid messing up RPC auth? Keep it simple with cookie auth (default) or set rpcuser/rpcpassword in bitcoin.conf and confirm your datadir paths.

Keep your momentum

Hands-on repetition sticks. Research backs this up: active learning improves outcomes in STEM classes (Freeman et al., PNAS), and retrieval practice beats rereading (Karpicke & Blunt, Science).

Here’s how I keep progress steady:

• Keep a “lab log.” After each session, write what you ran and why. Copy the exact bitcoin-cli commands and outcomes. You’ll thank yourself later.


• Pin your toolchain. Lock your Bitcoin Core version so examples don’t drift. Note it in your repo’s README.


• Automate small wins. Turn repeated commands into a shell script. Even a 15-line script builds muscle memory.


• Ask good questions. If you’re stuck, search or post on Bitcoin StackExchange with the exact command, error, and version.

Your first mini-project (testnet or regtest):

• Create a new wallet: createwallet


• Craft a PSBT for a small send: walletcreatefundedpsbt


• Review inputs/outputs and fees: decodepsbt


• Sign it: walletprocesspsbt (repeat if multisig)


• Finalize and broadcast: finalizepsbt → sendrawtransaction


• Verify confirmation: gettransaction or getrawtransaction

Level-up variant: make it a descriptor-based watch-only wallet, then sign on an offline wallet and broadcast online. That skill translates directly to robust self-custody.

Conclusion and next steps

If you’ve been meaning to get truly comfortable with Bitcoin, this is where you actually start. Keep it simple: run Core on regtest, practice a full send/confirm loop, then repeat on testnet. Build one tiny project, write down what you learned, and stick to a consistent version so you aren’t fighting the tooling.

I’ll post this on cryptolinks.com/news. Bookmark it. If you hit a snag, drop a comment on the post with your command, error, and Core version—I’ll point you in the right direction.

Links to keep handy:
• GitHub guide: Learning Bitcoin from the Command Line
• Bitcoin Core downloads: bitcoincore.org
• RPC reference: Core Docs