The Verge Hack, Explained

Post by osteele » Tue, May 22, 2018, 5:54 PM UTC

nextstep wrote: post #6

>>>In both cases, this hack presents a strong argument for tending towards sticking to things proven to work and to be wary of overcomplicating things and thereby introducing unnecessary risks when people’s financial assets are involved. Which, I suppose, means two points for team Bitcoin. What? The same bitcoin that is betting everything on an untested and incredibly complex second-layer protocol called "lightning n…

Post by lawn » Tue, May 22, 2018, 6:12 PM UTC

osteele wrote: post #21

nextstep wrote: post #6

>>>In both cases, this hack presents a strong argument for tending towards sticking to things proven to work and to be wary of overcomplicating things and thereby introducing unnecessary risks when people’s financial assets are involved. Which, I suppose, means two points for team Bitcoin. What? The same bitcoin that is betting everything on an untested and incredibly complex second-layer protocol called "lightning n…

> instead of just scaling with larger blocks Blocks will need to be ~5TB to match Visa transaction volume. Some lightning network advocates are concerned about the effect that a size increase necessary to support even a fraction of this volume would have on mining centralization. Other concerns are listed here https://en.bitcoin.it/wiki/Block_size_limit_controversy and here https://en.bitcoin.it/wiki/Scalability_FAQ#…

Post by tromp » Tue, May 22, 2018, 6:35 PM UTC

gtrubetskoy wrote: post #20

tromp wrote: post #17

This hack results from a basic design error: for difficulty adjustment to work properly, the window of recent blocks it considers must be relatively immune to time stamp manipulation. In other words, the allowed timestamp drift must be much smaller than the adjustment time window. Bitcoin allows a 2 hour drift, but has an adjustment window of 2 weeks. In verge's case, both are identical, at 2 hours. This is an open i…

> In verge's case, both are identical, at 2 hours. Naive question - is verge adjustment window defined in block time (as opposed to "human" time)? because > Bitcoin allows a 2 hour drift, but has an adjustment window of 2 weeks. The adjustment window is technically 2016 blocks, which is about two weeks in human time, but can in theory vary greatly if mining capacity fluctuates.

Post by mannykannot » Tue, May 22, 2018, 6:44 PM UTC

danbruc wrote: post #12

EGreg wrote: post #4

This is because, in decentralized networks that obstinately refuse to grant any special authority to third parties, accurately enforcing time synchronization is no simple matter. That depends on what you’re going for. The concept of time is actually a local phenomenon, as relativity shows. To compare whether events A and B happened first, you must first trace some path from A and B to a third party C (maybe C = A or…

Relativistic effects are irrelevant at the level of precision required for running a system distributed across the surface of Earth, what you are describing is just due to a lack of properly synchronized clocks. Place an atomic clock at each node and there is no need for any C deciding the ordering of A and B. Alternatively you may also be able to use logical clocks like a Lamport clock or a vector clock to establish…

Post by danbruc » Tue, May 22, 2018, 6:49 PM UTC

mannykannot wrote: post #27

danbruc wrote: post #12

Earlier quoted context omitted.

Relativistic effects are irrelevant at the level of precision required for running a system distributed across the surface of Earth, what you are describing is just due to a lack of properly synchronized clocks. Place an atomic clock at each node and there is no need for any C deciding the ordering of A and B. Alternatively you may also be able to use logical clocks like a Lamport clock or a vector clock to establish…

Are Lamport and vector clock mechanisms robust in the presence of nodes controlled by bad actors, who may be colluding through a hidden network?