• CSW is not the author of the Bitcoin White Paper.
• CSW is not the person who operated under the pseudonym Satoshi Nakamoto in the period 2008 to 2011.
• CSW is not the person who created the Bitcoin System.
• CSW is not the author of the initial versions of the Bitcoin software.

After years of gaslighting and harassment (I just noticed that my first post about this was from 2016, back when Gavin fell under his influence), I did not expect this much sanity from the legal system.

Remember: Craig Wright is a fraud. Not only that, but an all-out awful person that uses his fraud as a pretense to willingly ruin people’s lives. He deserves whatever is coming to him. Or, just to be forgotten.

Now that this is over, I might become more active in bitcoin development again. No promises though. The last few years have been difficult for me, for this reason and others. But it absolutely helps to have this out of the way.

This is not only a win for bitcoin, but for open source development in general. It’s good to remind copyright trolls that even if they have enormous financial backing and the willingness to forge pile after pile of documents, they will lose.

Here’s a copy of the whitepaper to celebrate: bitcoin.pdf (SHA256 b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553).

Copyright

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

I strongly regret it. It is a fool’s game in retrospect. The no-warranty clause apparently doesn’t hold up in court (at least in the UK). So, you’re, effectively, giving away an unlimited license to use your software for anyone to do with what they want, and they get to sue you for millions when it doesn’t work out.

All for trying to do a good thing.

growth

Bitcoin has grown a lot since I started contributing to it in 2011. Some arrangements that were acceptable for a small scale FOSS project are no longer so for one runing a 600 billion dollar system. Market cap is famously deceptive, but my point is not about specific numbers here.

One thing is clear: this is a serious project now, and we need to start taking decentralization seriously.

moving on

I realize I am myself somewhat of a centralized bottleneck. And although I find Bitcoin an extremely interesting project and believe it’s one of the most important things happening at the moment, I also have many other interests. It’s also particularly stressful and I don’t want it, nor the bizarre spats in the social media around it, to start defining me as a person.

spreading out

I will start by delegating my own tasks, and decreasing my involvement. I do not intend to stop contributing to Bitcoin, or even to the Bitcoin Core project, but I would like to remove myself from the critical path and take (even more) of a background role.

Note that we had a nice growth in development activity, and that maintenance of the code itself has already been spread over multiple people for a while. I’m not the most active maintainer. Looking at the number of git merges

bitcoin$ git log --pretty="format:%cn" --merges --since=2020-01-01 | sort| uniq -c
    313 fanquake
     51 Jonas Schnelli
    727 MarcoFalke
      7 Pieter Wuille
     65 Samuel Dobson
    363 Wladimir J. van der Laan

Only about 24% of the merges were done by me, last year.

plans

But there’s plenty of things left to figure out, from the top of my head:

• Decentralize distribution.

  • In the short run, transfer bitcoincore.org to an organization instead of private ownership. Reduce the “bus factor”.

  • I think it would be good if some other organizations set up mirrors, so there is less incentive to try to take bitcoincore.org down.

  • In the long run, move away from a website for code distribution completely. No matter who owns it, a website on the clearnet can be shut down with the press of a button, and it seems that the global internet is gearing up to make censorship increasingly easy. We need a decentralized web. For us, one option would be IPFS, which is starting to catch on. For the binaries themselves there’s already the option of downloading through torrents.

• Decentralize the release process, and release signing.

  • Delegate more parts of the release process. Other maintainers should be able to do a release without my involvement.

  • Rename the GPG key used to sign SHA256SUMS.asc to “Bitcoin Core release signing key”, instead of having it in my personal title. Make some construct so that N of M (minimally) trusted gitian signers doing a succesful build automatically results in a signed distribution.

  • Same for the native code signing for Windows and MacOS.

  • Even better in the long run would be to split up the keys, e.g. though RSA threshold signing, so that the whole process is geographically distributed.

• Decentralize the development hub.

  • It’s not clear whether github can be trusted to act in our interest in the long run. Although issues and PRs are backed up through the API, having to move somewhere else could give significant interruption in development. And hopping from provider to provider would be awful—ideally the whole thing would not rely on a central server at all. For this I’ve been watching the radicle project, a P2P distributed code collaboration platform. It’s not quite there yet, but seems promising.

Bitcoin is quite different in some of the requirements here from other FOSS projects, so we’ll have to develop some tools as we go. We could also, definitely, use some help here.

Some smaller things to consider:

• Find someone else who wants to do the IRC meeting chair instead of me. Or maybe rotate it between multiple people.

• Release (and release candidate) mails to the bitcoin-dev and bitcoin-core-dev lists will no longer be necessarily signed and sent by me.

• There’s some development specific tooling hosted by me (e.g. the PR notification bots on IRC and mastodon). As they are non-critical and only little time goes into maintaining them, I’m fine with this for now.

As for decentralizing Bitcoin’s node software itself:

• Carl Dong’s libbitcoin_kernel work. Bitcoin Core is a large monolithic project which includes the consensus code, which is much more critical than the other parts. The kernel would be an isolated part with well-defined interface, and at some point, its own review flow for changes. The difference with previous libbitcoin_consensus plans is that the kernel is stateful: it includes UTXO management and validation. It however does not include P2P, mempool policy, wallet, GUI, and RPC code. It could be re-used in different clients, to have more diversity in clients, but without the risks of a deviating consensus implementation.

Over the course of 2021 this will be my focus with regard to Bitcoin Core.

To clone anew, do:

git -c http.proxy=socks5h://127.0.0.1:9050 clone http://nxshomzlgqmwfwhcnyvbznyrybh3gotlfgis7wkv7iur2yj2rarlhiad.onion/git/bitcoin.git
cd bitcoin
git config --add remote.origin.proxy "socks5h://127.0.0.1:9050"

This assumes Tor proxy is set up on 127.0.0.1:9050 - the default. The last command is necessary to make sure that pulls for updating also go through the proxy. A full clone might be slow, so consider doing a shallow clone (--depth=10 or such) if not all of history is required.

Or if you already have bitcoin cloned:

cd bitcoin
git remote add orionwl http://nxshomzlgqmwfwhcnyvbznyrybh3gotlfgis7wkv7iur2yj2rarlhiad.onion/git/bitcoin.git
git config --add remote.orionwl.proxy "socks5h://127.0.0.1:9050"
# and then to pull changes: git pull orionwl master

To verify authenticity, always make sure that at least the top commit is correctly signed (get the maintainer GPG public keys somewhere else):

git log --show-signature

This is my personal reflection on recent events, and should not be seen as any official statement for Bitcoin nor Bitcoin Core.

Atmospheric toxicity

Day in, day out, there is trolling, targeted attacks, shilling on social media targeted toward us. I don’t know of any other project like this. I’ve seen developer teams in MMOs under similar pressure from users; but possibly this is even worse. There, there are avid disagreements about how the game rules should be changed, here people get worked up about changes affecting a whole economic system. And the people attacking are, in many cases, not even users of the software.

But it is even worse when many of those attacks are agitated by someone that purports to be part of your own project. Not just involved with, even leading projects whose developers and users are openly hostile to us.

Some development tasks are extremely complex and require focus over a long time. It is essential to be able to reduce distractions, by being at least sure that your own team has your back.

For those reasons over the last years we’ve tried to create a more sane and focused environment for developers to work in. Part of this is a restructuring of the project. A decoupling of the name “Bitcoin Core” from “Bitcoin”. Bitcoin is (understandably) seen as public property. No one owns the bitcoin system, it is supposed to be decentralized and intangible.

However Bitcoin Core is a software project run by a team of people working together, on an open source basis. People who choose for themselves who they want to work with, and who they don’t want to work with.

There comes a point when it is time to break ties with certain individuals which were formative in the beginning but have, over time, ossified and even come to be seen as a toxic influence. Especially if they haven’t partaken in active development for a long time.

Scams all the way down

On a different note, Bitcoin has unfortunately always attracted scammers (remember mybitcoin?), con artists (remember pirateat40?), as well as assorted opportunists of all kinds.

Bitcoin also has its own creation myth, with borderline-religious support by some.

But now something truly fishy is going on. Someone is claiming to be that creator, but is surrounded by technological and social trickery, based on backdated GPG keys, faked digital signatures, maybe classic bait-and-switch parlor tricks. Despite various red flags, many people are convinced that a certain person is the creator of Bitcoin. There is a larger confusion than ever where truth starts and where misdirection and scams end. I am extrememly concerned about this.

I wasn’t sure, and am still not sure how Gavin is involved in this. It is no longer likely that he was hacked, but at the very least he is confused. When we saw the blog post convinced he found Satoshi, the prudent thing to do was to revoke his ownership of the ‘bitcoin’ organization on github, under which the Bitcoin Core repository currently lies, immediately.

In the past he has stated that “Satoshi can have write access to the github repo any time he asks.”, so if he is absolutely convinced that this is Satoshi, there is a risk that he’d give away the repository to a scammer.

Least privilege

But in a way this was only the final straw. His privileges were seen as a liability by members of the project for a while (and not just because of proxy threats from Mike Hearn to shut down the project).

The principle of least privilege in computer security says that users, should only have access to the resources they need for the purposes that are essential to the user’s job.

This is not an idle concern, for us. Remember how the bitcoin sourceforge was hacked using Satoshi’s inactive account?

Gavin hadn’t done anything as a maintainer for a year or so, and before that he already was hardly active for a long time.

That’s perfectly fine, people move on to other things, other interests, no one is bound to this project for life. However, the world also moves on, and if you go on to other things you can’t expect to be able to come back at any point and that everything is in the same place where you left it. It was time to revoke those privileges anyway.

I have personally asked, in a phone conversation as well as in mail, Gavin various times to give up his privileges with the github project himself - and so have other people. The response was always that he’d “sleep on it”. Despite allegations of the opposite, this did not come out of the blue.

Crossing the Rubicon

So when the question comes up whether we should make Gavin maintainer again, my answer, and that of many others is a resounding “no”. For one, there is just no point, as he wasn’t acting as a maintainer for Bitcoin Core anymore in the first place, and in addition to that, many feel that we can be more productive if we separate our ways.