The drama surrounding the Bitcoin community reached a fever pitch a couple of weeks ago when the Asicboost “exploit” was revealed by Gregory Maxwell. This revelation exacerbated infighting between Bitcoin Core and Bitcoin Unlimited, especially since some have claimed that BU supporters have tried to block Segwit activation in order to take advantage of Asicboost’s 30% performance hike. However, many people reject claims that Asicboost is a “hack” or “exploit,” and instead they call it an optimization.
Bitcoin.com has had the opportunity to speak with a developer that has been researching Asicboost. We reached out to Jeremy Rubin to get his professional take on whether Asicboost is an exploit or an optimization, because he recently penned a fascinating article explaining its ins and outs. We also asked him to clarify for our nontechnical readers the differences between a hard fork and a soft fork.
ASICBOOST, Hard Forks and Soft Forks
Bitcoin.com (BC): Tell me a little about your background and history with Bitcoin and cryptography?
Jeremy Rubin (JR): I graduated MIT in 2016 with an SB in Computer Science and Engineering and a Masters of Engineering in Electrical Engineering and Computer Science. I wrote my thesis under Professor Ron Rivest. I first got into Bitcoin in 2011. In 2013, I did a project called Tidbit which aimed to replace ad-monetization with cryptocurrency mining. We became embroiled in a legal battle with the State of New Jersey. In 2014, I launched a project to distribute $100 in Bitcoin to every MIT undergrad. In 2015 I co-founded the MIT Digital Currency Initiative (the DCI) which, at its launch, employed Wladimir, Cory, and Gavin. That year I also co-founded the Scaling Bitcoin conference series and served as the first Program Chair. I am currently a freelance Bitcoin developer, contributing to Bitcoin Core, doing basic research on cryptocurrency, as well as teaching.
BC: What exactly is Asicboost and what is your history with it?
JR: I heard about Asicboost a while back, but didn’t pay much attention to it. I then read Greg’s email more recently and spent some time working through all the claims; I published my notes on the subject here. I have no other history with Asicboost.
Previously I did participate in an effort (led by Patrick Murck, Kat Walsh, and Elizabeth Stark, and others if memory serves) to coordinate opening up the patent space in Bitcoin. I don’t think that our patent system is very compatible with an open standards based technology community like Bitcoin. But I don’t recall anyone being aware of Asicboost at that time (the year prior to the announcement of Asicboost).
BC: Is Asicboost an optimization or exploit?
JR: In my opinion, Asicboost is primarily an optimization.
This is not mutually exclusive with it being an exploit; the difficulties around utilizing Asicboost and implications of certain ways of using Asicboost might lend itself to compromising the balance of hashpower on the network, but that is a separate, more involved, discussion.
It’s a little bit like asking if a knife is a tool or a weapon. In either case, it is a tool, but it’s weapon status is dependent on what it is used for.
BC: Judging by your article, it appears that Asicboost could be used by miners in a fair and useful way. Did I read this correctly?
JR: Yes. Asicboost, in both it’s overt and covert (I actually dislike that terminology) can
be used in a reasonable way. But I think Asicboost interacts with our understanding of Bitcoin in unexpected ways.
I dislike the terminology overt and covert. I find that dichotomy to be disingenuous to the problem underlying Asicboost. In my opinion, it is completely acceptable to have something like Asicboost covertly or overtly.
I prefer terminology such as Gnostic and Agnostic Proof of Work because I think that is closer to the heart of the matter. The chief consideration is the extent to which the optimization interferes with Bitcoin protocol development and Bitcoin’s consensus guarantees (i.e., if the Proof of Work is agnostic to the underlying protocol). If that bears out to be the case that the way Asicboost works is gnostic to the protocol, it’s going to require much more careful thought on how to compromise.
I believe Greg Maxwell’s proposal has a lot of the right ideas if miners use Asicboost in a protocol upgrade incompatible way, but I think that the suggested solution forces Asicboost to be more overt (by modifying the version bits) is deficient.
I’d like to see a solution that keeps Asicboost covert while making it compatible with protocol changes, but I know that Greg spent a fair amount of time making his proposal to be minimally disruptive to Asicboost so it’s unclear there is a better compromise.
I threw together a quick diagram. The current state of affairs, according to Greg’s e-mail is the black dot. Greg’s proposal moves it to the white dot. I’d like to see a solution that is the red dot. I can’t imagine wanting a solution like the ‘X’!
BC: What are the differences between a hard fork and soft fork?
JR: I think an easy way to think both hard and soft forks are like going to sleep and waking up in a Twilight Zone episode. In both situations, there’s something off or unexpected about how everyone is acting. A hard fork is a bit like waking up to everything being in a new language. You’ll obviously not be able to communicate. A soft fork equivalent would be eliminating double negatives from the language–you might not even notice that anything was different (until you try to tell someone, “I don’t want nothing”, and they don’t understand what you are asking for). So both bear risks, but in general a soft fork is designed to be less surprising and cause less network disruption. Both soft and hard forks are on a continuum, some soft forks look a lot more like hard forks, but the distinction I laid (hard fork: changing the rules; soft fork: tightening the existing rules) is generally accurate.
Do you believe Asicboost is more of an exploit or an optimization? Let us know in the comments below!
Images courtesy of linkedin.com, Jeremy Rubin, and Shutterstock