search

ECDSA (secp256k1) for Bitcoin Transaction

Now that you have a high-level understanding of BSV transactions, let’s look more closely at the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve. This is the algorithm Bitcoin SV uses for key generation, signing, and verification.

While the algorithm itself is standard, there are some subtle differences in its application within BSV.

hashtag
Private and Public Key Generation

The first step in digital signing is creating a private–public key pair.

Equation:

Public Key = Private Key × Base Point

  • The private key is simply a large random integer.

  • The base point is a special point on the elliptic curve that generates the entire cyclic group when combined repeatedly.

  • The public key is a point on the curve, represented with both x and y coordinates.

A private key is a 256-bit random number. Wallets usually encode it into WIF (Wallet Import Format) for easier handling.

hashtag
Public Key Representation

Once the private key is created, the public key is derived using the equation above.

  • Compressed format (33 bytes): Stores the x-coordinate plus a prefix indicating whether y is odd or even.

  • Uncompressed format (65 bytes): Stores both x and y coordinates explicitly.

Most wallets use the compressed form in practice.

hashtag
Best Practices for Wallets

Wallets follow two important practices for security, privacy, and usability:

  1. Security & Privacy:

    • A new key pair is generated for each transaction.

    • This prevents private key reuse (which could expose multiple transactions if compromised).

    • It also avoids easy traceability of funds across transactions.

  2. Usability:

    • Requiring backups for every new key pair would be inconvenient.

    • To solve this, wallets use Hierarchical Deterministic (HD) keys:

      • All keys are derived from a single seed key.

      • The seed can be backed up once, instead of after every transaction.

      • The seed is often encoded into a word list (mnemonic phrase), easier to manage than a long hex string.

hashtag
Message Signing and Verification in BSV

In BSV, digital signatures are always part of a transaction script:

  • Inputs contain an unlocking script (scriptSig) → includes the signature and public key.

  • Outputs contain a locking script (scriptPubKey) → includes a public key or a public key hash (created by SHA-256 followed by RIPEMD-160).

[GIF: Unlocking script combining with locking script for verification]

Transactions use a standardized template with these elements. Verification works by combining the unlocking and locking scripts, then evaluating the result as true or false.

Note: For enterprise applications, a signature may sometimes need to be checked directly against a public key before reaching the network. However, applications usually exchange addresses (public key hashes encoded in Base58) rather than raw public keys.

hashtag
Signature Format in BSV

A signature in ECDSA is a pair of integers (r, s). In BSV, signatures follow the [DER, SIGHASH] format:

  1. DER (Distinguished Encoding Rules):

    • Defines how to serialize signatures in binary format.

    • Structure: [header, length, rheader, rlength, r, sheader, slength, s]

    • Example: header = 0x30 (static), rlength = length of r, s = big-endian encoding of s.

  2. SIGHASH (Signature Hash):

    • A flag that tells which parts of the transaction are signed.

    • Options include:

      • SIGHASH_ALL (0x01) → signs all inputs and outputs.

      • SIGHASH_NONE (0x02) → signs all inputs, no outputs.

      • SIGHASH_SINGLE (0x03) → signs inputs and only the output with the same index.

      • Variations with ANYONECANPAY restrict signing to a single input while leaving outputs flexible.

Most transactions use SIGHASH_ALL.

hashtag
Additional Flag: SIGHASH_FORKID

In BSV, all signatures also require SIGHASH_FORKID, which adds 0x40 to the chosen SIGHASH value.

  • Example: SIGHASH_ALL (0x01) becomes 0x41.

hashtag
Key Takeaway

  • Private keys are large random numbers; public keys are derived points on the elliptic curve.

  • Wallets improve security and usability with new key pairs per transaction and HD keys.

  • In BSV, signatures live inside transaction scripts, combining unlocking and locking scripts for verification.

  • The DER format standardizes signatures, while SIGHASH flags control which parts of a transaction are signed.

  • Most transactions use SIGHASH_ALL + FORKID.

PreviousBitcoin (ergo, BSV) TransactionsNextSummary of BSV Transactions

Last updated