Cryptography and Security

A digital signature is a cryptographic value that allows others to verify that a message was authorized using a particular private key. Verification uses the corresponding public key and detects changes to the signed information. In cryptocurrency systems, signatures help satisfy spending conditions without revealing the private key itself. Bitcoin uses signature schemes including ECDSA and Schnorr, depending on the output and spending arrangement. A signature is not encryption: it normally does not conceal the transaction's contents. Nor does it automatically establish the signer's real-world identity, because the relationship between a person and a key may be unknown. Wallet prompts deserve careful review because a valid signature can authorize an unwanted transaction just as effectively as an intended one. Security depends on the signing algorithm, correct implementation, protected keys, and a clear understanding of the message or transaction being approved.

Sources: csrc.nist.gov · github.com

Double spending is an attempt to use the same digital funds in conflicting transactions. Bitcoin prevents both transactions from being valid within one accepted history when they try to spend the same previously unspent output. Nodes check that an output exists, that its spending conditions are met, and that it has not already been consumed. However, conflicting transactions can circulate before confirmation, and competing blockchain branches can temporarily include different spends. Proof of work and confirmation depth make replacing an accepted history progressively more difficult under the network's security assumptions. Merely seeing a transaction broadcast is therefore weaker evidence than verifying its inclusion and subsequent confirmations. Double spending does not require copying a physical coin or learning someone else's private key; it concerns disagreement over which authorized spend becomes part of the ledger that recipients ultimately rely on.

Sources: developer.bitcoin.org · developer.bitcoin.org

A fifty-one percent attack is a commonly used name for an attack involving control of a majority of a proof-of-work network's effective mining power. An attacker with sustained majority hash rate can seek to outpace honest miners, reorganize recent history, censor transactions, or replace the attacker's own payments with conflicting spends. The label is shorthand rather than a precise boundary between possible and impossible attacks: outcomes also depend on duration, confirmation depth, coordination, and chance. Majority mining power does not allow an attacker to forge other users' signatures, spend arbitrary outputs, or create coins beyond consensus limits accepted by full nodes. The attack concerns selection among valid histories, not unlimited authority over validity rules. Mining concentration therefore matters, but counting mining devices or nodes is not equivalent to measuring control of the work used to extend the chain.

Sources: bitcoin.org · developer.bitcoin.org

A cryptographic hash function transforms input data into a fixed-length output called a hash or digest. The same input produces the same digest, while a small change normally produces a very different result. Security properties include making it impractical to recover a suitable input from its digest or find distinct inputs with the same digest under the function's intended assumptions. A hash is not encrypted text and is not designed to be decrypted with a secret key. Cryptocurrency systems use hashes for data commitments, identifiers, Merkle trees, and proof-of-work calculations. These uses do not make a hash a guarantee that the original data is truthful; it can commit just as effectively to inaccurate information. Its role is to help detect changes or prove relationships between data. Different hash algorithms have different designs, output lengths, and security characteristics, so their names are not interchangeable.

Sources: csrc.nist.gov

A Merkle tree is a data structure that combines hashes in successive layers until they produce a single root commitment. Bitcoin uses a Merkle root in the block header to commit to the block's transaction identifiers. A Merkle proof can demonstrate that a particular transaction belongs to the committed set using a relatively small collection of intermediate hashes, without presenting every other transaction in the block. Changing a committed item changes the path to the root, making the alteration detectable under the hash function's security assumptions. However, inclusion is not the same as full validity. A proof that a transaction appears in a block does not independently establish that all its inputs were spendable or that the block belongs to the best valid chain. Merkle structures also appear in other cryptocurrency applications, where the meaning of a proved item depends on what the tree commits to.

Sources: bitcoincore.org · developer.bitcoin.org

A private key is secret cryptographic information used to perform operations such as creating digital signatures. In a typical cryptocurrency wallet, control of the relevant private key allows its holder to authorize spending when the remaining output or contract conditions are satisfied. The associated public key can be shared for verification without revealing the private key under the cryptographic system's security assumptions. A private key is not the same as a receiving address, transaction identifier, account password, or recovery phrase, although a recovery phrase may recreate many private keys. Losing the necessary keys without a usable backup can make funds inaccessible. Exposing them can let someone else authorize transactions without obtaining a separate account login. Security therefore involves generation quality, protected storage, reliable backups, and careful signing procedures. No legitimate payment recipient needs a sender's private key simply to receive cryptocurrency.

Sources: csrc.nist.gov · developer.bitcoin.org

Proof of reserves is a process intended to provide evidence about assets held by a cryptocurrency custodian relative to specified customer balances. Implementations may combine demonstrations of control over blockchain addresses with a Merkle-tree commitment that lets customers check whether their balances were included in a reported snapshot. The exact scope matters: evidence of assets alone does not establish that all liabilities were included, that assets are unencumbered, or that the operator can meet every future withdrawal. A snapshot also does not continuously verify the institution's condition between reporting dates. Different reports use different procedures, assurance levels, and asset coverage, so the phrase should not be treated as a uniform certification. Users examining a report should distinguish verifiable inclusion from broader claims about solvency, ownership, accounting controls, and operational security. Transparency tools can be useful while still leaving important questions outside their demonstrated scope.

Sources: kraken.com

A public key is the shareable component of an asymmetric cryptographic key pair. In cryptocurrency signature systems, it lets others check that a signature was produced using the corresponding private key without revealing that private key. Bitcoin derives public keys through elliptic-curve operations and uses them in spending conditions, sometimes directly and sometimes through commitments or hashes. A public key is not always identical to a receiving address, because addresses can encode different kinds of output information. Knowing an ordinary public key does not normally provide spending authority, but publishing it can still reveal relationships between transactions or wallet activity. Extended public keys used by hierarchical wallets can expose considerably more information than a single key. Verification also establishes a relationship to a cryptographic key, not necessarily to a named individual. Real-world identity requires additional evidence outside the key's mathematical properties.

Sources: csrc.nist.gov · github.com

A Schnorr signature is a digital signature produced using a Schnorr-style cryptographic construction. Bitcoin's BIP-340 specifies a particular version over the secp256k1 elliptic curve, including its encoding and verification rules. It forms part of the signing capabilities used with Taproot. The construction has mathematical properties that can support efficient verification and carefully designed multiparty signing protocols, but ordinary signatures do not automatically combine themselves or make every multisignature wallet private. Additional protocols must handle participant coordination and security correctly. BIP-340 signatures use a 64-byte core encoding, distinct from some other Bitcoin signature representations. As with other signature schemes, security depends on protecting private keys and implementing nonce generation and signing correctly. A Schnorr signature proves authorization under a key and a defined message; it does not encrypt transaction contents, identify the signer as a person, or prove the payment's economic purpose.

Sources: github.com

SHA-256 is a cryptographic hash algorithm in the SHA-2 family that produces a 256-bit digest. The output is commonly displayed as 64 hexadecimal characters. Bitcoin uses two successive SHA-256 operations when hashing block headers for proof of work, and related hashing constructions appear elsewhere in its data structures. The algorithm maps input data to a digest; it does not encrypt the data or provide a decryption operation. Miners do not break SHA-256 when they discover a block. They search through varying candidate headers until a resulting hash meets the required numerical target. The ability to verify a result quickly is different from the difficulty of finding one. SHA-256 should also be distinguished from the elliptic-curve signature algorithms that authorize Bitcoin spending. Hashing and digital signatures serve complementary roles, but possessing a transaction hash does not grant access to its funds.

Sources: csrc.nist.gov · developer.bitcoin.org

A zero-knowledge proof is a cryptographic method that lets a prover demonstrate that a statement is true without revealing the secret information used to establish it, beyond what the statement itself discloses. For example, a system can prove knowledge of a value satisfying specified conditions while keeping that value hidden. Blockchain applications use related proof systems for privacy and for verifying computations performed elsewhere. These are different goals: using a validity proof does not automatically make transaction amounts, identities, or application activity private. The proof also establishes only the precisely encoded statement, not the honesty of every external input or the quality of the broader system. Designs differ in proof size, verification cost, setup assumptions, and computational requirements. Zero-knowledge technology should therefore be evaluated through its actual guarantees and implementation rather than treated as a universal synonym for anonymity, correctness, or unlimited scalability.

Sources: ethereum.org