The Verge Hack, Explained
blog.theabacus.io
blog.theabacus.io
We're all capable of reading and recognizing well-written portions of the posted content.
It seems that getting your crypto-currency hacked gives publicity and boosts value! See also: the Experian hack.
In verge's case, both are identical, at 2 hours. This is an open invitation to difficulty adjustment abuse.
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.
Apparently, the adjustment window, which needs to be way longer than the allowed timestamp drift, is in fact way shorter...
This feels way too much against the rule of thumb that code consuming untrusted input should never be able to modify or control it's own configuration or binaries (or, more generally, trusted input). In this case, the attacker can hijack 50% - 100% of the configuration of the weighting algorithm. For bitcoin, you can control around 4% at most without risking immediate attention. Unless mining speed increases by a factor of 40 or 50 suddenly.
See https://www.reddit.com/r/btc/comments/428tjl/softforking_the...
>> Gates Only Work When They’re Raised
Well normally gates swing open and shut, maybe you mean some kind of portcullis, like in a castle? You have to raise those to open them. >> a gate that’s far too strong to break
>> through and too high to climb over —
>> this hack gets past it by finding a way
>> to lower it so close to the ground that
>> it can be stepped over
So now gates rise out of the ground? I don't think the author has seen an actual gate.1. start with a seed state.
2. non-deterministically choose the next step (e.g. submit a tx)
3. ask the system to prove the inverse of an invariant you want to check (e.g. hash power cannot fall below X% of total network power.)
Decentralized protocols have bugs; trust only what you can prove.
Great article.
Am I missing something? And here I thought having to hard fork your currency goes in the “not very secure” bin.
The only thing that comes to mind how something like that would be possible is if the news trends generated by this were somehow driving algorithmic trading .. either that or people investing in something they're just hearing of for the first time.. But even these possibilities don't seem rational.
It just doesn't seem to make much sense... unless the whole thing was being driven and pushed by some larger unknown actor with a lot of resources .. (state government, goldman sachs, etc.)
What? The same bitcoin that is betting everything on an untested and incredibly complex second-layer protocol called "lightning network" 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#General_Block_Siz...
No, it's on the order of 3 gigabytes. Visa claims they can handle up to 25k Tx/s.
226 B / Tx. 600 sec (10 min) per block.
(25000 Tx / s)(226 B / Tx)(600 s / block) = 3.39 • 10^9 B / block
Visa normally handled around 2k Tx/s, which would only require a few hundred megabytes per block.
*Source: 50,000 transactions per second, as of July 15, 2017
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 B if you really want) and then ask C which came first.
We had to deal with this when building our DLT. See this: https://intercoin.org/technology.pdf
For a large and complex network, events A and B which are very far apart cannot be compared in any canonical way. The larger the network the less they can be compared.
However, A can come before B relative to some reference point C.
That’s enough to achieve most things. The point is that you shouldn’t have a global and continuous sense of time in distributed systems. Leslie Lamport has developed many things including vector clock over the years to address this.
Our PTN is just the latest in a long line of examples.
When you say that you have “no need” for C once you have synchronized clocks, not only are you ignoring relativity but you are also ignoring the byzantine generals problem. If Han Solo can benefit from claiming he shot first, why would I trust his clock? If you’re implementing a video game or cryptocurrency in a byzantine resilient way, how exactly would you have a continuous global sense of time? Go ahead the floor is yours.
I am saying that you won’t be able to — local time is continuous and you should use that for comparisons.
It’s nowhere near as straightforward as you think to make global time work. You will find that “making sure nobody can or will cheat” will require exactly the kind of effort that will make the concept of a global timestamp meaningless. Also, why do you need a global timestamp in the first place? Upon further reflection you will probably realize that all your concepts of time actually require exactly what I said: two paths to the same local reference point, where a comparison is made.
Your ideas about global time are an illusion based on simplifying assumptions that are not true.
I never addressed what else is necessary to make this work in the presence of Byzantine faults. But I am also pretty sure that just sending information about events from A and B to C and asking C about the ordering is not sufficient, after all C may be faulty and give a wrong answer, change its mind after every query, or just not respond at all. Admittedly you did not provide many details, so I may very well totally misunderstand what you had in mind.
But, just to repeat, I am not really addressing the requirements of a Byzantine fault tolerant system, I am just saying that the special or general theory of relativity is not relevant for distributed systems on Earth.
I said that relativity is a special case of this principle that time is a local phenomenon.
A lot of the nonlocal effects in De Broglie Bohm theory become classical once you consider close-by objects and neighborhoods. They are just super correlated.
Why? We don’t know. But with so many correlations, you can compare way more easily between them.
https://www.wired.com/2016/01/quantum-links-in-time-and-spac...
So unless you can define or at least explain in more detail what you mean with »time (or space) is a local phenomenon«, we won't really get anywhere.
More seriously, if the name of the game is efficiency then a distributed ledger isn't the answer.
And if you're only looking for immutability, then time-stamping is already good enough (and available since the late 90s or so). I suppose you can use a Merkle tree and then proceed to put "Blockchain" in your marketing materials without technically lying.
600MB every 10 minutes is no sweat for even modest internet connections nowadays.
With technology like weak blocks and the lighting network and other side-chains the network can handle it no problem.
That's all pretty moot at the moment as BCH is averaging ~50kb blocks.
You are saying every merge in the core code protocol is trusted by you even if that code has not even been written yet.
Laszlo’s CPU had been winning, at most, one block of 50 Bitcoins each day, of the approximately 140 blocks that were released daily. Once Laszlo got his GPU card hooked in he began winning one or two blocks an hour, and occasionally more. On May 17 he won twenty-eight blocks; these wins gave him fourteen hundred new coins that day.
Satoshi knew someone would eventually spot this opportunity as Bitcoin became more successful and was not surprised when Laszlo e-mailed him about his project. But in responding to Laszlo, Satoshi was clearly torn. If one person was taking all the coins, there would be less of an incentive for new people to join in.
“I don’t mean to sound like a socialist,” Satoshi wrote back. “I don’t care if wealth is concentrated, but for now, we get more growth by giving that money to 100% of the people than giving it to 20%.”
As a result, Satoshi asked Laszlo to go easy with the “high powered hashing,” the term coined to refer to the process of plugging an input into a hash function and seeing what it spit out.
But Satoshi also recognized that having more computing power on the network made the network stronger as long as the people with the power, like Laszlo, wanted to see Bitcoin succeed.”
One can imagine the outrage it will cause if it happened today.