0

I am trying to wrap my head around GHOST protocol... I know it's too much to read, but not my fault. It's GHOST that's complicated (i guess)

As I read, it's said that:

instead of a longest chain consensus rule, GHOST follows the path of the subtree with the combined hardest proof of work/difficulty.

enter image description here

OK, SO Let me explain how I understand it. Every node started at 0 block. Then other nodes mined 1B block, attacker mind 1A block.. and attacker solves his block(belowest one) secretly.He doesn't broadcast it. Other nodes are at 1B and now there happened to be a fork (2D,2C,2B) since blocks got mined at the same time. then some nodes went ahead and got the longest chain ending at 5B(the most top chain). Remaining nodes(L1) are at 2C and 2B. some nodes(L2) from these remaining nodes(L1) are at 3E,3D,3C. and one of the nodes from L2 is at 4B now. Now, let's take a moment and say that everyone on the network broadcasted their blockchains. Attacker's chain won't be accepted because there's only 1 subtree(one path only).. Also, the most top chain is only one. As we can see on the image, The biggest subtree is 3E, 3D,3C. So what happens is some nodes share 0->1B->2C->3E, some share 0->1B->2C->3D->4B, some share 0->1B->2C->3C. Let's say I am nodeA and I receive all the broadcasted chains. When I get all of those, I have to choose from them. Since I found that different chains are derived from 2C, I should follow that path. I follow it and try to find the longest one in them which results in 0->1B->2C->3d->4B and that's the one i am gonna accept.

In this case, attacker's chain is doomed. so i think one of the problem's chance which is having 51% hash rate power and broadcasting the longest chain has been decreased(which is great). But I still see a couple of issues.

  1. If blocks don't get mined at the same time, we won't have subtrees as shown on the image, Hence GHOST protocol is powerless here. and we still have 51% attack possibility and in this case, attacker's secret chain will succeed.
  2. So, if blocks get mined at the same time, that's when GHOST protocol will help us. I guess GHOST protocol is a little bit of extra safety added on top of proof of work. but as soon as nodes followed GHOST protocol(which means, they accepted the chain - from the image it's 0->1B->2C->3D->4B), we are back to where we were(longest chain wins). until blocks start to get mined at the same time again..
  3. Let's say attacker broadcasted his chain, and my node received it. And let's also say that i've not received other node's chain due to network propagation delay. How will my node know that it shouldn't accept attacker's chain ? if my node had received all other node's chains, it would figure out that subtree in 0->1B->2C is bigger and would reject attacker's chain. Any idea ?
1

I think the main thing you've missed is the problem GHOST set out to solve.

It's first and foremost intended as a scalability/speed upgrade. We want to increase the size of each block and/or decrease the interval between blocks. Either of these would increase the ratio between propagation time and block interval.

The higher the ratio is, the more we get that blocks are mined at the same time. And then lots of honest hashrate is wasted on blocks that get orphaned.

This makes it easier for an attacker to attack, because he doesn't need to have more hashrate than the honest network - he only needs to have more hashrate than the unwasted hashrate of the honest network.

This isn't much of a problem now, when blocks are 10 minutes apart and are about 3MB. But if we were to try to, say, reduce the interval between blocks to 1 second, the time to propagate blocks will be a multiple of the average time to find a block, leading to huge waste and an easy attack.

GHOST (and the more recent SPECTRE) is designed to allow us to increase block size or speed without this waste.

Contrary to what you said, simply adopting GHOST will not cause less branching in the block tree. It will just mean that we won't waste hashrate due to this branching.

Re question 3 - I think you've got things backwards. The way a double-spending attack works is:

  1. Attacker pays merchant, tx is included in the honest chain.
  2. Merchant gives product.
  3. Attacker releases secret chain, where the tx is replaced by one that credits the attacker.
  4. Attacker has both the product and his money.

If you are not up-to-date on the network state, and think the attacker's chain is winning even if it's not, you're actually better off - you will see that the attacker intends to not pay, and you will know not to send the product.

After I send the product, I want the whole chain to recognize the tx that pays me. Even if there are nodes which are not up to date, and briefly believe the attacker's chain is valid - that will resolve quickly after they receive the blocks they've been missing (and see that the honest chain has more weight).

3
  • Thanks for the nice explanation. now i understand what the ghost protocol is for. I just don't understand how it solves the problem (waste of miner's hashrate, decrease attacker's chance)... Sep 27 '20 at 11:46
  • Could you explain how it solves the problem, starting with the scenario when there are 10 nodes and all of them mined the block at the same time. One of them is an attacker too. Let me know if it's better to ask a new question. Sep 27 '20 at 11:48
  • @NikaKurashvili: Consider the image in your question. The attacker only has 33% of the total hashrate - he was able to find 6 blocks, while 12 were found by the honest network. But he is able to put them all in a neat row, so in the longest chain scheme, he would be able to create a chain longer than the honest network (because only a single branch of the honest network is counter). In the GHOST protocol, he can't - the tree rooted at 1B is heavier, so the attacker's long but thin branch will be ignored. All the blocks mined by the honest network are counted, despite the branching. Sep 29 '20 at 10:08

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.