users, there is an easier alternative in the form of scanning a QR code, generated by the recipient.

Every type of bitcoin software allows users to create QR codes, which can include the wallet address
to send funds to, as well as the total amount to be paid. If a bitcoin wallet address receives 3 BTC
over a certain period of time and you send 1 BTC over to a friend, the bitcoin transaction will have
one input, the unspent outputs(UTXOs) of the bitcoin transactions through which you received the 3
BTC, and create two different outputs when you send the currency to the friend. The first output will
be the transaction to the friend totaling 1 BTC. The second output will be the change transaction,
which returns the unspent 2 BTC(as UTXO) to your change wallet address.

Sending a bitcoin payment can be denominated in a multitude of satoshi, the smallest increment of
bitcoin transactions lying at 8 decimal points after the period. Each input spends the satoshis paid to
a previous output. Each output then waits as an Unspent Transaction Output (UTXO) until a later
input spends it. When your Bitcoin wallet tells you that you have a 10,000 satoshi balance, it really
means that you have 10,000 satoshis waiting in one or more UTXOs. The value of 1 satoshi can vary
based on the value of a bitcoin in the way it's predicted to rise varyingly or stably until 2140. Whereas
1 satoshi is of insignificant value these days, it could be worth a handful of cents or dollars in the
future if bitcoin adoption becomes a globally accepted mode of payment.

Each transaction is prefixed by a four-byte transaction version number which tells Bitcoin peers and
miners which set of rules to use to validate it. This lets developers create new rules for future
transactions without invalidating previous transactions. An input uses a transaction identifier (txid) and
an output index number (often called vout for output vector) to identify a particular output to be spent.
It also has a signature script which allows it to provide data parameters.

The typical transaction process for bitcoin between two users transacting involves the following steps:
Generating a key pair, creating a public key hash (P2PKH), sharing the public key hash, creating a
P2PKH transaction, broadcasting the transaction, viewing the balance, spending the UTXO and
combining scripts.

Generating a Key Pair: The receiver generates a private/public key pair using the Elliptic Curve Digital
Signature Algorithm (ECDSA) with the secp256k1 curve. The private key is used for signing
transactions, while the corresponding public key will be hashed for address creation.

Creating a Public Key Hash (P2PKH): The receiver cryptographically hashes the public key to create
a public key hash. The hash obfuscates the public key, shortens it for convenience, and enhances
security.

Sharing the Public Key Hash: The receiver sends the public key hash to the sender, typically encoded
as a Bitcoin address. This address includes: A version number, the hash itself and an error-detection
checksum. It enables the sender to know where to send the satoshis securely.

Creating a P2PKH Transaction: The sender decodes the receiver’s Bitcoin address to extract the
public key hash. The sender creates a transaction with an output that includes: The amount (in
satoshis) to send. A script (pubkey script or scriptPubKey) that specifies the conditions to spend
these satoshis (i.e., control of the private key corresponding to the receiver’s public key hash). This
ensures that only the receiver can spend the funds.

Broadcasting the Transaction: The sender broadcasts the transaction to the Bitcoin network. The
transaction is validated and added to the blockchain, becoming an Unspent Transaction Output
(UTXO) associated with the receiver’s public key hash.

Viewing the Balance: The receiver’s wallet software identifies the UTXO associated with his public
key hash and displays the spendable balance. Allows the receiver to see and eventually use the
funds.

Spending the UTXO: When The receiver wants to spend the UTXO: He creates an input referencing
the Transaction Identifier (txid) of the sender’s transaction and the index of the output (vout) that the
sender created. He creates a signature script (scriptSig) containing data (e.g., his signature and
public key) that satisfies the conditions in the sender’s pubkey script and authorizes the transaction
by proving ownership of the private key corresponding to the public key hash.

Combining Scripts: The receiver’s signature script (scriptSig) and the sender’s pubkey script
(scriptPubKey) work together to validate the transaction. Ensures programmable authorization and
secures the transfer of funds.

Pay To Public Key Hash (P2PKH): P2PKH is the most common form of pubkey script used to send a
transaction to one or multiple Bitcoin addresses.

Pay To Script Hash (P2SH): P2SH is used to send a transaction to a script hash. Only the hash of the
redeem script (a more complex script) is stored in the transaction output. The redeem script is verified
later when someone spends the transaction. The hash of the redeem script is stored in the
blockchain, reducing transaction size and making the pubkey script simpler. The redeem script is
revealed only during the spending process, making it more efficient for lightweight wallets or novel
use cases.

Multisig: Multiple signatures are required before a UTXO can be spent. In multisig pubkey scripts,
called m-of-n, m is the minimum number of signatures which must match a public key; n is the
number of public keys being provided.

Null Data: Transactions with spendable outputs unnecessarily increase the size of the UTXO
database, which full nodes must store and manage indefinitely. Null data transactions are marked as
provably unspendable, ensuring that their outputs don’t get added to the UTXO set. This helps
optimize blockchain storage and reduces the load on full nodes, making the network more efficient
and scalable. It enables Pruning and Network Efficiency since null data outputs are unspendable, full
nodes can prune them from their UTXO database after validation. This reduces the long-term storage