Transaction Input (TxIn)

This pair of fields acts as a precise pointer to the Unspent Transaction Output (UTXO) being spent.

• Transaction Hash (txid): The cryptographic hash of the transaction containing the UTXO.
• Output Index (vout): The position (starting from 0) of the specific output within that transaction's outputs list. Together, they uniquely identify the source of the funds, forming the basis of Bitcoin's chain of ownership.

The ScriptSig is the data field that provides the cryptographic proof required to satisfy the spending conditions (the locking script) of the referenced UTXO.

• It typically contains a digital signature and a public key.
• The script is executed alongside the referenced output's locking script. The transaction is only valid if the combined script evaluates to true.
• This mechanism enforces ownership without revealing identities.

A 32-bit field originally intended for transaction replacement (Replace-By-Fee) and relative timelocks.

• Default value: 0xFFFFFFFF (4294967295) indicates the input is final and cannot be replaced.
• nSequence < 0xFFFFFFFF: Can enable Relative Timelocks (CHECKSEQUENCEVERIFY), requiring a specific number of blocks or time to pass after the input's confirmation before it can be spent.
• It is a critical component for advanced contract protocols like payment channels.

Introduced with the Segregated Witness (SegWit) upgrade, witness data is moved outside the traditional input structure to a separate field, solving transaction malleability.

• Contains the signature and other witness elements (like public keys) previously in the ScriptSig.
• Witness data is not part of the transaction ID hash, making the txid immutable.
• Enables more complex scripts (like Taproot) and improves scalability by reducing the effective size of transactions for fee calculation.

The first transaction in every block is the coinbase transaction, which creates new bitcoin. Its input has unique properties:

• Previous Transaction Hash: Set to 32 bytes of zeros (a null hash).
• Output Index: Set to 0xFFFFFFFF (4294967295).
• ScriptSig (Coinbase Data): Contains arbitrary data, including the block height and an extra nonce for mining. It does not spend a UTXO. This special input is the genesis of new currency supply in the system.

For a transaction to be valid, every input must pass a series of checks:

1. Existence & Unspent Check: The referenced UTXO must exist and not already be spent (no double-spend).
2. Script Validation: The input's unlocking script and the UTXO's locking script must execute successfully together.
3. Value Conservation: The sum of the input values must be >= the sum of the output values (the difference is the transaction fee).
4. Signature Verification: All required cryptographic signatures must be valid for the current transaction's data.

The transaction ID (txid) is the cryptographic hash of the previous transaction that created the UTXO being spent. This 32-byte identifier acts as a pointer to the specific output in the blockchain's ledger, allowing the network to locate and verify the source of the funds.

• Purpose: Uniquely identifies the source transaction.
• Format: A 32-byte double SHA-256 hash, typically represented as a 64-character hex string.
• Example: a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d

The output index (vout) is a zero-based integer that specifies which output from the referenced previous transaction is being spent. A single transaction can have multiple outputs, so this index is required to pinpoint the exact UTXO.

• Purpose: Identifies the specific output within the source transaction.
• Value: Typically 0 for the first output, 1 for the second, etc.
• Mechanism: Combined with the txid, it forms a globally unique identifier for a UTXO: txid:vout.

The unlocking script (scriptSig) provides the cryptographic proof that the spender is authorized to consume the referenced UTXO. It contains data like digital signatures and public keys that satisfy the conditions (the locking script) placed on the output.

• Purpose: Provides authorization to spend.
• Content: In a Pay-to-Public-Key-Hash (P2PKH) input, this includes a signature and the full public key.
• Validation: The scriptSig is concatenated with the output's locking script and executed. A result of TRUE validates the spend.

The sequence number is a 4-byte field originally intended for transaction replacement (Replace-by-Fee) and relative timelocks. It allows a transaction to be updated before confirmation.

• Default Value: 0xFFFFFFFF (4294967295) indicates the input is final.
• Relative Timelocks: A value with the most significant bit cleared (< 0x80000000) can encode a relative lock-time (e.g., 1000 blocks).
• Mechanism: The input cannot be spent until the specified sequence delay has passed relative to the confirmation of the output it spends.

For Segregated Witness (SegWit) inputs, signature and public key data are moved from the scriptSig to a separate witness field. This reduces the transaction's size for fee calculation and enables script versioning.

• Purpose: Stores witness data (signatures, etc.) separately.
• Location: In a separate data structure, not in the traditional input.
• Impact: Lowers transaction weight, fixing transaction malleability and enabling scaling solutions like the Lightning Network.

The combination of the Previous Transaction Hash (txid) and the Output Index (vout) is formally known as an outpoint. This pair is the fundamental reference to a specific, spendable UTXO on the blockchain.

• Definition: A unique pointer to a blockchain UTXO.
• Uniqueness: Guarantees no double-spend, as each UTXO can only be referenced as an input once.
• Database Key: In a node's UTXO set, the outpoint is often used as the primary key to track unspent outputs.

The primary security mechanism for a TxIn is the digital signature contained in its scriptSig (Bitcoin) or witness (SegWit). This proves ownership of the referenced UTXO. A critical vulnerability occurs if:

• The signature is malformed or invalid.
• The signing logic has a bug, allowing a signature to be replayed.
• The signed data (sighash) does not commit to all critical parts of the transaction, enabling transaction malleability.

A TxIn references a specific, unspent transaction output (UTXO). The core security of the blockchain relies on the consensus mechanism preventing the same UTXO from being spent twice. Key attacks include:

• Race Attacks: Broadcasting two conflicting transactions simultaneously.
• Finney Attacks: A miner including a double-spend in a block they mine. Security depends on waiting for sufficient block confirmations before considering a spend final.

For non-standard transactions (e.g., multisig, timelocks), the unlocking script in the TxIn must satisfy the conditions in the referenced output's locking script. Security risks include:

• Script injection: Maliciously crafted data in the input script could exploit bugs in a node's script interpreter.
• Logic flaws: Incorrectly constructed conditions in the input script could allow unauthorized unlocking.
• Resource exhaustion: Overly complex script validation could be used in a Denial-of-Service (DoS) attack.

TxIns are visible in the mempool before confirmation. This exposes transactions to several attacks:

• Fee Sniping: A miner replaces a low-fee transaction by double-spending its inputs with a higher-fee transaction, stealing the fee.
• Mempool Griefing: An attacker broadcasts a transaction spending the same UTXOs as a victim's pending transaction, causing conflicts and delays. Using Replace-By-Fee (RBF) or Child-Pays-For-Parent (CPFP) can mitigate some risks but introduces other trade-offs.

The security of a TxIn ultimately depends on the security of the private keys used to create its signatures. Critical considerations for wallet software:

• Key Generation: Must use cryptographically secure random number generators.
• Signing Environment: Private keys should never be exposed to untrusted environments (e.g., web browsers without proper isolation).
• Path Derivation: In HD Wallets, ensuring the derivation path is secure and deterministic. A compromised key renders all UTXOs it controls vulnerable.

A TxIn inherits the security properties of the UTXO it spends. If the originating transaction was insecure, the input may be too. Examples:

• Spending from a coinbase transaction requires waiting for 100 confirmations on Bitcoin to mitigate the risk of a chain reorganization.
• Spending from an output that was itself received in a double-spend attack is inherently invalid.
• The scriptPubKey of the spent output defines the security model (e.g., multisig thresholds, hash preimage requirements).