6 ms·

anyone who thinks GHOST is a good idea, has not understood Bitcoin at all. the whole point of the blocks is that nodes can work on the global state in a chain.

anyone who thinks GHOST is a good idea, has not understood Bitcoin at all. the whole point of the blocks is that nodes can work on the global state in a chain. so the idea that nodes should work on greedy subtrees is about the worst possible idea. Bitcoin solves not only the Byzantine generals problem, but a latency variance problem, to achieve logical broadcast. anyway, the author of this paper also believes that "anyone with reasonably high intelligence could have invented Bitcoin by random luck" [1]. well, no. there are many hidden problems which Bitcoin solves. the literature on quorum systems, distributed applications, etc. is very deep. [1] http://www.reddit.com/r/Bitcoin/comments/20oyes/brilliant_and_comprehensive_smackdown_of_leah/cg5ikzo http://www.reddit.com/r/Bitcoin/comments/20oyes/brilliant_an...

oleganza 13y ago
Could you pls expand on this: "Bitcoin solves also a latency variance problem, to achieve logical broadcast"?
- bachback 13y ago
  how does one node know what other nodes are doing if latency between the messages could be anything between 50ms and 5000ms? if one node has a good position in the network it would know more than other nodes and outpace the network. which is exactly what would happen with ghost. the ghost authors have bound estimations on latencies, overlooking the possibility of information arbitarge. somebody would figure out where the most information comes from and arbitrage the network. so besides hashing attacks there are "latency attacks", but they don't even appear in Bitcoin, because blocks solve that issue. latency is negligible vs. the 10-minute block time. this could be shown with a timing attack on an alt-coin with < 60 sec blocktime. Lamport's work make this connection obvious. He invented the Byzantine Generals Problem and wrote this paper: "Time, Clocks, and the Ordering of Events in a Distributed System", Communications of the ACM 21, July 1978 http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/t... logical broadcast means: every node has the same state (time invariance). the only thing that matters is hashing power.
gone35 13y ago
Completely agree. Judging from the technical description [1] and the most recent version of the draft white paper [2] alone, I think the project would benefit greatly from more substantial input and expertise from the academic cryptography community. I'm afraid they are spending a lot of effort cargo-culting on the wrong things, while missing where the real challenge lies: How to deal with the inevitable orders-of-magnitude increase in transaction size/complexity while preserving consensus-based distributed verification. To be more precise: The metered computation mechanism is a very clever solution for dealing with unrestricted computation and unbounded data storage, but their proposed solution does not convincingly address the inevitable increase in space required. Hand-waving about greedy subtree verification without actual numbers/scenarios that shows this could work at all (which would be very surprising to say the least) is not convincing. In all a great idea, though. It would be great if it works out. [1] http://gavwood.com/Paper.pdf http://gavwood.com/Paper.pdf [2] https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft
- vbuterin 13y ago
  > I'm afraid they are spending a lot of effort cargo-culting on the wrong things, while missing where the real challenge lies: How to deal with the inevitable orders-of-magnitude increase in transaction size/complexity while preserving consensus-based distributed verification. Umm... that's exactly one of the issues that we're cargo-culting about the most. There are two general categories of solutions to this problem: technical increments (ie. a better constant factor), and fundamental cryptographic upgrades (eg. the stacktrace challenge-response concept we have been talking about on our blog). The first category we are not yet doing because we are following the well established advice of "don't prematurely optimize". The second category, well, that's why we're thinking of ideas like distributed blockchain storage, clever algorithms to force more people to be full nodes, and challenge-response protocols. There is also another idea I was thinking of, which I'll have a post up over the next week or two. In the long term, we are already beginning the development of a very widespread collaboration with academic groups to try to tackle the problems in cryptocurrency, and at this point we fully expect we'll end up releasing Ethereum 2 at some point in 2016 which would take a lot of new cryptography into account.
vbuterin 13y ago
Bitcoin "solves" the problems behind Byzantine fault tolerance, quorum systems, etc by completely ignoring the past 30 years of research on the topic, and introducing a very simple construction that bypasses all of the issues entirely by using the concept of proof of work. Don't get me wrong, Bitcoin is a brilliant idea, but it's the sort of brilliant idea which is actually more likely to come to you if you were NOT bogged down by existing research on how to do things. Satoshi's primary gift was not deep knowledge, it was a fresh perspective. And I am not saying these things because Ethereum is a super-magic-brilliant protocol that involves deep knowledge about thirty years of development in multiple fields; it's not. It's also an ultimately fairly elementary idea that I still remain surprised that nobody tried to seriously push before me. In fact, at least two other groups got very close in 2012-2013, and a few weeks ago at the payments innovation conference in Boston I learned that apparently the concept sans blockchain was around in the 1990s; but for some reason they did not take the idea to its logical conclusion. Also, our implementation of GHOST does not in any way compromise the concept of global state; blocks are required to specifically include uncle headers in order to benefit from them.
- bachback 13y ago
  I would suggest to run a simulation where nodes are globally distributed and have various latencies with high variance, and then study this problem of non-uniform distribution of information. with GHOST nodes would cluster in physical locations (say Iceland). the latency between those heavy nodes would be very low, and the latency to say Australia very high. the heavy nodes could then co-opt the network. it does not help if the authors proves a bound of latency, because this imbalance would destroy the network. with geographically skewed distribution of information, one can imagine all kinds of weirds effects and attacks. perhaps I'm wrong and will find out this actually works, but even then robustness requires safety over the longterm in very unexpected cases.
  - vbuterin 13y ago
    The information distribution should not be any more skewed than Bitcoin because every block can be validated by itself assuming only the validity of its parent as prior knowledge. This differs from the Israeli authors' GHOST, which assumes that nodes already have the uncles; in our system, uncles are included in the block. But we are definitely going to be doing various kinds of network simulations to make sure that every network protocol we push out is stable and convergent.

oleganza 13y ago

Could you pls expand on this: "Bitcoin solves also a latency variance problem, to achieve logical broadcast"?

bachback 13y ago
how does one node know what other nodes are doing if latency between the messages could be anything between 50ms and 5000ms? if one node has a good position in the network it would know more than other nodes and outpace the network. which is exactly what would happen with ghost. the ghost authors have bound estimations on latencies, overlooking the possibility of information arbitarge. somebody would figure out where the most information comes from and arbitrage the network. so besides hashing attacks there are "latency attacks", but they don't even appear in Bitcoin, because blocks solve that issue. latency is negligible vs. the 10-minute block time. this could be shown with a timing attack on an alt-coin with < 60 sec blocktime. Lamport's work make this connection obvious. He invented the Byzantine Generals Problem and wrote this paper: "Time, Clocks, and the Ordering of Events in a Distributed System", Communications of the ACM 21, July 1978 http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/t... logical broadcast means: every node has the same state (time invariance). the only thing that matters is hashing power.

gone35 13y ago

Completely agree. Judging from the technical description [1] and the most recent version of the draft white paper [2] alone, I think the project would benefit greatly from more substantial input and expertise from the academic cryptography community. I'm afraid they are spending a lot of effort cargo-culting on the wrong things, while missing where the real challenge lies: How to deal with the inevitable orders-of-magnitude increase in transaction size/complexity while preserving consensus-based distributed verification. To be more precise: The metered computation mechanism is a very clever solution for dealing with unrestricted computation and unbounded data storage, but their proposed solution does not convincingly address the inevitable increase in space required. Hand-waving about greedy subtree verification without actual numbers/scenarios that shows this could work at all (which would be very surprising to say the least) is not convincing. In all a great idea, though. It would be great if it works out. [1] http://gavwood.com/Paper.pdf http://gavwood.com/Paper.pdf [2] https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft

vbuterin 13y ago
> I'm afraid they are spending a lot of effort cargo-culting on the wrong things, while missing where the real challenge lies: How to deal with the inevitable orders-of-magnitude increase in transaction size/complexity while preserving consensus-based distributed verification. Umm... that's exactly one of the issues that we're cargo-culting about the most. There are two general categories of solutions to this problem: technical increments (ie. a better constant factor), and fundamental cryptographic upgrades (eg. the stacktrace challenge-response concept we have been talking about on our blog). The first category we are not yet doing because we are following the well established advice of "don't prematurely optimize". The second category, well, that's why we're thinking of ideas like distributed blockchain storage, clever algorithms to force more people to be full nodes, and challenge-response protocols. There is also another idea I was thinking of, which I'll have a post up over the next week or two. In the long term, we are already beginning the development of a very widespread collaboration with academic groups to try to tackle the problems in cryptocurrency, and at this point we fully expect we'll end up releasing Ethereum 2 at some point in 2016 which would take a lot of new cryptography into account.

vbuterin 13y ago

Bitcoin "solves" the problems behind Byzantine fault tolerance, quorum systems, etc by completely ignoring the past 30 years of research on the topic, and introducing a very simple construction that bypasses all of the issues entirely by using the concept of proof of work. Don't get me wrong, Bitcoin is a brilliant idea, but it's the sort of brilliant idea which is actually more likely to come to you if you were NOT bogged down by existing research on how to do things. Satoshi's primary gift was not deep knowledge, it was a fresh perspective. And I am not saying these things because Ethereum is a super-magic-brilliant protocol that involves deep knowledge about thirty years of development in multiple fields; it's not. It's also an ultimately fairly elementary idea that I still remain surprised that nobody tried to seriously push before me. In fact, at least two other groups got very close in 2012-2013, and a few weeks ago at the payments innovation conference in Boston I learned that apparently the concept sans blockchain was around in the 1990s; but for some reason they did not take the idea to its logical conclusion. Also, our implementation of GHOST does not in any way compromise the concept of global state; blocks are required to specifically include uncle headers in order to benefit from them.

bachback 13y ago
I would suggest to run a simulation where nodes are globally distributed and have various latencies with high variance, and then study this problem of non-uniform distribution of information. with GHOST nodes would cluster in physical locations (say Iceland). the latency between those heavy nodes would be very low, and the latency to say Australia very high. the heavy nodes could then co-opt the network. it does not help if the authors proves a bound of latency, because this imbalance would destroy the network. with geographically skewed distribution of information, one can imagine all kinds of weirds effects and attacks. perhaps I'm wrong and will find out this actually works, but even then robustness requires safety over the longterm in very unexpected cases.
- vbuterin 13y ago
  The information distribution should not be any more skewed than Bitcoin because every block can be validated by itself assuming only the validity of its parent as prior knowledge. This differs from the Israeli authors' GHOST, which assumes that nodes already have the uncles; in our system, uncles are included in the block. But we are definitely going to be doing various kinds of network simulations to make sure that every network protocol we push out is stable and convergent.