These are my notes of the eighth lecture from Coursera’s Bitcoin and Cryptocurrency Technologies during Dec 2016 – Feb 2017. While the lecture is lengthy and I had to watch it a few time to grasp the concepts, I thought it was interesting.
Questions answered in this Post:
- What is bitcoin’s stance on node identity? Why?
- What is a Sybil attack?
- What is implicit consensus?
- What are some attacks discussed that this consensus protocol protects against?
- What is an orphan block?
- What is a zero-confirmation transaction and how to prevent it?
One major point was that bitcoin nodes do not have persistent long-term identities. Because of this, the consensus protocol attributes deviate from what is in the distributed systems consensus protocols. So, while we know that bitcoin is different, why exactly do we care? One thought is that because of this deviation, does this mean the existing algorithms are not compatible and thus something new have to be invented? Why are identities useful for distributed consensus protocols?
Below are the specific examples provided in the lecture:
Pragmatic: some protocols need node identification (id) such as a protocol could say use the lowest ranked ID to do .
Security: assume less than 50% malicious nodes for this protocol to work.
Prevent from a Sybil Attack An adversary makes multiple nodes and uses them to break the system.
Why don’t Bitcoin nodes have identities?
- Since Bitcoin is a P2P system, no central body to assign identities to nodes
- Pseudo-anonymity is actually an inherent gol of bitcoin
So instead of that, Arvind suggested something weaker in that the system is able to pick a random node in the system as well as determine who is the owner thus making the all Sybils get a single token. With this procedure then something called implicit consensus can occur.
Implicit Consensus (AKA Simplified Bitcoin Consensus algorithm)
It’s a procedure of adding new blocks to the blockchain in consensus.
- Random node is selected and make it
- proposed the next block in the chain
- Other nodes accept or reject the block by determining whether or not to build on top of it
- If accept, then this block gets added. If reject, they ignore the block and build over the current chain they have.
- Nodes acceptance means adding the block’s hash in the next block they create
Why does this work? or how can a malicious adversary subvert the process?
- Stealing Bitcoin – not if the underlying crypto is good
- Denial of Service Attack – not unless all other nodes are malicious
- Double-spend attack – add the heuristic that only add to the longest block
Can Alice simple steal Bitcoins belonging to another user at a different address that she doesn’t control?
Example:
It is not Alice’s turn to propose the next block in this chain.
She can’t steal other bitcoins because she can’t forge their signatures and thus if the underlying crypto is solid, one cannot simple steal Bitcoins
If she hates a node Bob, she can choose not to accept any blocks proposed by Bob. So she’s denying service to Bob.
Thus if Bob’s block doesn’t make it into the next block Alice proposes, he will just wait another block until an honest node gets the chance to propose.
Arvind claims this is nothing more than a little annoyance. I guess in my mind it was larger. First with this little annoyance, I see it as a delay since you’re waiting for the next honest node. The next honest node could take a very long time.
The last one Arvind talks about is the double spending attack.
Alice is a customer of a merchant and Bob is the seller.
Alice goes to Bob’s website and buys for it in Bitcoins.
She creates a Bitcoin transaction from her address to Bob’s address.
Thus it gets broadcasted to the network
C_A -> B
transaction
signed by A
pay to pk_B: H()
This transaction should have existed from a previous transaction. Thus there’s a pointer to that previous block.
Let’s say Alice is now proposing a transaction, decides to ignore the bock with Bob’s stuff and create a new transaction
transaction
signed by A
pay to pk_A: H()
Will they both end up in the long term consensus chain
There is an idea that the honest node will extend the longest valid branch. From the facts of the transaction, both leafs have the same number of transactions. They have the same length.
There is a heuristic where you choose the node that you received first. Thus there is a chance that the other block would get chosen, so what happens with Bob.
The chain with Bob meant that Alice got free software and Bob did not get any payment. The remainder block is called an orphan block.
Thus this would be a successful double spend.
Zero-confirmation transaction Bob would send over the software without waiting to see if Alice’s transaction actually made it into the blockchain. It’s like giving someone a product with only seeing that they have the money in their hand and that they hadn’t actually given it to you.
However, instead Bob should be more careful. He should wait for more confirmations before sending the software. Because he knows that the longer chain gets chosen, then he’s in the clear if he sees that his transaction has more blocks
Double spend probability decreases exponentially with # of confirmation
Most common heuristic: 6 confirmations
Recap
- protection against invalid transactions is cryptographic but enforced by consensus
- Protection against double-spending is purely by consensus
- You’re never 100% sure a transaction is in the consensus branch. Guarantee is probabilistic. 1- (1/2)^6 = .9844
What can a malicious node do?
Ignore the longest valid branch rule when proposing a new block.