Bitcoin Lightning Nodes
WHY BITCOIN CAN ONLY BE AS FREE OPEN SOURCE…
A fundamental choice of Satoshi in the development of Bitcoin (that is rather rarely talked about) is the fact that Bitcoin is Free Open Source Software. Every cycle new users and developers become interested in Bitcoin and try to wrap their heads around it.
While software licensing and development process is not high up on the reading lists of rabbit hole entrants, it is not only important to the development of Bitcoin, but also crucial to the security of Bitcoin that users understand that Bitcoin’s security is a direct result of the freedoms granted by permissive free software licenses.
With the recent proliferation of Bitcoin software bundled in easy to use full node packages for non-technical ‘point & click’ users, the topic of why Bitcoin software must be free software is worth revisiting. The goal of this article is to lay out why Bitcoin can only be as Free Open Source Software and create awareness for the potential threat to the Bitcoin network that the widespread adoption of packaged Bitcoin software with non-permissive software licenses could pose.
“I’ve developed a new open source P2P e-cash system called Bitcoin.”
– Satoshi Nakamoto
On February 11th 2009 Satoshi announced Bitcoin to the forum of the P2P Foundation as “a new open source P2P e-cash system”. Up to that point, it was only the second mention of “open source” in Satoshi’s public correspondence, the first being in the release announcement of Bitcoin v0.1 to the Cryptography Mailing List a month earlier on January 8th 2009:
“Windows only for now. Open source C++ code is included.”
– Satoshi Nakamoto
The term “open source” was coined in 1998 by the Open Source Initiative, but the idea behind open source goes back to 1985 when Richard Stallman founded the Free Software Foundation. The focus is on what the recipient of software is permitted to do with the software.
“’Free software’ means software that respects users’ freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software.”
– The Free Software Foundation
Between then and now, the term “free software” all but disappeared and was more or less replaced by “open source”, which focuses on the practical consequences enabled by these licenses: surprisingly effective collaboration on software development. Even though the Bitcoin software is a prime example of free software, hardly anybody calls it that nowadays.
Instead, Bitcoin is mostly described as open source software – a term whose literal meaning does not convey the full meaning of the term and causes confusion among new Bitcoin developers. This is not to put any blame on anyone who uses the term “open source”, heck, even Satoshi himself preferred that label over “free software” when he announced it. However, and more importantly, the license he chose for the Bitcoin Software was a permissive free software license: the MIT License.
HOW DO BITCOINERS TRUST BITCOIN
When explaining Bitcoin to someone new, one of the early questions to answer is how Bitcoin users can trust the Bitcoin software, trust that it really does what it is supposed to do, that it doesn’t do anything else than what is supposed to do, and that it doesn’t have any malware that may, for example, steal user funds underhand.
The answer is: We don’t.
“Being open source means anyone can independently review the code. If it was closed source, nobody could verify the security. I think it’s essential for a program of this nature to be open source.”
— Satoshi Nakamoto
Bitcoin is Free Open Source Software after all and an important *part* of what that means is that the Bitcoin source code is not encrypted, hidden or exclusively available to a select few like in Closed Source Software; quite the contrary, it is open and publicly accessible for everyone to audit and reviewers are explicitly welcome to do so. This is a feature. Anyone can open the Bitcoin source code, read it, run it, review it and verify what the software does, that it does exactly that and nothing else than what it is supposed to do.
“Don’t trust, verify.”
Bitcoin Mantra
Many have done exactly that in the past 12 years: at the very most hackers have been looking for holes and weaknesses in the Bitcoin code, some of them motivated by the prospect of cashing in a huge prize money if they succeed in breaking Bitcoin; others to avoid such malicious exploitation that could mean a devastating blow for the network that they rely on and want to protect.
As a result, the Bitcoin code is (probably) the most reviewed code of all software in existence. If the source code was not available to the meticulous scrutiny and persistent review of countless examiners, no-one in their right mind would store any substantial economic amount, let alone $1 trillion, in Bitcoin.
“Open Source doesn’t just mean access to the source code.”
Open Source Initiative
But while the source code of Bitcoin being public is sufficient to describe Bitcoin as not Closed Source Software (CSS); public code is *not* a sufficient criterion to describe software as Open Source Software, even if the literal meaning of the term might imply just that.
Among developers it is widely known, that the term “open source” has poor semantics, as a misunderstanding arises whereby people think source code disclosure is enough to meet the open source criteria, when in fact it is not. To understand the meaning of Open Source, it is worth looking back at the origin of the term and why it came into existence.
“Open Source” was coined in 1998 in Palo Alto by the newly established Open Source Initiative (OSI). The declared intent for the neologism was to distinguish “the pragmatic, business-case grounds” that had motivated Netscape to publish their source code (with modification and redistribution permissive license) from the label “free software” that was older and advocated by the Free Software Foundation (FSF).
The open source movement was basically a fork of the free software movement, with the main factionalizing difference between the groups being the relationship to proprietary software. Advocates of the term open source are willing to coexist with proprietary software, while free software advocates maintain the vision that all software is a part of freedom of speech and that proprietary software is unethical, unjust and for some even outright evil.
OSI advocates therefore argued that the term “free software” was too loaded with “politics and philosophy” and that a less principled approach would attract more software users and developers.
So in essence, the rebranding of “free software” to “open source” can be described as a marketing stunt. A move that was soon regretted by OSI founder Bruce Perens for undermining the efforts of the Free Software Foundation.
“Most hackers know that Free Software and Open Source are just two words for the same thing. Unfortunately, though, Open Source has de-emphasized the importance of the freedoms involved in Free Software. It’s time for us to fix that. We must make it clear to the world that those freedoms are still important, and that software such as Linux would not be around without them.”
Bruce Perens (Founder of OSI, Author of the Open Source Definition)
IMPORTANCE FOR BITCOIN SOFTWARE
Leaving the historical anecdotes aside and focusing on the practical implications of the Open Source Definition and the Free Software Definition, it becomes apparent, that both definitions essentially require that the software license grants the same freedoms to its users, namely the freedom to study the software, to run the software, to modify the software and to share possibly modified copies of the software. (Minor differences disregarded for the sake of brevity and focus)
A major strengths of open source software lies in the collaborative nature of the development process. A unique collection of the most experienced and knowledgeable developers in the field have made Bitcoin Core the most trusted implementation in the space through years of collaborative work.
“Given enough eyeballs, all bugs are shallow”
– Eric S. Raymond
Open source development has proven to be the best remedy to buggy code as it leverages the power of the marketplace of ideas; by making the source code widely available for public testing, scrutiny, and experimentation, the process of bug discovery increases rapidly. This perk of open source development is especially crucial for Bitcoin – a software that seeks to be the base layer of a new global monetary system – an aspiration that hardly forgives bugs.
Open source projects are also more likely to attract reviewers. The motivation to audit code is a lot higher for developers if they are allowed to fix the bug they discovered without permission of the copyright owner, simply by forking the repository.
It is also worth noting, that the freedoms to modify and redistribute code gives open source developers the valuable strategic option to quit a project and move on to another without losing their code. If the code they wrote during an employment were not open source, the developer could not use the code that they themselves wrote in future projects without permission. By working on open source licensed software, the developer’s work becomes portable and past work is not lost.
Another benefit of Open Source is the decoupling of software from a single company. When a software is supported explicitly by one company, and the company goes out of business, then so too does the software. That’s not the case with open source. If a company that produces an Open Source software goes out of business, the code can be still used by others and if the license allows it, another company or community can take over and continue supporting the project. Open Source software is not bound to one single company; rather, it is free technology to be used and extended by anyone.
FREEDOM TO MODIFY AND REDISTRIBUTE IS CRITICAL FOR THE BITCOIN CONSENSUS MODEL
All of the above factors draw open source developers to Bitcoin, contribute to its technology enhancement and strengthen its security by increasing the amount of vigilant eyeballs on the code. This is existential for the quality of Bitcoin code given its aspirations and the socio-economic impact thereof. But the security of the Bitcoin network does not only rely on impeccable code.
The consensus model of Bitcoin is based on users being able to freely choose the code that they are running on their nodes to determine the rules of the network. This requires that users have the freedom to choose the software that they run which can only be achieved if the Bitcoin software is free to modify.
However, since users usually don’t have the technical capabilities required to modify the Bitcoin software according to their preference themselves, they rely on developers to do it for them. This in turn requires that the license must also be permissive to redistribute the software modifications by the developers so users can choose which code to run on their nodes.
Bitcoin’s decentralization comes from the peer-to-peer network of sovereign full nodes that run free open source Bitcoin software. While Bitcoin Core is the technological steward of the protocol, this status is bestowed only by the voluntary actions of Bitcoin users. Bitcoin Core cannot unilaterally force changes to the consensus rules of the network. If they tried to push code without consensus, the repository could simply be forked as the project is free open source software with a permissive MIT License. Here, the permissive license of the software is the user’s insurance against developers acting out of consensus.
If the license were not permissive i.e. restricting modification and redistribution of the software, users would have to trust that developers never push out-of-consensus code. Furthermore, the possibility that the software could be forked provides a check on developers to adhere to the development principles of Bitcoin and address all concerns raised adequately.
BITCOIN FULL NODE PACKAGES
In recent years, especially since the advent of the Lightning Network, node package projects emerged that bundled the Bitcoin Core software with an ever growing number of useful Bitcoin software tools for users to run on dedicated hardware devices like Raspberry Pi, Odroid or Rock64. The development of node packages was pioneered by the Raspibolt guide, which provides a step-by-step manual to set up Bitcoin Core and LND from scratch.
Thanks to the excellent descriptions, Raspibolt is a great way to learn the basics of command line interface and, while challenging and not suitable for those who get easily frustrated with computers, fairly doable even for non-technical users.
More convenient is the RaspiBlitz, that originated from the Raspibolt. It is a convenient scripted node package for users who have a focus on security and are comfortable with using a terminal for advanced features. More importantly, the ease of setting up a node with Raspiblitz opened the gates for many new node runners and directly contributed to the decentralization and resilience of the Bitcoin network.
Both projects use the MIT License, which means they are free open source software and anyone is allowed to use the code, modify it, improve it and release it. This allowed the Raspiblitz developers to iterate on the pioneering work of the Raspibolt project and make running a node convenient for more users. It’s worth repeating that more users running a self-sovereign node and verifying transactions are an existential necessity for Bitcoin, so it’s not a stretch to conclude that the freedoms provided by the Raspibolt license paved the way for the emergence of Raspiblitz and directly strengthened the decentralization and resilience of the Bitcoin network as running a node became convenient for more users.
IMPORTANCE OF FREE SOFTWARE LICENSES FOR BITCOIN NODE PACKAGES
The example of Raspibolt and Raspiblitz illustrates how free software licenses help the advancement of the Bitcoin ecosystem by allowing developers to iterate on the findings and code of others. But there is a more fundamental importance of permissive licensing for Bitcoin node package software specific to Bitcoin that is rooted in the nature of the Bitcon consensus model which depends on users to have the freedom to choose the software they run on their nodes.
Creative Commons licenses, for example, are generally not suitable for software and it is the explicit recommendation of Creative Commons License creators that it should not be used for any software, let alone consensus-relevant Bitcoin infrastructure software.
Unfortunately, Bitcoin node packages with non-permissive Creative Commons Licenses that restrict modification and redistribution are a thing. These projects are popular mostly among non-technical point & click users who are not proficient in modifying code themselves and therefore heavily depend on developers to provide the right code to them. Dependence on developers is not a problem per se, but dependence without the insurance of free software licenses is.
Without the insurance that developers from the Bitcoin community could fork the project, the users of a CC licensed package are dependent on the project’s maintainers – not sovereigns, but customers – left with nothing but the right to drop the product when push comes to shove, as the CC License makes it impossible for other developers to even fork the repository without violating copyrights.
But running at the mercy of a project’s maintainer is antithetical to the core principle of self-sovereign Bitcoin users as it negates the assumption of free users that the Bitcoin consensus model is built upon. It is therefore important that users and developers are aware and understand the implications of the license they choose to run on their node. Especially less technical users should pay attention to their software’s license and demand packages with permissive licenses to avoid lock-in to a package.
After all, the quest for better monetization of open source Bitcoin software does not have to come at the cost of losing user sovereignty. Lightning node packages have low transaction fee wallets built-in that allow for novel monetization models with micropayments that are worth to explore and experiment with. Developers should not underestimate the willingness of a free user community to reciprocate the gift of sovereignty empowering software and focus on making recurring donation options easy to use and customize. The dream of streaming money is possible today with the maturing of the Lightning Network and offers a solution to open source’s funding problem. Bitcoin node packages are ideally positioned to seize this opportunity in an elegant Bitcoin way. Theoretically, at least. It would be great to see it happen.
Special thanks to Kim Neunert and Kevin Ravensberg for their input. Featured raspberry pi image is from NEO GENESIS BITCOINIZATION, a love letter to the Bitcoin project and everyone pushing for it to reach it’s fullest potential.