Jeremy Rubin's Blog

Here you'll find an assorted mix of content from yours truly. I post about a lot of things, but primarily Bitcoin.

categories: Bitcoin, Shenzhen Journey.

Templates, Eltoo, and Covenants, Oh My!

If you’ve been following The Discourse, you probably know that Taproot is merged, locked in, and will activate later this November. What you might not know is what’s coming next… and you wouldn’t be alone in that. There are a number of fantastic proposals floating around to further improve Bitcoin, but there’s no clear picture on what is ready to be added next and on what timeline. No one – core developer, technically enlightened individuals, power users, or plebs – can claim to know otherwise.

In this post I’m going to describe 4 loosely related possible upgrades to Bitcoin – SH_APO (BIP-118), OP_CAT, OP_CSFS, and OP_CTV (BIP-119). These four upgrades all relate to how the next generation of stateful smart contracts can be built on top of bitcoin. As such, there’s natural overlap – and competition – for mindshare for review and deployment. This post is my attempt to stitch together a path we might take to roll them out and why that ordering makes sense. This post is for developers and engineers building in the Bitcoin space, but is intended to be followable by anyone technical or not who has a keen interest in Bitcoin.

Bitcoin Eschews Roadmaps and Agendas.

I provide this maxim to make clear that this document is by no means an official roadmap, narrative, or prioritization. However, it is my own assessment of what the current most pragmatic approach to upgrading Bitcoin is, based on my understanding of the state of outstanding proposals and their interactions.

My priorities in producing this are to open a discussion on potential new features, risk minimization, and pragmatic design for Bitcoin.

Upgrade Summaries

Below follows summaries of what each upgrade would enable and how it works. You might be tempted to skip it if you’re already familiar with the upgrades, but I recommend reading in any case as there are a few non obvious insights.


Currently proposed as BIP-118.

APO provides two new signature digest algorithms that do not commit to the coin being spent, or the current script additionally. Essentially allowing scripts to use outputs that didn’t exist at the time the script was made. This would be a new promise enforced by Bitcoin (ex. “You can close this Lightning channel and receive these coins if you give me the right proof. If a newer proof comes in later I’ll trust that one instead.”).

APO’s primary purpose is to enable off chain protocols like Eltoo, an improved non-punitive payment channel protocol.

APO can also emulate some of the main features of CTV and could be made to work with Sapio, partially. See the complimentary upgrades section for more detail.

CAT (+ variants)

Currently no BIP. However, CAT exists in Elements and Bitcoin Cash as a 520 byte limited form, so a proposal for Bitcoin can crib heavily from either.

Cat enables appending data onto other pieces of data. Diabolically simple functionality that has many advanced use cases by itself and in concert with other opcodes. There are many “straightforward” use cases of cat like requiring sighash types, requiring specific R values, etc, but there are too many devious use cases to list here. Andrew Poelstra has a decent blogpost series (part 1 and part ii) if you’re interested to read more. In particular, with much cleverness, it seems possible one could implement full covenants with just CAT, which covers (inefficiently) most of the other techniques discussed in this post.


Currently no BIP. However, CSFS exists in Elements and in Bitcoin Cash, so a proposal for Bitcoin can crib heavily from either.

CSFS enables checking of a signature against a message and key from the stack without including any transaction data.

Use cases include oracle protocols, key delegations, a channel update invalidation variant (Laolu claims this can be tweaked to be fully non punitive like eltoo, but you’ll need to bug him to write it up), and (+CAT) full covenants.


Currently proposed as BIP-119.

CTV enables committing to a specific “next” transaction from script. This is the ability to make an unbreakable promise on chain which Bitcoin can enforce (e.g. “This coin can only be spent to my multisig, or my backup after a timelock”). This is a departure from normal script which is traditionally only concerned with restrictions on the sender, CTV imposes restrictions on the recipient. More technically, CTV is essentially the ability to embed a signature of a specific transaction inside of a script without needing any elliptic curve operations. The validation costs are low. For more advanced logic, you can nest multiple different CTV Hashes either using taproot or up to the script length limits in regular script.

CTV can be used for vaults, channels, and many other uses. There’s also Sapio which is a language and toolkit for creating many kinds of programs with CTV.

CTV compliments CSFS to be able to emulate APO-like functionality sufficient to build Eltoo, potentially making APO feature-wise redundant.

Comparative Analysis

Now that we’ve got the basics covered, let’s explore these upgrades comparatively across several dimensions.

Design Specificity

“Design Specificity” is a subjective measure of how substantially an upgrade could change from its current design while still meeting the features goals. It is not to be confused with security or safety. Ranked in order from most to least design specific, with non-exhaustive lists of design questions based on ongoing community discourse as well as my own personal understanding of what might be desirable.

  1. CSFS
  2. CTV
  3. CAT
  4. APO

Explanations & Open Questions:

  1. CSFS is very simple and there is essentially a single way to implement it. Three open questions are:
    1. Should CSFS require some sort of tagged hash? Very likely answer is no – tags interfere with certain use cases)
    2. Should CSFS split the signature’s R & S value stack items for some applications that otherwise may require OP_CAT? E.g. using a pinned R value allows you to extract a private key if ever double signed, using 2 R values allows pay-to-reveal-key contracts. Most likely answer is no, if that is desired then OP_CAT can be introduced
    3. Should CSFS support a cheap way to reference the taproot internal or external key? Perhaps, can be handled with undefined upgradeable keytypes. One might want to use the internal key, if the signed data should be valid independent of the tapscript tree. One might want to use the external key, if the data should only be valid for a single tapscript key + tree.
  2. CTV is a commitment to all data that can malleate TXID besides the inputs being spent, therefore CTV does not have much space for variation on design.
    1. Should the digest be reordered or formatted differently? If there were more data on what types of covenants might be built in the future, a better order could be picked. Some thought has already gone into an order and commitments that make covenants easier, see the BIP for more. It’s also possible the serialization format for the variable length fields (scriptsigs, outputs) could be changed to make it easier to work with from script. (Maybe, minor change)
    2. Should CTV include more template types? Possibly, CTV includes an upgrade mechanism baked in for new template types, so it is extensible for future purposes.
    3. Should CTV commit to the amounts? CTV does not commit to the amount that a coin has. Input-inspecting functionality should be handled by separate opcodes, as CTV would be overly restrictive otherwise. E.g. dynamic fees through new inputs would be harder: given CTV’s design it is not possible to detect which field did not match therefore it is not possible to script against unexpected amount sent errors without some compromise (e.g. timeouts).
  3. CAT is simplistic, and there are really few ways to implement it. However, because it requires some restrictions for security, there are difficult to answer open design questions:
    1. What is the appropriate maximum stack size CAT should permit? Currently the design in Elements is 520 bytes, the max general stack size permitted in script.
    2. Should CAT be introduced or SHASTREAM, SUBSTRING, or another variant? There is a strong argument for SHASTREAM because when constructing covenants (e.g. for use with CTV) based on TX data it’s possible for size of a data field (e.g., serialization of all outputs) to exceed 520 bytes.
  4. There are many tough questions that the community has grappled with during APO’s design and engineering process, generally asking how APO-like techniques can be made ‘Generally Safe’ given iit breaks current assumptions around address reuse.
    1. Should APO require chaperone signatures (in order to ensure that replay is not done by 3rd parties)? Current Answer: No, anyone is free to burn their keys by revealing them to similar effect.
    2. Should APO use key tagging to mark keys that can use APO: Current Answer: yes, APO should be “double opt-in” (both requiring a tag and a signer to produce such a signature)
    3. Should APO allow signing with the external taproot key: Current Answer: no, because it makes APO not “double opt-in”.
    4. Should APO optimize signing with the internal taproot key? Answer: default key 0x01 refers to taproot internal key, so it can be made cheaper if you’re going to need it without having to repeat the entire key.
    5. Should APO commit to the signing script? Answer: let’s do two variants.
    6. Should APO instead be a larger refactoring of sighash logic that encapsulates APO (e.g. sighash bitmasks)? Current Answer: No, APO is good enough to ship as is and doesn’t preclude future work.


This category covers how “safe” each change is ranked from safest to least safe. What makes a change more or less safe is how limited and foreseeable the uses are of a specific opcode, in other words, how well we understand what it can do or where it might interact poorly with deployed infrastructure.

  1. CTV
  2. CSFS
  3. APO
  4. CAT

CTV is the safest new feature since fundamentally what it introduces is very similar to what can be done with pre-signed transactions, so it is only a pivot on trust and interactivity. Where there is some risk from CTV is that addresses (or rather, invoices) that are reused might have the same program behind them which could cause unintended behavior. This differs from the reuse problem in APO because the problem is stateless, that is, if you verify what is behind an address you will know what exists and does not exist. E.g., two payment channel addresses will create distinct payment channels that updates cannot be replayed across. In contrast with APO, paying one APO using address twice creates two instances of the same channel, state updates from one channel can be used on the other.

CSFS is the next safest, it is just a small piece of authenticated data. CSFS and CTV are relatively close in terms of safety, but CSFS is slightly less safe given a remote possibility of surprising uses of it to perform unforeseen elliptic curve operations. This functionality already exists for up to 5-byte messages. A hash preimage revelation can emulate a signer compactly. Using binary expansions and addition could be used to allow signing of values more compactly (e.g., 2x16x32 byte hashes could be used to construct a signature of a post-hoc selected Sequence lock). Read more here. Therefore it is appropriate to think of CSFS as an expansion of the efficiency of this technique, reusability of keys, and the types of data that can be signed over. Although CSFS is famously used to build covenants by comparing a CSFS signature to a CHECKSIG signature and getting transaction data onto the stack, CSFS cannot do that without CAT.

APO. This is the next safest because APO has some questions around key reuse safety and statefulness of information. See the above description in CTV for why this is tangibly worse for APO than CTV. See more discussion of APO’s safety & design trade offs here.

CAT is the least ‘safe’ in terms of extant Bitcoin concepts as it is highly likely CAT introduces at least advanced covenants if added, especially in conjunction with the above opcodes, but may also enable other unintended functionality. CAT is a source of continual surprise with regards to what it enables in composition with existing opcodes, therefore a systematic review of composability and known uses should be done before considering it. That CAT was forked out by Satoshi is of limited relevance as the variant proposed for reintroduction would not have the vulnerability present initially.

Complimentary Upgrades

Pairings of upgrades can work together to deliver functionality that neither could alone:

  1. CAT + CSFS: full blown arbitrary covenants
    1. With arbitrary covenants you can deploy many different kinds of smart contracts which are out of scope for this article.
  2. CAT + CTV: Expanded covenants
    1. slightly simpler to use interface but fewer features than CSFS + CAT which can covenant over witness data and inputs.
  3. CTV + CSFS: Eltoo
    1. This can add very similar functionality to eltoo with the script fragment: CTV <musig(pka, pkb)> CSFS <S+1> CLTV The protocol is essentially identical to the Eltoo paper, however there are a couple subtle differences required for dynamic fee rates.
  4. CTV + APO: Slightly Different
    1. Several sources have claimed that APO offers a strict superset of CTV’s functionality (but not efficiency). This is false. Their digests are slightly different, as such there are some niche smart contracts that could use the differences in commitment structure for interesting effects (CTV commits to all scriptsigs and sequences, APO cannot cover that data but can cover a few variants of less data covered).

By all means not an exhaustive list – feel free to message me with additions.


My recommendation is to deliver the upgrades described in this document in the following order:

  1. CTV
  2. CSFS
  3. APO

This recommendation comes as a synthesis of the thoughts above on the composability, safety, and open design considerations of the various proposals currently in flight.

With CTV in place, we can begin experimenting with a wide variety of contracts using the Sapio toolchain, as well as improve and invest in maturing the toolchain. Mature toolchains will make it easier to safely engineer and deploy applications making use of CTV and future upgrades.

CSFS is an independent change that can be deployed/developed in parallel to or before CTV, the implementation from Elements could be easily ported to Bitcoin. With CSFS and CTV, Eltoo-like constructions will be possible as well.

APO can then be deployed as an optimization to existing use patterns driven by market adoption of CTV+CSFS based use. This also gives us time to kick the can down the road on the design questions that APO prompts around generalization of signature digests and key reuse safety. A similar approach was discussed on the mailing list, but without the insight that CSFS + CTV was sufficient for Eltoo like constructions, requiring CAT instead.

Lastly, OP_CAT can be delivered as part of an effort towards generalized arbitrary covenants and perhaps in conjunction with some special purpose opcodes (such as OP_CHECKINPUT) that can more easily handle common cases. CAT, although it has safe implementations used in Elements, deserves very strict scrutiny given it’s documented surprising uses.

This approach represents a gradual relaxation of Bitcoin’s restrictions around smart contract programming that introduces useful, safe primitives and gives the community time to build and deploy useful infrastructure. The path described in this post is an opportunity to upgrade bitcoin with simple primitives that compose nicely for permissionless innovation.

Thanks to those who reviewed drafts of this post and provided valuable feedback improving the clarity and accuracy of this post, including pyskell, Keagan McClelland, Ryan Gentry, and Olaoluwa Osuntokun. Edit + Feedback ≠ Endorsement.

Open Letter on Diversity & Inclusion at Scaling Bitcoin

ATTN: Scaling Bitcoin Participants and Sponsors

We started Scaling Bitcoin with a deep commitment to diversity and inclusion. Fundamentally, Scaling Bitcoin is about bringing together elements of the Bitcoin community that would not otherwise – many of the core contributors met face to face for the first time in Montreal. Meeting face to face was a fantastic opportunity to bridge divides and seek common goals; at Scaling Bitcoin spontaneous discussions broke out which would have never occurred online. Diversity and inclusion are key elements in pulling together different parts of our community to have the discussions fruitfully. Fundamentally Scaling Bitcoin exists to work towards eliminating any barrier to entry for any person to contribute to Bitcoin’s scientific and engineering ecosystem.

Diversity and inclusion are complicated multi-faceted topics – at Scaling Bitcoin, we do our best to address them from all sides. Our conference aspires to be in a different region every time, from our first event in Montreal, to Hong Kong, to Milan, and now, to Silicon Valley. Our participants and sponsors come from all over the world (18 countries at the last event!), speak many different languages, and have vastly different perspectives on how we’ll accomplish our shared goal of Scaling Bitcoin.

We help people attend Scaling Bitcoin who would not be able to otherwise as a part of our diversity and inclusion efforts. This help comes in multiple forms, including discounted tickets for students, as well as travel and accommodation assistance for those who require it. Our chief concern is getting the individuals most likely to contribute to Bitcoin’s scientific and engineering ecosystem to the conference. We also try to help those who face additional difficulties to better integrate into the community. In past Scaling Bitcoins, this has included efforts and special programming through our academic supporting organizations to better socially integrate low-income, minority, and female participants at Scaling Bitcoin. For example, at Milan one of our Academic partners (The MIT DCI) hosted a special dinner for the students from their summer bootcamp (you can read about it here) to get to interact with some core developers in a smaller group setting.

Bitcoin developers and scientists don’t just materialize overnight, it requires diligent study and effort. This is an intimidating prospect for almost anyone, and many capable developers drop out for lack of good support. Initiatives like Chaincode’s Hacker Residency and DGLAB’s BC2 workshop have been wildly successful in nurturing talented Bitcoin Core Developers. Scaling Bitcoin is simply doing our part to onboard more talent. Explicitly seeking to onboard talent from diverse backgrounds is a critical for engineering Bitcoin to be an empowering technology to meet the needs of users all over the world. The last several decades of research on the subject shows that seeking out social diversity leads to better decision-making across the board (read about the research here).

This year, as a part of our efforts to improve Scaling Bitcoin by better structuring our Planning Committee we created a Diversity & Inclusion Committee. This committee is comprised of individuals who were excited to help us to continue our efforts around diversity and inclusion. One of the main tasks for this committee is to help us review and process subsidy requests, which are awarded based on many factors, including, likelihood of contributing to Bitcoin’s scientific and engineering ecosystem, demonstrated need, and total cost (we have a limited budget, after all). Despite now having an explicit committee for diversity and inclusion, it continues to be the job of every volunteer in Scaling Bitcoin to work towards eliminating any barrier to entry for any person to contribute to Bitcoin’s scientific and engineering ecosystem. Different people experience different barriers to entry to a field like Bitcoin, thus, the kinds of support programs we offer are not always available to everyone (we can’t afford to give everyone student ticket pricing!). The Diversity & Inclusion Committee is there to ensure that our efforts are fair and sufficient.

Technology conferences like Scaling Bitcoin present a remarkable opportunity for building community. In light of recent reports of incidents of harassment and exclusionary practices at tech conferences, we’ve take a progressive stance on making sure that Scaling Bitcoin remains a respectful and safe space for all of our participants to build that community. Incidents of harassment and exclusionary practices negatively impact people of all genders, races, and backgrounds, as well as the conferences and their communities. We take such issues seriously and have required all participants to follow our Code of Conduct since the first Scaling Bitcoin event in 2015.

Part of what makes Scaling Bitcoin such a remarkable gathering is the intense level of focus on the technology during the event. Our CoC exists to minimize the possibility of distractions and to maximize the learning, shared understanding and technical advancement of one of the most important engineering projects of our time. We hope that our attendees recognize and support that objective, and the organizing committee will as well.

Additionally, the Program Committee, which handles talk selection, operates with complete autonomy from the rest of the Scaling Bitcoin organization, including the Diversity & Inclusion Committee. No one is excluded from the conference as a result of our diversity and inclusion efforts. The main goal of the Program Committee is to unbiasedly select talks with the highest potential impact on Bitcoin. The majority of tickets are sold openly to the public. We welcome any suggestions and ideas from the Bitcoin community as to how our efforts can be more effective and we will continue to do our best to make Bitcoin a more diverse and inclusive environment.

We’re excited to be hosting what we expect to be the best Scaling Bitcoin yet this year. To increase our reach and impact in the community, we’re hosting a 2 Day tutorial preceding Scaling Bitcoin called Dev++. This is a wonderful opportunity for those just entering the space to get fast-paced high-quality instruction on becoming a Bitcoin Engineer. Following the conference, we will have a Career Fair and an event for startups to pitch to investors. You can read more about these new initiatives at


Jeremy Rubin

Scaling Bitcoin Planning Committee

With special thanks to Byron Gibson, Neha Narula, and the rest of the Scaling Bitcoin Planning Committee for reviewing and editing this letter, and for maintaining a strong commitment to diversity and inclusion in Bitcoin.

United States Government Censorship of Fuck Nazis Virtual Lapel Pin

My Right to Say "Fuck Nazis"

When I woke up in the morning of September 1st, 2017 I immediately began my morning ritual of lazily glancing through emails. On this morning, one particular email stood out — the Fuck Nazis Virtual Lapel Pin had been censored by the United States Government.

Let’s jump back a minute for some context.

On August 19th, 2017 I began a new project, the Fuck Nazis Virtual Lapel Pin. The project’s goal was to raise funds to resist the recent uptick in Nazism and other forms of violent racist extremism in America. The Fuck Nazis Virtual Lapel Pin is a unique fund-raiser because donors quid-pro-quo receive a digital asset in return for their contribution, I hoped this would harness the excitement around the emerging “Initial Coin Offering” phenomenon.

The reception was not as positive as I had hoped it would be — earlier in the week, I had been subject to some minor censorship by the Ethereum Maintainers and Community Moderators.

On September 1st, 2017 at 2:40 AM Pacific Daylight Time Neustar initiated a transfer of my domain. One hour and 29 minutes later Neustar sent me an email explaining the transfer.

The Takedown

The Takedown

I’ve sent Neustar an email requesting that they reinstate my registration, but I’ve not yet heard back from them.

Request to Reinstate

Neustar is a contractor hired by the U.S. Governemnt to operate the .us TLD. Because they are managing a federally owned property, I beleive they are obligated to follow the First Amendment with respect to registered names. Otherwise, I do not think the FCC may legally continue to use them as a contractor. To quote ICANNWatch:

[W]hile a private entity like Neustar is under no intrinsic obligation to respect the First Amendment, the fact that they did this under government consultation, and pursuant to a government-granted charter to operate the country code registry for the United States, raises serious issues of Constitutionality.

It’s not a strange expectation to hold that contractors of the United States Government must abide by constitutional provisions. For instance, private prisons are not at liberty to exact cruel and unusual punishments. Kimberly N. Brown delivers a thorough treatment of this in “We the People,” Constitutional Accountability, and Outsourcing Government. While there are controversial cases, it is generally clear that public actors must hold accountable private actors that they delegate their constitutional powers to.

Notwithstanding the concern over whether it is the FCC or Neustar who is legally culpable, we can safely assume that the FCC is bound to ensure that Neustar respects constitutional rights in fulfilling their duties as a government contractor, and therefore examine Neustar as a government actor.

Neustar’s management policy document can be found here. The relevant sections are B-78 and B-98. Neustar claims that they will review domains which contain the “7 Words” and possibly delete them (presumably, ensuring that they are not violating the registrant’s First Amendment rights). Their claim is that the domain violate’s the “7 Words” policy enforced by Neustar. (This is a reference to George Carlin’s infamous Seven Dirty Words skit) In this case, the presence of “fuck” in the domain is what alerted Neustar to need to review my domain. However, in failing to waive I believe they violated my First Amendment rights.

There are three major relevant Supreme Court cases here, Cohen v. California (1971), Miller v. California (1973), and FCC v. Pacifica Foundation (1978).

In Cohen v. California, a man was arrested for disturbing the peace for wearing a “Fuck the Draft” shirt. In this case, the speech was found to be protected by the First Amendment for multiple reasons. Most relevantly, the court refused to recognize the speech as “Fighting Words”, or speech intended to elicit violence. This is because Cohen’s voiced dissent of the draft was not intended to elicit any violence, it was simply to voice an opinion. Similarly, the material published on the Fuck Nazis site was clearly in support of non-violent action, e.g.

As a first measure, and irrespective of what is most effective, I want to use funds raised ensure that it is possible to protest these Nazis as safely as possible. No one should permit the Nazis to intimidate them out of their freedom to speak against them.

along with a list of other non-violent actions I would use the funds raised to support. The court went further to find that

Finally, and in the same vein, we cannot indulge the facile assumption that one can forbid particular words without also running a substantial risk of suppressing ideas in the process. Indeed, governments might soon seize upon the censorship of particular words as a convenient guise for banning the expression of unpopular views. We have been able, as noted above, to discern little social benefit that might result from running the risk of opening the door to such grave results.

This makes it clear that the censorship of Fuck Nazis Virtual Lapel Pins by revocation of the domain is unconstitutional.

Miller v. California is a case of a very different nature involving the distribution of pornographic content, but it established a simple three-prong test for unprotected explicit speech. If you pass all three tests, then the work is considered obscene.

(a) whether “the average person, applying contemporary community standards” would find that the work, taken as a whole, appeals to the prurient interest.

Fail: Fuck Nazis is clearly non-pornographic and elicits no sexual response.

(b) whether the work depicts or describes, in a patently offensive way, sexual conduct specifically defined by the applicable state law.

Fail: Fuck Nazis is clearly non-sexual.

(c) whether the work, taken as a whole, lacks serious literary, artistic, political, or scientific value. If a state obscenity law is thus limited, First Amendment values are adequately protected by ultimate independent appellate review of constitutional claims when necessary.

Fail: Fuck Nazis is a political and artistic project, and is presented cogently.

Having clearly failed all three tests, Fuck Nazis is non-obscene protected speech by all measures.

Critically, both Cohen v. California and Miller v. California are both rulings with regards to the state’s ability to restrict speech. Only FCC v. Pacifica Foundation deals with the federal government’s ability to restrict “obscene” speech, which established the “7 Dirty Words”.

The critically relevant part of FCC v. Pacifica Foundation is that the measures enforce by the FCC (to only broadcast during hours children are unlikely to be awake) did not prevent adults from accessing and finding the content. In this case, Neustar’s actions against Fuck Nazis does prevent adults from accessing the content unadulterated (whereas the time restriction enforced by the FCC permitted identical material to be broadcast at a reasonably later time). Furthermore, based on Neustar’s enforced policies I would be able to register the domain “” (if it were available — it’s been held since 2014) and use the subdomain “fuck” giving me the “” domain. This makes the case that there is zero benefit from the measure taken by Neustar, at the expense of the significant burden of forcing me to change a domain that I have already linked to in numerous communications. Of greater concern is the general freedom of speech risk established by this enforcement mechanism.

Based on the above, Neustar, acting as an agent of the United States government, plainly violated my First Amendment rights causing damages to my project that are difficult to quantify given that the fund-raiser I was hosting on the site is ongoing.

Censorship by Ethereum Maintainers

The Ethereum Maintainers and Moderators inexplicably took actions to censor the Fuck Nazis Virtual Lapel Pin.

When I posted the project to the Ethereum subreddit on August 26th (here) it faced an immediate barrage of negative attention from the Ethereum community. I can tolerate negative reception, but I can’t tolerate censorship.

One of the negative response I noticed a few days after posting was Vitalik Buterin (the infamous founder and lead maintainer of Ethereum) liking a libelous tweet which called my project “a shameless attempt at scamming people”. I typically interpret a like on Twitter as at least a weak endorsement (the twitter-meme “RT not endorsement” can be taken to imply that while retweeting is not endorsement, maybe liking is).

Vitalik likes a libelous tweet

From my perspective, Vitalik’s implicit endorsement of a libelous message claiming that I am perpetrating fraud with Fuck Nazis is the only shame-worthy action! From day one Fuck Nazis’ course of action has been focused on many charitable causes, including:

  1. Donations to organizations like the Southern Poverty Law Center and the Anti-Defamation League.
  2. Sponsoring guards for synagogues who are denied publicly funded police details.
  3. Workshops on how to non-violently oppose Nazis in cities where they are staging demonstrations.

After Vitalik liked the above tweet, I noticed that my post was censored from /r/ethereum by the moderators (Vitalik is also the lead moderator of /r/ethereum). This censorship occured days after it had been on the front page, leading me to believe it was removed for no logical reason other than distaste for the issue involved.

Removed from /r/ethereum

I met Vitalik back in 2014, in the very early days of Ethereum, so I was willing to give him the benefit of the doubt on the post removal. I shot him an email on August 29th and again on the 31st but he is yet to respond.

No Response

His lack of response to me signals, but does not confirm, that it was him who censored Fuck Nazis and he is unwilling to justify his actions to me directly.

The Ethereum Foundation and affiliated contributors have no legal requirement to grant me free speech as a private organization.

That said, they do have a moral responsibility to protect free speech and to be inclusive of many different kinds of people within their community. By actively censoring my post on Fuck Nazis, they have chosen to signal their alignment with a racist agenda and cause a chilling effect on future social impact projects on Ethereum.

Their attempted censorship runs counter to the philosophy stated on

Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.

While certainly Reddit doesn’t attempt to make the same censorship guarantees as Ethereum, it’s difficult to imagine that if the leader of the development team behind Ethereum is engaged in censoring causes spitefully on Reddit that he will lead the team to fulfill the promises laid out in their statement.

Vitalik (and others in the Ethereum Foundation) must make clear their strong intention for building inclusive and tolerant community with explicit actions to improve the situation. Until sufficiently addressed, the entire community must continually push leaders of the Ethereum community for more information on how they plan to treat similar issues in the future.

This isn’t about getting an apology for censoring the Fuck Nazis thread, it’s about not building technologies that put power into the hands of hateful people who will use their power to infringe on your human rights.

Overall, this is the least of my worries currently: the Fuck Nazis Virtual Lapel Pin project is currently facing ongoing censorship from the U.S. Goverment as well. But I figured it was worthwhile for me to write up this post so that the Ethereum community can respond accordingly.

Drawing the Blockchain

This is correct

One of my major pet peeves in presentations about the blockchain is that most people seem to draw the arrows/pointers in the incorrect direction.

Pointers should point from newer blocks to older blocks. This is because in a blockchain, each block is immutable so it would be impossible to update older blocks to point to newer ones. This is also in line with most singly linked list representations. Because it can be confusing, it’s always best to include reference heights for extra clarity.

© 2011-2021 Jeremy Rubin. All rights reserved.