In the earlier post I wrote about Bitcoins, their goodness and the underlying cryptography. In the present post I a writing about Bit coins transactions and Blockchain.
Bitcoins are associated with “bitcoin addresses”. Bitcoins themselves are not stored; but rather the keys or passwords needed to make payments are stored, in “wallets” which are apps that manage the addresses, keys, balances, and payments. Specifically, there are two cryptographic keys associated with each bitcoin, a public key and a secret key. Public key is the bitcoin address and secret key is used to make payments. These keys are the same keys used to sign and verify the digital signatures.
How transaction happen in Bitcoin?
A transaction is an instruction to unlink some bitcoins from an address(sender), and move them to the control of another address (recipient). Bitcoin defines electronic coin as a chain of cryptographic digital signatures. Each sender transfers the coin to the recipient by digitally signing a hash of the previous transaction and the address of the recipient and adding these to the end of the transaction. A payee can verify the signatures to verify the chain of ownership.
Image Source : Bitcoin white paper
How to verify that one of the owners did not double-spend the coin?
There is a need for a way for the payee to know that previous owners did not sign any earlier transaction. To accomplish this without a trusted party, transaction must be publicly announced, and a system for participants to agree on a single history of the order in which they are received.
How to make public announcement?
Timestamping: Timestamp each transaction such that majority of the nodes agree that it was the first transaction where bitcoins are spend. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the one before it.
How to implement a distributed timestamp server on a peer-to-peer basis?
Blockchain : distributed ledgers, i.e. a list of transactions that is replicated across a number of computers, rather than being stored on a central server. Blockchains has dual aim, anyone should be able to write to The Bitcoin Blockchain; and that there shouldn’t be any centralised power or control.
A use case for a block chain is a tamper‐evident log. That is, we want to build a log data structure that stores a bunch of data, and allows us to append data onto the end of the log. But if somebody alters data that is earlier in the log, we’re going to detect it.
What is the safeguard for Blockchain?
Hash Pointer. A hash pointer is simply a pointer to where some information is stored together with a cryptographic hash of the information. Whereas a regular pointer gives you a way to retrieve the information, a hash pointer also gives you a way to verify that the information hasn’t changed.
Blockchain is built as a linked list using hash pointers. Whereas as in a regular linked list where you have a series of blocks, each block has data as well as a pointer to the previous block in the list, in a blockchain the previous block pointer will be replaced with a hash pointer. So each block not only tells us where the value of the previous block was, but it also contains a digest of that value that allows us to verify that the value hasn’t changed. We store the head of the list, which is just a regular hash‐pointer that points to the most recent data block.
If an adversary modifies data anywhere in the blockchain, it will result in the hash pointer in the following block being incorrect. If we store the head of the list, then even if the adversary modifies all of the pointers to be consistent with the modified data, the head pointer will be incorrect, and we will detect the tampering.
How Blockchains are implemented in bitcoin?
In distributed setting even if all peers are ‘trusted’, there can be a problem of agreement or consensus – if each peer is updating at different speeds and have slightly different states, how do you determine the “real” or “true” state of the data? Worse, in an ‘untrusted’ peer-to-peer network where you can’t necessarily trust any of the peers, how do you ensure that the system can’t easily be corrupted by bad peers?
For the time assume there is somehow an ability to pick a random node in the system. This assumption of random node selection makes possible something called implicit consensus.
Bitcoin consensus algorithm :
- New transactions are broadcast to all nodes
- Each node collects new transactions into a block
- In each round a random node gets to broadcast its block
- Other nodes accept the block only if all transactions in it are valid (unspent, valid signatures)
- Nodes express their acceptance of the block by including its hash in the next block they create.
What about random node ?
Proof-of-work: Solution to selection a random node in untrusted environment. The key idea behind proof‐of‐work is that we approximate the selection of a random node by selecting nodes in proportion to a resource that we hope that nobody can monopolize. The idea is to allow nodes to compete with each other by using their computing power, and that will result in nodes automatically being picked in that proportion.
Bitcoin achieves proof‐of‐work using target hashes, an application of hash puzzles. Blockchain implement target hash by increment a nonce in the block until a value is found that gives the block’s hash the required zero bits.
As we saw earlier, normally a block contains a series of transactions that a node is proposing and a hash pointer to the previous block. In addition, we’re now requiring that a block also contain a nonce. The idea is that we want to make it moderately difficult to find a nonce that satisfies this required property, which is that hashing the whole block together, including that nonce, is going to result in a particular type of output. If the hash function satisfies the puzzle‐friendliness property, then the only way to succeed in solving this hash puzzle is to just try enough nonces one by one until you get lucky.
H (nonce || prev_hash || tx || tx || … || tx) < target
This notion of hash puzzles and proof of work completely does away with the requirement to magically pick a random node. Instead, nodes are simply independently competing to solve these hash puzzles all the time. Once in awhile, one of them will get lucky and will find a random nonce that satisfies this property. That lucky node then gets to propose the next block. That’s how the system is completely decentralized. There is nobody deciding which node it is that gets to propose the next block.