DEV Community: Muhammad Ademola

ECDSA - The Math That Only Goes One Way

Muhammad Ademola — Thu, 21 May 2026 10:27:43 +0000

Bitcoin gives you the ability to generate a key pair, a public key and a private key. You generate a signature with your private key, and that signature is what you attach to a transaction. It proves to any third party that the transaction was authorized by you, the rightful owner, without you ever having to reveal the key itself.

But what is actually happening underneath that process?

ECDSA — Elliptic Curve Digital Signature Algorithm

The mechanism behind all of it is ECDSA — a digital signature system built on elliptic curve cryptography.

An elliptic curve is defined by the equation y² = x³ + ax + b. Bitcoin fixes the constants at a = 0 and b = 7, which reduces the equation to the one introduced in the last article:

y² = x³ + 7

This is called the secp256k1 curve. Every key, every signature, every verification happens through operations on points that lie on this curve, inside the finite field.

ECDSA handles three things: key creation, signature generation, and signature verification. Each one builds on the last.

Key Creation

A private key is a randomly generated large integer d — chosen from the range 1 to n − 1, where n is the order of the secp256k1 curve. It's a 256-bit number, meaning it's chosen from a space of roughly 2²⁵⁶ possibilities. No one chooses it for you, no server stores it, no institution knows it. It exists only where you keep it.

The public key Q is then derived from it:

Q = d · G

G here is the generator point — a fixed, agreed-upon point on the secp256k1 curve that the Bitcoin network uses. The operation d · G is point multiplication, a one-way operation: the point G is added to itself d times using elliptic curve addition rules, all within the finite field.

Think of your public key as your account details — the address people send funds to. Your private key is your transfer authorization, except unlike a bank PIN, it isn't held by anyone else. Only you.

One-Way Operations — Why You Can't Go Backwards

To understand why reversing Q = d · G is impossible, it helps to start with something more familiar: prime factorization.

It is believed that prime numbers are the fundamental building blocks of all natural numbers — that every positive integer greater than 1 is a product of primes. Take 504 as an example:

504 = 2 · 2 · 2 · 3 · 3 · 7

Multiplying those factors together to get 504 is trivial. But hand someone 504 and ask them to recover the prime factors, and the only known approach is to repeatedly divide by every prime smaller than the number. As the numbers scale up to hundreds of digits, this becomes computationally infeasible. No shortcut is known to exist aside this naive way.

Point multiplication on an elliptic curve works on the same principle, and this amongst other reasons guarantees security. Computing Q = d · G given d is fast. But given only Q and G — recovering d — is the elliptic curve discrete logarithm problem. There is no known efficient algorithm to reverse it.

This one-way property is the entire basis of Bitcoin's security. But what does this actually mean for the signature that ECDSA produces?

Digital signature, like handwritten signature allows a receiver to convince a third party that a document came from a specific sender. But unlike a handwritten signature, a digital one cannot be forged, copied, or lifted from one document and placed on another.

More critically, a handwritten signature at the bottom of a document doesn't guarantee the contents above it weren't altered after signing. The signature and the message are separate things.

A digital signature fixes both problems. It cannot be forged - producing a valid signature requires the private key, which only the owner holds. And it is bound to the exact content of the message, if a single character in the transaction changes after signing, the signature becomes invalid. It doesn't just sign a document. It signs every bit of it.

Bitcoin’s Secret Math: Modular Arithmetic & Finite Fields

Muhammad Ademola — Thu, 14 May 2026 23:07:16 +0000

Of the major problems Bitcoin set out to solve, one was the risk of centralization — and that’s part of what has made it one of the quickest growing currency today. Another was the issue of security.
Both of these are deeply tied to cryptography, the science of securing information using mathematical algorithms.
At the heart of the cryptography that powers Bitcoin are modular arithmetic and finite field.

Modular Arithmetic

Simpler than it sounds, it’s something you already use every day whenever you read a clock.

Modular arithmetic deals with the remainder left after division.

An analog clock never shows 13, 14, or 30. It counts from 1 to 12, then wraps back around. A digital clock goes up to 24, but if your clock reads 23:00 and you want to convert it to a 12-hour format, you apply modulo 12. Here’s the idea: numbers wrap around once they hit a limit. In this case: 23 mod 12 = 11 So, 23:00 becomes 11 PM.

No matter how large the number gets, modulo arithmetic always brings it back within a fixed range. Bitcoin leans on this heavily — the specific modulus it uses is a 256-bit prime number: p = 2²⁵⁶ − 2³² − 977, chosen for both its size and its mathematical properties. Every arithmetic operation in Bitcoin's cryptography runs against this prime, ensuring results stay within a predictable, bounded space.

Finite Fields

A finite field is a set with a finite number of elements that supports four operations — addition, subtraction, multiplication, and division (except by zero) — while always producing a result that still remains within the set.
This property is known as closure.
For example, if your finite field is {0, 1, 2, 3, 4, 5, 6} (a field of order 7), then:

3 + 5 = 8 → 8 mod 7 = 1  ✅ (still inside the set)
6 * 3 = 18 → 18 mod 7 = 4  ✅ (still inside the set)

But there’s one important condition: the number of elements in the field must be a prime number, or a power of a prime.
This guarantees that every element (aside from zero) has a multiplicative inverse, which makes division possible without breaking out of the field.

In Bitcoin's case, the finite field has exactly p elements — that same 256-bit prime — giving it an astronomically large but still finite and well-structured space to operate in. Division inside this field works through something called Fermat's Little Theorem: instead of dividing by a, Bitcoin computes a^(p−2) mod p, which gives the same result while staying entirely within the field.

Why does Bitcoin care?

Bitcoin’s security is built on elliptic curve cryptography — a branch of cryptography where private keys, public keys, and signatures are generated through mathematical operations on points on a curve. The specific curve Bitcoin uses is called secp256k1, defined by the equation y² = x³ + 7, and all point operations on it happen inside the finite field described above.

The challenge is that, without boundaries, these operations would produce numbers that grow astronomically large, very quickly.

Finite fields solve this problem. By performing elliptic curve operations inside a finite field using modular arithmetic, Bitcoin keeps every result bounded within a fixed range. A private key is simply a random integer between 1 and the curve's order n, another large prime, close in size to p. The corresponding public key is derived by multiplying a fixed starting point G (the generator point) by that private key, entirely using modular arithmetic.

In practice, this means the numbers never grow beyond a fixed size (256 bits for bitcoin), making the cryptography both secure and computationally feasible.

Finite fields are a major reason Bitcoin’s cryptography can actually work efficiently in the real world.

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.