Vote Buying, On-Chain Governance, and Quadratic Plutocracy

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.


Anti-ASIC Forks Considered Harmful

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.


A candidate heuristic for covert ASICBoost detection on-chain

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 it

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.


Solidity anti-patterns: Fun with inheritance DAG abuse

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!


From AsicBoost to HF: Greg Maxwell on Bitcoin’s Path Forward

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.



On Soft Fork Security

This post is a publication of an old draft I had on the Ethereum soft fork and its security.  I chose not to publish the article at the time, but am releasing it now for public viewing.

Lots of fun with soft forks in the last few months, starting with the discovery of a potential DoS vulnerability in the proposed Ethereum DAO wars fork, followed by an analysis that suggests that Ethereum is inherently safer than Bitcoin against miner censorship on soft forks.  Even Ethereum’s founder Vitalik Buterin was quoted as reflecting on the results by saying “In my opinion, outside of the scope of this one narrow incident, the difficulty of implementing soft forks is a good thing; it means that a small mining oligopoly cannot engage in censorship (a property that Bitcoin does not have!) and that the only way to practically interfere with the protocol operation is a hard fork, and hard forks are, in my opinion, more democratic as the entire community and not just a few miners must participate”.

This blog post will cover my thoughts on just what this difficulty property that Bitcoin supposedly does not have entails, and how we can quantify it for general blockchains and blockchain applications.  I’ll lean on my reading of previous forks, and attack vectors previously discovered by the cryptocurrency community in their applications.  In the original series of posts that started this debate, HackingDistributed also notes that “… miners can still exclude transactions based on features that are easy to statically analyze: e.g. format, syntactic features, source addresses, etc.”  Part of this post will be spent determining whether only such transactions can be censored, and we will also address both why and how such transactions can be censored.  We will only cover soft forks.

This post contains only hypotheses meant for potential consideration in future discussions.  There is nothing that has been rigorously validated within, and as such the post represents my personal opinion alone.  We will focus specifically on a class of attacks on soft forks at the network and mempool level, where an attacker generates transactions valid under old rules and invalid under new rules and attempts to leverage these transactions to attack either new or old nodes.  Such attacks are similar to the attack on the Ethereum soft-fork previously described, and involve exhausting the mempool of nodes (and potentially overwhelming the relay network with transactions).

Other fork-specific attacks are possible and must be excluded through manual audit, but this class of attack is particularly devastating because it represents a general purpose DoS vector, a network partitioning vector, and in all cases is completely free to an attacker (as it relies on transactions that will never be mined).


How I learned to stop worrying and love ETC

This is an opinion post.  Please read it as such.  Usual disclaimer that this does not constitute legal or financial advice.

There is a particular brand of argument about the Ethereum/Ethereum Classic fork in the Bitcoin community that is both universally prevalent and demonstrably incorrect.  This is an argument that I’ve seen made by Bitcoin developers, miners, and vocal users ad nauseum.  The argument plays into fears in Bitcoin fork politics, and roughly proceeds as follows: The ETH/ETC fork event was a negative action that harmed the Ethereum community and its token’s underlying value.
A useful introduction to such anti-fork arguments in the context of Bitcoin can be seen in this slide.

In this brief article, I propose both a logical and an empirical argument that claiming these tenets apply to Ethereum is dead wrong.  Not only was forking the optimal action for the Ethereum community at the time, but it did not harm the community in any meaningful way (and may have benefited it in others!)

This article is targeted at explaining why the Ethereum fork was undeniably beneficial to Bitcoin users who may be unfamiliar with Ethereum; to Ethereum users, I’m likely preaching to the choir and will be contributing nothing new of substance.