This post is a continuation/expansion of a previous post, “On-Chain Vote Buying and the DAO Dark Ages“, published on HackingDistributed. In this initial post, we provided an efficient private vote buying infrastructure that could be used to arbitrarily alter stable game theoretic equilibria in any on-chain voting protocol by allowing votes, identities, and restrictions on behaviors to be bought and sold on an efficient, private, trust-minimizing market.
We also explored an attack on blockchain systems we called a “Dark DAO”, in which a network of incentivized participants pooled to form a vote buying or consensus attacking cartel that was opaque to outsiders. These attacks have implications on on-chain voting incentives, general blockchain security, and e-voting in the permissionless model (where users can generate their own keys using untrusted hardware).
We will now explore these ideas in the context of other complicating factors, such as direct on-chain governance for consensus rules, and schemes which explicitly allow for vote buying such as quadratic voting.
A super hot topic in the Ethereum/Monero/not-Bitcoin-cryptocurrency discussion space these days is the rise of ASICs for several coins: first Monero, then allegedly Ethereum, a coin that was designed to be and was sold as ASIC resistant. What are innocent coinholders to do in the event of such evil companies like Bitmain taking over decentralized mining ecosystems with their chips of doom?
In this post, I’m going to provide some counterpoints to the fervor that is gathering around repeated forks for ASIC resistance. I’m going to argue that in the long term, these games won’t improve specialization or economies of scale, won’t be a productive use of developer time, and may pose the risk of increasing centralization. Finally, and perhaps most disturbingly, they make attacks on cryptocurrencies cheaper, primarily for sophisticated and well-resourced attackers like nation states.
Covert AsicBOOST is a topic that for many requires no introduction. Today, we are going to discuss one possible form of potential on-chain evidence of covert ASICBoost use. We will justify the heuristic, explain in what cases it may lead to false positives (or negatives), and present some initial attempts at parsing the data we have available to try to tackle the following question: “Did any miner, at any point in its mining history, activate covert ASICBoost on chain?”.
This work was originally included in a draft technical report that was intended to analyze the issue in far more depth, though the creation of this report was abandoned due to lack of interest across my collaborators, and, to be honest, myself. I abandoned this work in April of 2017 (almost one year ago!), with a plan to get back to it and find some concrete, unbiased results. Being that this has never materialized, and I am unlikely to return to this problem in the future, I would like to present our preliminary directions to the community.
If you don’t understand Bitcoin mining, this post is not for you, as I won’t be providing any background.
Note that this does NOT represent finished, validated, peer reviewed, or otherwise substantiated work; read with a lot of skepticism and take any conclusions derived from such a heuristic with a grain of salt without RIGOROUS PEER REVIEW.
We forked the fucking currency. It all started when we forked the currency.
God, fuck. I don’t want to work today. Pass the babysuckers and their brainless oaf accessory-du-jour. I can’t stand those people.
The goggles. A ray of light shines through the kitchen… the sweep. If I can find the goggles I can make it.
When I wake up I feel naked. Not clothes-naked, but prison-naked. The type of naked where the guard makes eye contact on the john. No Monday morning Twitter, just exposure. The cold, concrete floor reminding you of what you’ve done to your life. Or at least what they think you’ve done. Putting the goggles on is like coming home.
It’s hot in Tokyo, but the air conditioner is doing its best. I sit in a friend’s tiny studio apartment. Tired, overworked, behind on deadlines. It’s a feeling that most in the Ethereum space know well. I promised myself that this was the week I wouldn’t work, but that wasn’t happening. The 1st Underhanded Solidity Coding Contest is coming to a close, and after all I had an idea. Months earlier, during a contract review for a client, I had an idea of a new form of antipattern that I felt was subtle, devious, and hard enough to notice that it might even make a wave in Ethereum at some point. I’d seen production, open source contracts publicly released on Github where the pattern was present in full, and often not exploitable by what I can only imagine is chance. But I’m an academic by trade, and there wasn’t quite enough here for a paper. So what better place for this exploit than the USC!
This is the latest in a series of posts on the equivalence of UASF and hard fork security risks. In this post, we take a recent Coindesk article and replace all instances of “UASF” with “HF”. The results read sanely. Another reminder that UASF without miner majority is a contentious fork, and carries security risks equivalent for all practical purposes to the corresponding hard fork.
THIS ARTICLE IS A PARODY, AND THE QUOTES CONTAINED THEREIN ARE NOT REAL.
As opposed to my usual impenetrable rambles, I’m going to keep this one short and sweet. Many claiming SegWit is a block size increase. Many claiming it is not. So what is it from the point of view of the only thing that matters here, the data structures in the code? Let’s answer that now. No references this time, because everything I’m claiming is obvious.