Witness Data

Anna previously received Bitcoin and now wants to pay Peter with it. The earlier payment created an output: a record of an amount and the conditions for spending it later. The new transaction refers to that output through an input. Simply claiming the coins belong to Anna is not enough. For an ordinary payment, her wallet creates a signature that can be checked without revealing her private key. A wallet is an application or device for receiving and sending bitcoin. A private key is a secret numerical value used to create such a signature. With SegWit, such verification data is supplied as the input’s witness. A signature being present does not yet mean it is correct. [1] [4] [5]

Think of the difference between “present a valid credential” and the credential actually presented. Bitcoin has no human adjudicator: rules check the relationship. The witness program is part of the condition recorded in the earlier output; its version determines how it is evaluated. The new spending transaction supplies the witness. Technically, this is an ordered list of data items for each input. It is not automatically an executable program or a copy of all unspent coins. [1] [7]

Witness can reveal a signature, a public key or the script used, a program describing spending conditions. A public key is used to verify signatures and does not need to be kept secret. It is not an encrypted mailbox. Your private key stays with you: you use it to sign, rather than sending it to the network in place of the signature. Neither witness nor a published signature replaces a Seed Phrase, the words used to recover a wallet. If you lose your keys and backup, the public payment history alone cannot restore your ability to sign further transfers. [1] [3] [4]

A block explorer is an application for looking up transactions and blocks on a particular network. An explorer may display wtxid alongside txid. Both are hashes, short fingerprints calculated from an exact data encoding by applying SHA-256 twice. txid uses the encoding without witness; wtxid uses the complete encoding with witness. They are not recipient addresses or two different payments. If a transaction has no witness, it uses the original encoding and the identifiers are equal. In Bitcoin Core v29.0, decoderawtransaction reports the full identifier in hash; an input’s witness data appears in txinwitness. [1] [7] [8]

Another transaction can refer to an earlier one before it is confirmed. If someone could change the earlier identifier merely by altering signature data, that reference would no longer match. Changing witness alone does not change txid, which helps protocols using dependent transactions, such as Lightning Network. This does not promise that the entire transaction is immutable. Other fields or older non-SegWit inputs can still affect txid, and an altered witness must still meet its applicable verification rules. [1] [6]

Witness travels with the full transaction encoding and becomes part of block data when included. It is not free storage outside the chain. A byte added by witness serialization contributes 1 WU to weight, compared with 4 WU for a base byte; WU means weight unit. A Full Node independently checks the rules and needs the relevant data to validate spending. A smaller weight contribution neither permits skipping required checks nor means that the data occupies no storage. [1] [7]

In the older format, spending evidence went into scriptSig. Native SegWit version 0 requires this field to be empty: the needed evidence is in witness. There is also a P2SH-wrapped form, using the older way of paying to a condition identified by a script hash. Here scriptSig must contain exactly the push of the corresponding witness program, not arbitrary additional instructions. Spending evidence remains in witness. The same purpose can therefore have different encodings; a field’s name alone is not enough to interpret it. [1] [5]

P2WPKH supplies a signature and public key. The node checks that the key’s hash matches the original condition and that the signature is valid. P2WSH supports a condition identified by a whole script’s hash. Its last witness item is witnessScript, whose hash must match the output’s program. Earlier items provide initial data for executing the script, such as signatures. BIP 143 specifies how the signed message is assembled for this version, including the value of the output being spent. Successfully reading the data alone does not prove the conditions are met. [1] [2] [5]

Taproot uses native witness version 1 and allows key-path or script-path spending. When selecting the path, any annex, a special supplementary field, is first set aside; its data still counts toward weight and is covered by the signature. One remaining item is interpreted as the key-path signature. The script path reveals the script used and a control block: data proving its connection to the earlier output, not a new blockchain block. Any preceding items supply data to the script. Version 0 rules cannot simply be carried over to this case. [3] [5]

A cryptographic commitment is a fingerprint that binds data to its specific contents. When a witness commitment is required, BIP 141 ties the evidence to the rest of the block through the Coinbase Transaction, the first transaction used for the miner’s reward. A tree of wtxid hashes produces a root summarising the included data. The reward transaction uses a zero wtxid in this tree. The root is combined with a reserved 32-byte value and hashed twice to produce a commitment recorded in its output. If no transaction has witness, the commitment is optional. This links public evidence together; it is neither a key backup nor a replacement for verification itself. [1]