In this article, we’ll look at one of the popular addressing methods on the Bitcoin network, which dates back to 2011. P2PKH (Pay To PubKey Hash) is one of the most common addressing methods in Bitcoin. It’s used to send bitcoins to a regular address (beginning with the letters 1 or 3).

Here’s Why Bitcoin Users Are Not Abandoning P2PKH Transactions

This article aims to provide a detailed understanding of the most common type of Bitcoin transaction —public-key hashing (P2PKH). To achieve this, we propose the following:

A quick overview of the concept of an unspent transaction output (UTXO) and how a transaction is formed.
A breakdown of each part of a P2PKH transaction
An overview of how unlock and lock scripts work in conjunction with spending funds.

A P2PKH transaction is the type most people use to move a certain amount of bitcoin from one address to another, typically through a wallet interface. An example transaction is used to illustrate some of the processes that occur behind the scenes in a typical wallet.

Unspent Transaction Outputs (UTXO)

A very important concept to understand before delving into transaction breakdowns is the unspent transaction output , or UTXO. In a Bitcoin transaction, the UTXO is what is consumed or spent. UTXOs can only be spent once. Once spent, they are called spent transaction outputs .

Spending a UTXO is like using a $20 bill to buy something for $10, but instead of the cashier keeping the $20 bill, they set it on fire and create two new $10 bills out of thin air, keeping one and returning the other to you.

In this analogy, the burned $20 bill started out as a UTXO, but once it was spent, it became the result of the spent transaction, resulting in two new $10 bills, representing two new UTXOs ready to be used in future transactions.

All bitcoins available for consumption on the network are called the UTXO set .

The process of constructing a transaction

Each transaction consists of a version number , input , output , and lock time .

The input data contains the endpoints , sequence number , and unlock script , also called scriptSig .

The output contains the amount spent and the lock script , also called scriptPubKey .

The lock time determines at what time a transaction becomes valid.

Every transaction has at least one input and one output. The input contains logic that informs the network which UTXOs to use (via output points) and proves that it is allowed to use them (via unlock scripts). The output contains logic that informs the network of the conditions under which a future transaction is allowed to use newly minted UTXOs (via lock scripts).

The figure below shows the relationship between a confirmed transaction with spent outputs, confirmed transactions with unspent outputs, and new, unsent transactions.

How P2PKH addressing is decrypted in a Bitcoin transaction — Transactional relationships

Steps to create a transaction

The steps to create a P2PKH transaction are as follows:

Identify a previous transaction containing UTXOs you control (only Bitcoin you already own).
Create initial entry points for the new transaction to determine the UTXO of the previous transaction to spend.
Create the output of the new transaction such that the locking script contains the conditions under which the newly created UTXOs can be spent/unlocked by the next transaction.
Create an unlock script that matches the conditions set by the output lock script of the previous transaction. It contains the recipient’s signature and is created at the very last stage, but is largely part of the input and is physically placed in the middle of the transaction.

Introduction to Serialized Transactions

A complete signed P2PKH Bitcoin transaction is discussed in detail below.

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

This transaction was randomly selected on Blockchain.com and can be viewed here ( raw values ).

With a UTXO value of 17,373,066, address 19iy8HKpG5EbsqB2GUNVPUDbQxiTrPXpsx sends 390,582 satoshi to address 1JKRgG4F7k1b7PbAhQ7heEuV5aTJDpK9TS and receives 16,932,484 satoshi back as change. The remaining difference between the inputs and outputs is given to the miner as a transaction processing fee.

Version number

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

The version number is four bytes long and is expressed as a hexadecimal value in little-endian format.

There are two types of versions. Version 01 indicates no relative time locking. Version 02 indicates that relative time locking may exist. Version 02 was introduced in BIP0068 , which added OP_CHECKSEQUENCEVERIFY, along with BIP0112 , which updated it. Version 02 is used in conjunction with a sequence number, which is described below.

Transaction example – version 01.

Entering a transaction

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

Each transaction input points to the output of the previous transaction. If the unlock scenario in the current transaction’s input matches the conditions set by the previous transaction’s output scenario, the UTXO held by the previous transaction can be spent.

Number of cons

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

The next one to nine bytes in the transaction input data define the number of included minuses and are of type VarInt. There is always one minus for each consumed UTXO.

Example of a transaction with 1 UTXO input.

Transaction

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

Each minus is a reference to the hash of the previous transaction and a corresponding index pointing to the exact amount spent UTXO.

The first 32 bytes of the negative decimal point are a reference to the hash of the previous transaction, containing UTXO, used in little-endian format. For example, the hash of the previous transaction is:

486c887f2378feb1ea3cdc054cb7b6722e632ab1edac962a00723ea0240f2e9c

and when included at the origin of a transaction, it is expressed in little-endian format :

01 9c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48 01000000

The last four bytes of the outpoint specify the index of the UTXOprevious transaction being used. It also has a hexadecimal value in little-endian format.

019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48 01000000

The transaction containing the spendables UTXOcan be viewed here ( raw values ) . The first entry in «out»the previous transaction’s key shows that the current transaction uses UTXO, which contains the decimal value 17,373,066 satoshis. Note that the current transaction does not explicitly include UTXOthe amount of 17,373,066 satoshis, but only references it through the contents of the output point.

Unlock script

The unlock script, also called scriptSig, contains the stack script (signature) and the redeem script (public key) of the user making the transaction and receiving the funds.

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

Unlocking the script length

6a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b330701

The first 1–9 bytes have a type VarIntand define the number of subsequent bytes that make up the stack script and the cancel script. In this case, the first byte (0x6a)declares that the next 106 bytes are pushed onto the stack (discussed below) .

Stack Script (Signature)

Stack Script Signature

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

The stack script contains the signature of the person submitting the transaction to the network, and sighash. This is part of the proof that the user (the signer) is authorized to spend the UTXO, pointed to by the transaction’s output.

The first 1-9 bytes are the type VarIntand determine the number of subsequent bytes that make up the signature.

47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380а01б330701

In this case, the first byte(0x47)declares that the next 71 bytes are a signature and sighash. The signature is created based on the user’s private key.

47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380а01б330701

The signature can be broken down as follows:

30 – Signature markerTHE
44— states that the signature length is 68 bytes .
02 – value marker R
20 — declare that the valueRhas a length of 32 bytes
3da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9 — meaning R
02 – value marker S
20 — declare the valueS32 bytes long
02d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307 – meaningS

Finally, a single byte representing sighashthe transaction is appended to the signature P2PKHand sighashcan be one of the following:

SIGHASH_ALL (0x01):the signature is applied to all inputs and outputs, this is most common for transactionsP2PKH.
SIGHASH_SINGLE (0x03): the signature applies to all inputs and one output.
SIGHASH_ANYONECANPAYin combination withSIGHASH_ALL (0x81): signature applies to one input and all outputs.
SIGHASH_ANYONECANPAYin combination withSIGHASH_SINGLE (ox83): the signature applies to one input and one output.

47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b330701

Redeem Script – Activate a script

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

The redemption script contains the conditions set by the script PubKey. In transactions, P2PKHthe redemption script is simply the user’s (signer’s) public key .

The first 1–9 bytes of the redemption script type VarIntdetermine the number of subsequent bytes that make up hashthe public key.

2102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34e

In this case, the first byte(0x21)declares that the next 33 bytes are a hash of the user’s public key. The hashing algorithm is HASH160, which is followed SHA256by a hash of RIPEMD160. The public key is derived from the user’s private key.

2102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34e

Sequence Number – Sequence Number (nSequence)

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

nSequenceis four bytes long and is expressed as a hexadecimal value in little-endian format.

Initially, nSequence existed so that a user could replace a previously submitted unconfirmed transaction with a new transaction using the same input but a higher nSequence value. However, this didn’t work in practice, as miners have no incentive to confirm transactions with a higher nSequence value nSequence, preferring instead to confirm transactions with a higher fee.

Originally, nSequence was only used for shutdown nLockTime (discussed below) . If nSequence is set to 0xFFFFFFFF, it nLockTimeis ignored.

BIP0125 introduced a new use for nSequence, using it to signal RBFif its value is less than 0xFFFFFFFE. An example of when this is desirable is when a user sends their transaction to the network but realizes the fee is insufficient and wants to resend the transaction with a higher fee.

Transactions often default to nSequence 0xFFFFFFFE, discarding RBFand allowing nLockTime. To use nLockTimeand subscribe to RBF, typically nSequenceset to 0xFFFFFFFD.

BIP0068 was repurposed to allow for relative time locking. This functionality is implemented if nSequence and only if the transaction has a version 02.

nSequence— is essentially the amount of time that must pass for a transaction to be confirmed and is specified by the block height or in units of 2⁹ (512)seconds from the current time. A transaction locked by relative time is invalid until (nSequence * 521 seconds) or (nSequence * number of blocks) of its parent transactions are confirmed.

Eighteen of the 32 bits of the value nSequenceare used to lock the relative time. The remaining 14 bits are reserved for future updates, as shown below:

A detailed explanation of time locks can be found here . ( Bitcoin’s Time Locks )

An example of a transaction is a version 01with a serial number 0xFFFFFFF, a refusal from RBFand a use of nLockTime.

Transaction outputs

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

Transaction outputs contain output scenarios and the amount controlled by these scenarios. A transaction most often has more than one output. In a typical P2PKH transaction, an output contains a spend output and a change output. Each output contains the amount consumed in satoshis and the conditions that must be met to spend it.

Number of outputs

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

The first byte of a transaction output specifies the number of outputs and is of type VarInt.

This transaction has two outputs: one for the amount spent from the incoming UTXOand one for the change amount.

Exits

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

The first 16 bytes of each output represent the amount consumed according to the unlock (detailed below) , and are expressed as a hexadecimal value in little-endian format.

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

The second part of the output is a variable-length value called a lock script, or equivalently, scriptPubKey. The lock script defines the conditions under which the specified data can be used. In other words, it allows only the user with the correct signature to access the funds.

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

This transaction P2PKHconsumes UTXO, previously controlled by address 19iy8HKpG5EbsqB2GUNVPUDbQxiTrPXpsx, with a value of 17,373,066 satoshi. The first output of this transaction creates a new one UTXOworth 390,582 satoshi, which is controlled by the receiving address 1JKRgG4F7k1b7PbAhQ7heEuV5aTJDpK9TS.

The second output of this transaction creates a new UTXOoutput worth 16,932,484 satoshi, controlled by the original sending address 19iy8HKpG5EbsqB2GUNVPUDbQxiTrPXpsx. This is the “change” from the transaction.

First conclusion

The first output amount in decimal value is 390,582 satoshi (hexadecimal 0x0005F5B6).

b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac

The blocking script is extracted from the address of the user receiving the funds.

b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac

Blocking script— it’s just a script, a piece of code that tells the network how to spend that amount. The code is written in Bitcoin Script, which is a stack-based language based on reverse Polish notation (RPN RPN), which is Turing-incomplete. It’s a very primitive language that essentially just pops values from the stack and performs operations on the elements using a series of commands called OP_CODES .

The blocking script is extracted from the recipient’s address and is broken down as follows:

19– (25 bytes) length of the next unlock script.
76— OP_DUP: Duplicates the top element of the stack.
a9— OP_HASH160: The input data is hashed twice: first with SHA-256 and then with RIPEMD-160.
14– (20 bytes) the length of the next public key hash.
88— OP_EQUALVERIFY: Returns 1 if the inputs are exactly equal, 0 otherwise. OP_VERIFY is then run, which fails and marks the transaction as invalid if the top-stack value is false.
and— OP_CHECKSIG: All output, input, and script data are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If so, 1 is returned; otherwise, 0.
bdf63990d6dc33d705b756e13dd135466c06b3b5– hash of the recipient’s public key.

Second conclusion

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

The second output value is 16,932,484 satoshi.

845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac

The lock script for the second withdrawal sends 16,932,484 satoshi back to the sender. This is a sender change.

845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac

The blocking scenario can be analyzed as follows.

19– (25 bytes) length of the next unlock script.
76— OP_DUP: Duplicates the top element of the stack.
a9— OP_HASH160: The input data is hashed twice: first with SHA-256 and then with RIPEMD-160.
14– (20 bytes) the length of the next public key hash.
88— OP_EQUALVERIFY: Returns 1 if the inputs are exactly equal, 0 otherwise. OP_VERIFY is then run, which fails and marks the transaction as invalid if the top-stack value is false.
and— OP_CHECKSIG: All output, input, and script data are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If so, 1 is returned; otherwise, 0.
5fb0e9755a3424efd2ba0587d20b1e98ee29814a– hash of the recipient’s public key.

19 – (25 bytes) length of the next unlock script.

Transfer fee

The transaction fee received by the miner is the difference between the total input and output amounts. In the transaction example, the miner’s fee is calculated as:

miner_fee = (input_amount) - (spend_amount +change_amount) 
miner_fee = (17373066) - (390582 + 16932484) 
miner_fee = 50000 satoshi

Lock Time (nLockTime)

01000000019c2e0f24a03e72002a96acedb12a632e72b6b74c05dc3ceab1fe78237f886c48010000006a47304402203da9d487be5302a6d69e02a861acff1da472885e43d7528ed9b1b537a8e2cac9022002d1bca03a1e9715a99971bafe3b1852b7a4f0168281cbd27a220380a01b3307012102c9950c622494c2e9ff5a003e33b690fe4832477d32c2d256c67eab8bf613b34effffffff02b6f50500000000001976a914bdf63990d6dc33d705b756e13dd135466c06b3b588ac845e0201000000001976a9145fb0e9755a3424efd2ba0587d20b1e98ee29814a88ac00000000

nLockTimeEnables the use of absolute time locks. They are four bytes long and expressed as a hexadecimal value in little-endian format. An absolute time lock allows a user to submit a transaction to the network that will remain invalid until a specified amount of time has passed. This nLockTimeis essentially a target time for transaction confirmation and is specified by the block number or epoch time.

If nLockTime0, there is no time lock. The transaction becomes valid immediately.

If nLockTimegreater than 0 and less than 500,000,000, the absolute block time is measured in units of the number of blocks.

If nLockTime is greater than or equal to 500,000,000, the absolute lock time is measured in epoch time units.

It is important to note that if nSequence is set to 0xFFFFFFFF, it nLockTimeis completely disabled.

In the transaction example, nLockTimethe value is 0.

Unlocking Bitcoin Script

Below is how the lock and unlock scripts work together to unlock funds in an output P2PKH. Only the values for the first output are shown, but the logic applies to both outputs.

The leftmost column shows the contents of the lock script, the middle column shows the contents of the unlock script, and (remember, Bitcoin Scriptthis is RPNa Forth-like language) the rightmost column shows how the stack is built.

The script is executed as follows:

Push the signature and then the public key onto the stack:

OP_DUP duplicates the top element of the stack, the public key, and pushes it onto the top of the stack:

OP_HASH160 pops the top element from the stack and performs a SHA256 hash on it, then RIPEMD160:

<pubkey hash> = RIPEMD160(SHA256(public key))

It then pushes this hash onto the top of the stack:

The public key hash is placed on the top of the stack:

OP_EQUALVERIFYPops the top two elements from the stack and checks their equivalence. If the two public key hashes are not equal, then the recipient attempting to receive the funds provided an invalid public key, either accidentally or intentionally. OP_EQUALVERIFYThis will cause the script to fail, in which case the transaction will be invalid.

Finally, OP_CHECKSIGit pops the top two elements from the stack, which should be the public key and the signature, and checks if the signature is valid for the public key.

If OP_CHECKSIGsuccessful, it pushes 1 onto the stack and the transaction is valid and complete.

If the user has not provided a valid signature for the public key, OP_CHECKSIGpushes 0 onto the stack, indicating that the transaction is invalid.

Conclusion: Bitcoin P2PKH transactions are a core element of the cryptographic ecosystem. They ensure security, reliability, and high efficiency of the entire system. P2PKH transactions can be used to perform a wide range of Bitcoin operations, including sending, receiving, and managing cryptocurrency data. Because this transaction type offers a high level of security, it is one of the most popular in the Bitcoin world.

Useful information for enthusiasts:

[1] YouTube Channel CryptoDeepTech
[2] Telegram Channel CryptoDeepTech
[3] GitHub Repositories CryptoDeepTools
[4] Telegram: ExploitDarlenePRO
[5] YouTube Channel ExploitDarlenePRO
[6] GitHub Repositories Smart Identify
[7] Telegram: Bitcoin ChatGPT
[8] YouTube Channel BitcoinChatGPT
[9] Telegram: Casino ChatGPT
[10] YouTube Channel CasinoChatGPT
[ 11 ] DOCKEYHUNT
[ 12 ] Telegram: DocKeyHunt
[ 13 ] ExploitDarlenePRO.com
[14] DUST ATTACK
[15] Vulnerable Bitcoin Wallets
[16] ATTACKSAFE SOFTWARE
[17] LATTICE ATTACK
[ 18 ] RangeNonce
[19] BitcoinWhosWho
[20] Bitcoin Wallet by Coinbin
[21] POLYNONCE ATTACK

Contact me via Telegram: @ExploitDarlenePRO