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.
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).
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.
So by this point everyone in the Bitcoin community has heard about the collision attack on BU’s short IDs that are used for the propagation of XTreme Thinblocks, as well as Peter R’s rebuttal claiming the infeasibility of such an attack in practice.
Many in the Bitcoin community, including Rizun himself, are requesting that Maxwell release his collision-finding code to the public. I find this strange; coding such a collision attack is something that’s covered in Security 101 in most places, so there should be no surprises or novelty here unless Maxwell has found some strange new optimization.
So what would such code look like? Let’s take a look. I’ve released a full copy of the code here, so be sure to try it on your own machine. Note this is completely unoptimized code – optimizations amounting to several orders of magnitude of improvement are lurking virtually everywhere. This is only intended to give the general public an idea of what such code would look like.