2

I do understand the necessity for a proof of work to avoid malicious miners mining a fork on the current blockchain. This is difficult as this proof of work takes lots of power (and time).

Yet I don't understand why do we need a proof of work if transactions were almost instantaneous: if I use an adress with unspent input to pay a merchant and if this transaction is immediately validated (or let's say in the next 12 seconds) by the peers, then I don't have any input left for double-spending...

This is my understanding so what points am I missing?

  • Validated by who though? The whole world needs to validate and (more importantly) agree on the order of the transactions. 12 seconds is plenty of time to send a double spend transaction. – Jannes Nov 27 '15 at 11:28
  • If I spend 40 BTC I really have to pay a merchant and then another 30 BTC which I don't have to pay another merchant, nodes/peers, when receiving these transactions do see the double spending and they just have to refuse one of these two transactions. So what's the point to have on top of that a need for a proof of work? – blockFrance Nov 27 '15 at 13:47
  • 2
    Yeah, but the point is that other nodes don't know which was the first transaction. They don't know which one to refuse. So half of them might refuse the 30BTC, but the other half would refuse the 40BTC. And then noone knows the truth anymore. And to make things worse, this is largely under control of the attacker, so he can get 99% to refuse the 40BTC transaction. – Jannes Nov 27 '15 at 15:20
  • @blockFrance Even if they do refuse it initially, what do they do if they see it later in a chain with more proof of work than their current chain? If they refuse it at that point, they'll disagree with the rest of the world. – David Schwartz Nov 30 '15 at 12:07
4

How do nodes bootstrap if some of the nodes are evil?

It's actually not that difficult to obtain a very large number of IP addresses. There are botnets that have hundreds of thousands of nodes.

Imagine that each bot in that botnet joined your network, and pretended to be a normal node. Then, the botnet controller makes those nodes claim that some transaction never happened. (Or, that some other transaction happened instead.) If a new node arrives to the network, who are they going to believe: the 99% who claim that the transaction never happened, or the 1% who do?

This is a deceptively simple sounding problem, and it's very easy to come up with proposals that sound good, but don't work.

What if two conflicting transactions show up at the same time?

Second, even supposing that the entire system came to consensus at the speed of light, I (an attacker) can still get two systems to disagree. I rent two servers in different parts of the world, and I get them both to broadcast different, conflicting transactions to local nodes. Because of the distance, it's guaranteed that even honest nodes will disagree about which transaction came first.

Because there's no way to stop peers from occasionally disagreeing, you need a way to resolve those disagreements. In Bitcoin, this is pretty simple. Each Bitcoin node has its own memory pool, some of which conflict. Each node tries to create a block. Eventually, one of them will win.

You're probably wondering, "Why not just ask your peers which transaction came first, and change your vote if a majority of them disagree?"

The problem with querying your peers: Cliques

Imagine a network structured like this:

network with nine nodes, half of which are blue and half of which are orange

The blue nodes believe that transaction A came first. The orange nodes believe that transaction B came first. The lines represent connections between peers.

From the perspective of each individual node, a majority of their peers agree with their vote, and so the two blocs will never come to agreement. In the worst case, the transaction will be in limbo forever.

This problem is solvable, but all of the solutions (including Bitcoin's solution) have nontrivial downsides.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.