Hacker News new | ask | show | jobs
by hendzen 4572 days ago
From the article: "I don’t understand why double spending can’t be prevented in a simpler manner using two-phase commit. What drawbacks and advantages does it have compared to the full Bitcoin protocol? uppose Alice tries to double spend an infocoin with both Bob and Charlie. The idea is that Bob and Charlie would each broadcast their respective messages to the Infocoin network, along with a request: “Should I accept this?” They’d then wait some period – perhaps ten minutes – to hear any naysayers who could prove that Alice was trying to double spend. If no such nays are heard (and provided there are no signs of attempts to disrupt the network), they’d then accept the transaction."

The problem with 2PC is that a malicious node could stop somebody from being able to spend their coins by always sending nays out to the network when ever the victim sent a transaction. To prevent this, you would need to be able to detect when a node is faulty/malicious which would require implementing a costly Byzantine Consensus Protocol [1]. In practical systems that can withstand Byzantine faults, the number of messages required to agree on a log entry (e.g. a transaction) would be O(n^2) in the number of nodes in the network, which would greatly limit scalability.

The genius of Bitcoin's Proof of Work protocol is that:

1) it is more resilient than Byzantine agreement. Byzantine agreement with 3f+1 nodes can handle at most f faulty nodes, while Bitcoin can tolerate 49% of the network hashing power being malicious. (though this is being debated currently due to theoretical strategies like selfish-mining)

2) it is much more efficient than Byzantine agreement in the number of messages sent, which has allowed the network to scale to thousands of nodes, although they have been running into issues with the blocksize/block limit, but their are currently research efforts [4] underway to remedy this.

The main problem with Bitcoin's proof of work scheme it is that it is extremely expensive in terms of CPU cycles, but this is solved by compensating miners for their efforts through coin generation and transaction fees.

[1] - http://www.cs.cornell.edu/courses/cs614/2004sp/papers/lsp82.... [2] - http://pmg.csail.mit.edu/papers/osdi99.pdf [3] - http://arxiv.org/pdf/1311.0243v5.pdf [4] - http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full...

2 comments

I don't think this exactly right -- an evil node can't send a false nay because it would have to be able to forge the conflicting transaction, the signature prevents that.

Bitcoin already essentially does the 2PC that the author is asking about for unconfirmed transactions. The problem being solved is that the Byzantine Generals problem is unsolvable for anonymous actors, as a malicious participant can create a majority of evil voters, winning any dispute resolution by 'Sybil attack'.

The proof of work system allows a newly joined node to determine the current consensus even when it's disputed, without having any idea who is on the network, so long as it has at least one link to the true hashing-power consensus. It also acts as a commitment protocol -- once you've signed your winning block to the network, it's nonrepudiable even by you.

With an alternate source of identification, a pseudo-anonymous 'Infocoin' ledger should be able to function and scale just fine without all the PoW expenditure--or in other words, you must have a system of making identities expensive, and Bitcoin's is Proof of Work.

Original post author here. Thanks -- your comment pretty much nails the answer to my question.

Edit: A problem with this is that it would be necessary for a naysayer to exhibit the other transaction (proof of double spending). But they couldn't forge such a transaction, since they don't have the private key necessary to generate the signature. So I'm still a bit puzzled by this.

Edit 2: And it appears that bcoates is making the same point.

Btw, Ripple is basically a two-phase commit protocol. The problem is trust - ripple has basically decided to trust a centralized list of nodes, whereas bitcoin does not require this trust.
The problem is network disruption. Your system would work if you could guarantee all nodes in the network could communicate with each other every 10 minutes. What happens if this is not possible?

This scenario is called a netsplit in Bitcoin parlance. It has happened before, and it will happen again. In bitcoin, healing a netsplit is relatively easy, you pick the longest chain and you allow all the transactions from the smaller chains to be re-added to blocks in the new official chain.

In your system, if you had a double-spend where both sides ended up being accepted due to a netsplit, which one would win during the healing process? In bitcoin, the winner is the one that happens to be in the longest chain.

Secondly, how would you store the infocoin ledger in your system? The advantage of the bitcoin blockchain is that it provides an official source for all transactions that is easy to verify. A new node can come in, download the block chain and be certain they have all the information available about bitcoin ownership, with no holes. In your system, without a blockchain, how do you guarantee you have a record of all transactions, with no gaps?

"In your system, if you had a double-spend where both sides ended up being accepted due to a netsplit, which one would win during the healing process? In bitcoin, the winner is the one that happens to be in the longest chain."

That doesn't seem to be unanswerable, and it's not like "happens to be on the longest chain" is more deserving or anything, it just happens to be the way it works in bitcoin.