Blockchain: Transactions - blockchainpsu/blockchain-essentials-spring2020 GitHub Wiki
Introduction
Behind each block is a group of transactions. A transaction in cryptocurrency involves a sender, receiver, and an amount of currency sent. If we go broader, it'll still require a sender and receiver, but the "amount" specified isn't limited to monetary value anymore.
However, transactions are more complex than that. How do we know that a transaction meant to be added to the chain is legitimate? It'll require a little bit of finagling with signatures and hashes, to verify that everything's in order.
Transaction Structure
Transactions are mainly made of an input plus the ID of the transaction, and then has an associated output with the transaction value.
The input is created with the sender's public address and amount sent, and the output is created with the receiver's public address. Of course, there's a lot of math involved to make sure that the wrong people don't get the transaction.
A key part of protecting the transaction for the intended recipient is through a digital signature, which is used to prove ownership of a transaction's value once sent. Let's take a look at those now.
Digital Signatures
Each member node on a blockchain is assigned a public and private key. Public keys are used to create public addresses, and are ... public. Private keys are ... private.
We sign transactions using the recipient's private key to indicate that the recipient is the intended recipient. That is, the sender of the transaction meant to send the transaction to a certain person, and that person will verify they're the right person by signing.
Key Generation
A key part of this is actually generating the keys themselves. Let's look at one common example to display its intricacy with RSA, and then look at how Bitcoin does it with ECDSA.
RSA Encryption
The Rivest-Shamir-Adleman (RSA) algorithm is a simple, popular encryption method, and not at all relevant to blockchain. However, I'll briefly mention it as key pair generation tool.
In RSA, key pairs are created by taking two large random primes, multiplying them together, throwing them into a mathematical function called a totient, doing some more math shenanigans and then arriving at your key pair. The public key is the product of the random primes and an arbitrary exponent e. The private key involves the exponent e and the totient of the product of the primes. If you want a better explanation of RSA key generation, look at its Wikipedia entry.
What I'm trying to get at is that key pair generation has to be extremely careful. Breaking RSA encryption involves finding the two original primes from their product, which is extremely difficult to do. So, for blockchain, we need a way to generate key pairs and make it hard to find them in the first place.
ECDSA
The Merkle Tree
When we represent transactions in the blocks of a blockchain, we use a Merkle Tree to help represent the transactions in a storage-friendly manner.
A Merkle Tree is a complete binary tree of hashes, where each parent node is the hash of its children concatenated together, and each leaf is a transaction ID. In Bitcoin, as we move towards the root of the binary tree, we hash the concatenated children twice with SHA-256.
The root (referred to as the Merkle Root), then, is a representation of each transaction stored in a block. If the transactions somehow change or are different, we'll know because the Merkle Root will be different from what it was before.