These are notes that I have kept during the process of learning more about bitcoin and crypto currency
Cryptographic Hash Functions
Summary: The committment API is how cryptographic hash functions work. This is basically a starter to how public/private key encryption through hashing works
How the commitment API works
//applying a commit function to a message, will return a com(committment val) and a key //property 1: Hiding - Given only com, its infeasible for anyone to find out the message so the message itself is hidden
(com, key) := commit(msg)
//publish key, msg and the user presumably already has com this will allow the user to verify the mesasge //property 2: Binding - Its infeasible to find a message2 such that verify(commit(msg), message2, key) == true. This basically is there to ensure that once you have committed to a message you cannot modify and use the commitment with a different message
match := verify(com, key, msg)
Summary: Hash pointers provide a mechanism to have the following properties.
Purpose of a hash pointer: - pointer to get information back - erify the information has not changed - CAN WORK FOR ANY DATA STRUCTURE WITH NO CYCLES!!! - Can be used to create simple trusted blockchains
Simple Bitcoin Schemes
The following are two examples of dumb bit-coins which work but have obvious problems:
Rules for Goofy coin:
- Goofy can create new coin - Goofy can create a new coin - Can send coin to someone else
Transactions are done in a block chain fashion as follows
- Goofy creates a coin, and it is signed by Goofy’s private key
- this is then paid to alice and alice now owns the hash
Pros: It’s decentralized
Cons: Double Spending Attack : It’s impossible to detect if the user sends the same coin to multiple users thereby spending it again, since all of those block chains can be verified as “untampered”
Create coin functionality
Every coin is created and published
- It’s assigned to a recepient (public key)
- Each coin has a ID
Pay coins functionality
Each block as explained earlier can have multiple transactions
- consumes valid coins
- coins that are not already consumed
- create new coins equal to the value of the consumed coins
Signature: signature of all the owners
Coins are immutable they are created and destroyed, but they belong to the same user when they were created
No Double spending attack
The problem here is a centralized transaction management system, Scrooge is the coin creator and destroyer since scrooge keeps the history
- Can we have a decentralized trusted mechanism
- How can people agree on validity of transactions
- How to give ID’s to these transactions?
Decentralization in Bitcoin
Important aspects to remember
- Who maintains the ledger of transactions?
- Who has authority over which transactions are valid?
- Who creates new bitcoins?
- Who determines how the rules of the system change?
- How do bitcoins acquire exchange value?
Problems with current distributed consensus protocols (Impossibility Result):
- Byzantine Generals Problem
- Fischer Lynch Paterson
Paxos - never produces inconsistent result, but under some conditions can get stuck.
- Why not use PAXOS for bitcoin consensus an already existing agreed upon consensus protocol? Paxos is designed more for distributed systems, and doesn’t work as well for bitcoin
- Bitcoin nodes have no identity
- Identity is hard in a P2P system - Sybil attack
- Psudonymity is a goad of bitcoin
Bitcoin distributed consensus protocol
The problem we are trying to solve is a distributed consensus protocol, where a chain of trust can be maintained. Remember that there is no identity for each of the nodes in the blockchain rather the blockchain is provided tokens!
- Sybil attack
- Double spend attack
Bitcoin consensus algorithm (simplified) This algorithm is simplified in that it assumes the ability to select a random node in a manner that is not vulnerable to Sybil attacks.
- New transactions are broadcast to all nodes
- Each node collects new transactions into a block
- In each round a r andom 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
The following is an example of a double spend attack.
In this attack Alice is a malicious agent, who defrauds user Bob by sending him some money and then sends the same bitcoin to herself using a pseudonym. Given that Bob allows the transaction to proceed immediately after receiving the money, there is a high probability that the Ca→A’ transaction will proceed having the longer chain rather than the Ca→B transaction. Thus being a successful attack
Now let us see how bitcoin defends against this attack by seeing the same transaction from Bob’s viewpoint.
So there is no consensus guarantee, but after several confirmations there is a very high probability that the transaction is true and finished.
Incentivize nodes for working honestly