Transaction Lifecycle:

1. Creation:
   ┌─────────────────────────────────────────────────────────────┐
   │  • User creates transaction in wallet                     │
   │  • Selects UTXOs to spend                                 │
   │  • Specifies outputs                                      │
   │  • Calculates fees                                        │
   └─────────────────────────────────────────────────────────────┘
                              │
                              ▼
2. Signing:
   ┌─────────────────────────────────────────────────────────────┐
   │  • Wallet signs each input                                │
   │  • Adds signatures to transaction                         │
   │  • Transaction becomes valid                             │
   └─────────────────────────────────────────────────────────────┘
                              │
                              ▼
3. Broadcasting:
   ┌─────────────────────────────────────────────────────────────┐
   │  • Transaction sent to network                            │
   │  • Nodes add to mempool                                   │
   │  • Propagates across network                              │
   └─────────────────────────────────────────────────────────────┘
                              │
                              ▼
4. Validation:
   ┌─────────────────────────────────────────────────────────────┐
   │  • Nodes verify signatures                                │
   │  • Check UTXO availability                                │
   │  • Verify no double-spend                                │
   └─────────────────────────────────────────────────────────────┘
                              │
                              ▼
5. Mining:
   ┌─────────────────────────────────────────────────────────────┐
   │  • Miners select transactions                             │
   │  • Include in block                                       │
   │  • Solve PoW puzzle                                      │
   └─────────────────────────────────────────────────────────────┘
                              │
                              ▼
6. Confirmation:
   ┌─────────────────────────────────────────────────────────────┐
   │  • Block added to blockchain                              │
   │  • Transaction has 1 confirmation                         │
   │  • More confirmations over time                           │
   └─────────────────────────────────────────────────────────────┘

Script Properties:
- Stack-based: Operates on a stack
- Non-Turing Complete: No loops, bounded execution
- Stateless: No memory between executions
- Deterministic: Same input → Same output
- Secure: No recursion, no infinite loops

Script Execution:
1. Push data onto stack
2. Execute opcodes
3. Final stack contains result
4. Valid if top element is true (non-zero)

ScriptSig (Unlocking):
<sig> <pubkey>

ScriptPubKey (Locking):
OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG

Execution:
1. <sig> <pubkey> (stack from ScriptSig)
2. OP_DUP (duplicate pubkey)
3. OP_HASH160 (hash pubkey)
4. <pubkey_hash> (push script hash)
5. OP_EQUALVERIFY (compare hashes)
6. OP_CHECKSIG (verify signature)

ScriptSig (Unlocking):
<sig1> <sig2> <redeem_script>

ScriptPubKey (Locking):
OP_HASH160 <redeem_hash> OP_EQUAL

Redeem Script (for 2-of-3):
OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG

Execution:
1. Evaluate redeem script
2. Check hash matches
3. Execute redeem script

ScriptSig (Unlocking):
<sig>

ScriptPubKey (Locking):
<pubkey> OP_CHECKSIG

Execution:
1. <sig> (from ScriptSig)
2. <pubkey> (push pubkey)
3. OP_CHECKSIG (verify signature)

ScriptPubKey:
OP_RETURN <data>

Purpose:
- Store arbitrary data on blockchain
- Proof of existence
- Metadata storage

Limitations:
- Data cannot be spent
- Usually limited to 80 bytes
- Used for various applications

Transaction Validation Process:

1. Syntax Validation:
   ✓ Correct format
   ✓ Valid lengths
   ✓ Known opcodes

2. Input Validation:
   ✓ Inputs exist and are unspent
   ✓ Input amounts sum correctly
   ✓ No double-spend

3. Script Validation:
   ✓ Execute ScriptSig + ScriptPubKey
   ✓ Result must be true
   ✓ No script errors

4. Fee Validation:
   ✓ Fee >= minimum
   ✓ Fee rate acceptable
   ✓ Not below dust limit

5. Consensus Rules:
   ✓ Check locktime
   ✓ Sequence numbers valid
   ✓ No OP_RETURN in inputs
   ✓ Transaction size within limits

Script Stack Operations:

Example: P2PKH Verification

ScriptSig: <sig> <pubkey>
ScriptPubKey: OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG

Stack Evolution:
Step 1: [<sig>, <pubkey>]
Step 2: OP_DUP → [<sig>, <pubkey>, <pubkey>]
Step 3: OP_HASH160 → [<sig>, <pubkey>, <hash>]
Step 4: <pubkey_hash> → [<sig>, <pubkey>, <hash>, <pubkey_hash>]
Step 5: OP_EQUALVERIFY → [<sig>, <pubkey>] (if equal)
Step 6: OP_CHECKSIG → [true] (if signature valid)

Result: true (transaction valid)

Coinbase Transaction:
- First transaction in every block
- Creates new bitcoins
- No inputs (creates UTXO from nothing)
- Contains block reward + transaction fees

Coinbase Input:
Input Count: 1
Previous Transaction: 0x0000...0000 (all zeros)
Output Index: 0xFFFFFFFF
ScriptSig: <block_height> <extra_nonce> <message>

Coinbase Output:
Block Reward: 3.125 BTC (as of 2024)
Transaction Fees: All fees from transactions

SegWit Transaction Structure:

Legacy Part:
- Version
- Inputs
- Outputs
- Witness Marker (0x0001)
- Witness Count

Witness Part:
- For each input: witness stack
  - Signature
  - Public key

Benefits:
- Transaction malleability fixed
- Lower fees (more space efficient)
- Path for future upgrades
- Script versioning

SegWit Address:
- Bech32 format (bc1...)
- Native SegWit (P2WPKH)
- Wrapped SegWit (P2SH-P2WPKH)

Taproot Transaction (2021 Upgrade):

Key Features:
1. Schnorr Signatures
2. MAST (Merklized Abstract Syntax Tree)
3. Script Paths (multiple spending conditions)
4. Key Path (single signature)

Taproot Address:
- Bech32m format (bc1p...)
- 32-byte public key

Script Structure:
- Taproot: Key path OR Script path
- Key path: Single signature (standard)
- Script path: Merkle tree of scripts
- Only reveal executed script

Benefits:
- Privacy (only one condition revealed)
- Lower fees (smaller transactions)
- Complex scripts (more conditions)
- Batch verification

Fee Market:

Supply: Block space (1 MB - 4 MB)
Demand: User transactions

Low Demand: Low fees (1-2 sat/vB)
High Demand: High fees (50-100+ sat/vB)

Fee Estimation:
1. Wallet estimates fee
2. Based on mempool size
3. Based on recent blocks
4. Based on urgency

Priority:
1. High fee = First confirmation
2. Low fee = May wait
3. Very low fee = May never confirm