Types of Transaction

Bitcoin currently creates two different scriptSig/scriptPubKey pairs. These are described below.

It is possible to design more complex types of transactions and link them together into cryptographically enforced agreements. These are known as Contracts.

Pay-to-Public-Key-Hash(P2PKH)

Most consider a basic bitcoin transaction with one public key address transacting value to another address. A Bitcoin address is only a hash, so the sender can’t provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:

Pay-to-Script-Hash (P2SH)

P2SH addresses were created with the motivation of moving “the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. They allow the sender to fund an arbitrary transaction, no matter how complicated, using a 20-byte hash“1. Pay-to-Pubkey-hash addresses are similarly a 20-byte hash of the public key.

Pay-to-script-hash provides a means for complicated multi-signature transactions, unlike the Pay-to-pubkey-hash, which has a specific definition for scriptPubKey, and scriptSig. The specification places no limitations on the script, and hence absolutely any contract can be funded using these addresses.

The scriptPubKey in the funding transaction is a script that ensures that the script supplied in the redeeming transaction hashes to the script used to create the address.

In the scriptSig above, ‘signatures’ refers to any script sufficient to satisfy the following serialized script.

Checking process:

Generation
Generations have a single input, and this input has a “coinbase” parameter instead of a scriptSig. The data in “coinbase” can be anything; it isn’t used. Bitcoin puts the current compact-format target and the arbitrary-precision “extraNonce” number there, which increments every time the Nonce field in the block header overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction. The extra nonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp, and an extra nonce (2 to 100bytes).

General format (inside a block) of each input of a transaction – Txin

The input sufficiently describes where and how to get the bitcoin amount to be redeemed. If it is the (only) input of the first transaction of a block, it is called the generation transaction input, and its content is completely ignored. (Historically, the Previous Transaction hash is 0, and the Previous Txout-index is -1.)

General format (inside a block) of each output of a transaction – Txout

The output sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

Multisignature
In multisignature, more than one private key is required to make the transaction. If you think of a standard paper check-in where two parties have to sign or authorize the check, this is the same basic principle as multisignature bitcoin transactions. A multisignature address will be easy to identify as it begins with the number 3 instead of 1 or bc1, as discussed earlier.

A transaction can be in either one of two states:

• Spent state—This is where the value of an address in a transaction has been moved on to another address.
• Unspent state—This is where the value in an address has not been spent.
  

An unspent transaction is known as a UTXO or Unspent Transaction Output. To determine your pseudo-balance, you add up all the UTXOs in all the addresses that you have the private key to unlock.