FULMO Blog | Building the Lightning Network

Bitcoin LightningATM – Pocket Edition construction guide

August 5, 2022August 5, 2022
by Tim

The LightningATM is a fully functional Bitcoin ATM and demonstrates the power of the Bitcoin Lightning Network. It accepts Fiat-Coins and gives you back precious Satoshis (SATS). Thanks to Lightning even small amounts can be exchanged with near-zerofees. The LightningATM is the perfect Showcase on every Meetup, Conference, or in your Office to onboard more people in a fun way to Bitcoin.

In this guide, we put together our knowledge and give you a guide to assemble the LightningATM construction set which you maybe bought in our shop. But even if you purchasedall the parts by yourself the guide should be helpful. Besides our documentation,you find excellent tutorials and videos on the official Bitcoin LightningATM wiki and in our first guide. If you prefer to have a tutorial in german I can highly recommend the great tutorial at Ereignishorizont.

This guide is divided into five sections:

overview LightningATM hardware components
hardware assembly guide
Software setup LightningATM
Software setup lntxbot
your first exchange

Important: All the hardware assembly and software setup/usage you are doing at your own risk!

LightningATM hardware components

Before you can put together the different hardware components you should haveat least the following tools for the proper construction of the ATM at hand:

small screwdriver
voltmeter
one insulated plier (alternative: sharp knife)
soldering iron (optional)

If you don’t have a voltmeter at hand maybe ask in a hacking space near you before you purchase one, they should have one. You need the voltmeter just to tune thevoltage transformer once.

All the parts you need for the ATM are the following:

3D printed case
Coin Acceptor
Raspberry Pi Zero
Jumper Cables
Power Converter
ePaper – Display
Micro USB Cable
Micro SD Card
Screws

We recommend using the Version 2 of the Waveshare 2.13inch display. Otherwise, you can face problems in running the demos from Waveshare library and the ATM software itself. Please check the back of the display for a “V2” sticker.

When you have all parts together let’s get our hands dirty and let’s assemble the components.

Hardware assembly

Micro USB Cable

Let’s start with the preparation of the Micro USB Cable. With some luck, you got already the Micro USB / USB Type-A version with open wires. Lucky peep, no work for you. If you got one complete Micro USB / USB Type-A cable you have to cut it in half. The cable with the Micro USB head should be around 12 cm.

You have to uncover the electrical conductors and can also remove the data conductors (green and white) from the cable if you want. For the best possible result and to have it easier for the connection with the power converter, you should solder the conductors. But no worries if you haven’t a soldering iron you can just twist the conductors and bring them in shape.

Prepare the power converter

If you have your UBS-Cable prepared you can now connect it to the IN ports of the power converter. The black cable has to be connectedto IN(-) and the red cable to IN(+). If the cable is connected to the converter you have to adjust the resistor to get the proper poweron the outgoing connections of the converter.

CAUTION! IN THE NEXT STEP!

The converter could have high voltage on the OUT ports.

Connect the USB-Cable head to a power bank or 5V battery and put the voltmeter at the OUT(-) and OUT(+). Now adjust the little golden screw as long as you have 12,1V on the voltmeter. You must have exactly 12,1V. If the voltage is too high, you could destroy the coin acceptor. Remove the voltmeter from the OUT port and add two jumper cables to it.

Prepare the coin acceptor

Now you can connect the jumper cables with the coin acceptor. The red jumper cable goes to DC12V and the black jumper cable goes to GND.

Configure and teach the coin acceptor

When you finished the previous steps your setup should now look something like this, except for the power supply:

Now it’s time to configure the coin acceptor.

If you prefer a more visual guide for the configuration and for the teaching of the coin acceptor you should check out the following video from 21isenough: https://youtu.be/14JfEhNSdZE?t=1413

Following the steps for the configuration.

Set the two step switch on the coin acceptor to “NO”
Set the three step switch to “Medium”
Press and hold the ADD and MINUS button at the same time until A appears in the display
Press the SET key and hold it for a short time, then E appears in the display. This indicates that you are now in the menu for the number of different coin types
Use ADD (or MINUS) to set the number of coins to 6 (coins = 5 cents to 2 euros) and press SET
Now the display shows H1 (for first coin) and the first of 6 LEDs should be active
Now indicate how often the coin should be inserted for calibration. Set to 20 with ADD (or MINUS) and press SET
The display now shows P1 for further settings of coin 1 and you can define the output signal 5 cents = 2 pulses / 10 cents = 3 pulses / 20 cents = 4 pulses / 50 cents = 5 pulses / 10 euros = 6 pulses / 2 euros = 7 pulses
Set with ADD (or MINUS) to 2 pulses (for 5 cents) and then press SET
The last thing on the display is F1, which stands for the accuracy of the coin detection. The value 8 worked well
Use ADD (or MINUS) to set to 8 and then press SET
The parameterization for the first coin is now done and the next 5 coins must follow
Now the second LED is on and the display shows H2
Repeat the same steps for the second coin up to 6 coins
If all coins are set, all LEDs flash briefly to confirm and the display shows A again
After a short time the display shows 0 (zero) again

If the steps were successful you can calibrate now the coin acceptor.

Press the SET key twice
The first LED light and A1 appears in the display
Now insert the first coin (5 cents) 20 times.
It is recommended to use as many different coins of the same type as possible
After all that the LEDs will flash and the display will show A2
Repeat the procedure for the remaining coins
All LEDs flash again briefly for confirmation and the display shows 0 again

Now the coin acceptor is ready.

Prepare the display

The next step is the preparation of the display. If you have any issues with the display or later problems with the software for the display you should check out the official Waveshare Issue-Tracker and the official documentation.

First, you mount the e-Paper display to the e-Paper-Adapter. Be careful, the e-Paper display is very fragile. The next step is to connect the e-Paper-Adapter to the e-Paper-HAT with the flat white cable. The third step is to connect the 8 cables from the e-Paper-HAT to the Raspberry Pi Zero. For the wiring, details have a look at the great plan from Axel Hamburch:

Connect the Raspberry Pi Zero with the Coin Accepetor

For further details look at the detailed wiring plan:

At that point your hardware is ready and you can go to the software setup. Before you put everything into the case I recommend first to setup the software. It’s easier to do debugging outside of the case.

Setup the LightningATM

Install the ATM software

You can find further explanations at the official ATM documentation.

Download the Raspbian ATM Image
Flash the Image to the SD Card with balenaEtcher
Remove and add the SD Card again to your computer
In the mounted SD Card add one file to the /boot folder on the flashed SD Card
Create “wpa_supplicant.conf” file and add your Wifi credentials

The configuration file should look like:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
	ssid="Home"
	scan_ssid=1
	psk="XXXXXXXXXXXX"
	id_str="Home"
}

Remove the SD Card from your computer and put the card in the Pi Zero.Turn on the Raspberry Pi now and wait a bit. In the meantime check atyour local router which IP address was assigned to the Zero. To makethings easy in the future let the router always assign the same IPaddress to the Pi.
Go to a terminal application on your computer and remotely access yourPi. For example the “Terminal” on macOS or Windows via the SSH-Client”PuTTY”.

Login to your Zero with the IP and the user “pi” for example “pi@192.168.xxx.xxx”
Confirm to add the ECDSA key fingerprint with “yes”
Login with the default password “raspberry”
Change the default password of the user “pi” to a new password with “passwd”. CAUTION: you have to remember the password for the future. Best, put it directly into a Password-Manager
Upgrade the Pi Zero to the newest software version

$ sudo apt update && sudo apt upgrade

It takes some time but doesn’t skip the step because you will also get security patches with an update.

Now you can install “clone” the current version of the LightningATM Software:

$ git clone https://github.com/21isenough/LightningATM.git
$ cd LightningATM
$ pip3 install -r requirements.txt

In the process, the Pi will reboot and you have to log in again with the credentials you set earlier.

Install the display drivers

First you have to install the Waveshare Python display driver.
Execute the following commands:

$ cd ~
$ git clone https://github.com/waveshare/e-Paper
$ cd ~/e-Paper/RaspberryPi*/python
$ sudo python3 setup.py install

If you want to test for the correct installation and correct wiring of your display you can use the example programs included in the cloned project.

CAUTION: Before running the display test make sure that your e-Paper-HAT switches (little jumpers) are set to A and 0.

$ cd ~
$ cd e-Paper/RaspberryPi_JetsonNano/python/examples/
$ sudo python3 ./epd_2in13_V2_test.py

CAUTION: If you have a different display version (little sticker on the e-Paper display back) than “V2”, you have to adjust the test program accordingly.

If you have problems getting the demo running you find more help in the Waveshare Issue tracker.

If everything works fine you can initialize the ATM software. With the first startup of the ATM, the “config.ini” will be created.

Execute the following commands:

$ cd ~/LightningATM/
$ ./app.py

This will lead to an error like “No display configuration matched”. That’s why we have to adjust the “config.ini” now.

$ cd ~
$ nano ~/.lightningATM/config.ini

When the file is open, change the “display” variable to “waveshare2in13v2”.

# Define what screen you are using with the ATM
# Current options are:
# display = papiruszero2in
# display = waveshare2in13
display = waveshare2in13v2

You can save your changes now and close the file for now.

Setup lntxbot

To get Bitcoin for the dirty fiat coins to have to define an exchange endpoint. To keep things easier we concentrated on the Telegram-Bot called lntxbot. You could do the same with a BTCPay Server endpoint.

Open the “config.ini” file and do the following adjustments.
Set the wallet to the lntxbot.

activewallet = lntxbot

Now you can add your credentials for the bot:

[lntxbot]
url = https://lntxbot.com
creds = YOUR_LNTXBOT_CREDENTIALS

In your lntxbot you can get your credentials with the following command:

/lightningatm

The output should be similar to:

You can save the file now.

First exchange

If the previous steps all succeeded you can test your first exchange with the ATM.

$ cd ~/LightningATM/
$ ./app.py

You should see now the welcome message from the ATM and can insert the first coins.After some time the display should print that beautiful invoice which you canscan in your wallet.

Congratulations! You made your first transaction with the Pocket ATM. Now spread the word and showcase the ATM on the next community meetup.

May the Bitcoin be with you!

Bitcoin

Regulatory attention on Bitcoin & privacy techniques to counter

May 31, 2021May 31, 2021
by @_pretyflaco

Attention is both a curse and a blessing. On the one hand, almost every Bitcoiner wants more adoption and welcomes any coverage that might attract one or two new users to Bitcoin. After all, the peaceful revolution to separate money and state can only succeed if more people join it. On the other hand, not all attention is equally helpful. When Wikileaks started accepting Bitcoin donations, Satoshi was concerned about the attention given to Bitcoin in 2011 and disappeared a short time later with the following penultimate words:

“WikiLeaks has kicked the hornet’s nest, and the swarm is headed towards us.”
Satoshi Nakamoto

Today we know that the hornets went after Wikileaks (and continue to do so to this day). Bitcoin however, went on a honeymoon phase in which the network grew to a sizable strength with millions of users and institutional investors piling in. But this honeymoon phase is bound to end eventually.

In this article we will outline how increased attention to Bitcoin and accompanying regulation plans are creating an environment that is detrimental to user’s rights to financial privacy, and which Bitcoin tools to mitigate are available today.

While governments may accept that Bitcoin isn’t going away, it is extremely unlikely that they will embrace its Cypherpunk qualities of censorship resistance, financial privacy and inclusivity. More likely, they will exhaust all means to regulate the ecosystem in ways that aim to dilute Bitcoin’s censorship-resistance and put the financial privacy of Bitcoin users at risk.

Efforts to this end are already underway. The emergence of mining pools with blacklists that only want to accept compliant transactions into blocks gives an idea of how an attack on censorship-resistance could play out.

Playing right into this, are regulatory efforts, such as the recently published Financial Action Task Force draft (summary). It aims to undermine the pseudonymity of Bitcoin addresses with even broader collection of KYC data. What these regulatory domestication attempts have in common is that they attempt to exploit the public nature of the Bitcoin timechain by augmenting it with toxic honeypots of personal data.

Surveillance companies are enemies of a free society

Centralized service providers in the Bitcoin ecosystem are obliged to conform to AML / KYC regulations on a “best effort” basis and by implementing “reasonable procedures” to prevent money laundering.

Screenshot from https://support.bitvavo.com/l/en/article/icy22n424p-transaction-monitoring

The uncertainty about what “best effort” and “reasonable” exactly means is creating an environment where service providers are susceptible to the marketing of surveillance companies. These are positioning themselves as the silver bullet to regulatory compliance and consulting the service providers on “risk management” in ways that are overreaching and pre-compliant. Several companies with big marketing budgets have specialized in this kind of surveillance activity and built a business around selling on-chain snooping software and data.

Bitcoin is not anonymous, at least not by current majority default usage. The Bitcoin timechain is an open, transparent, pseudonymous public ledger accessible for anyone. It doesn’t contain any real world personal identity data, but the way Bitcoin is currently transacted by the majority of users makes it possible for observers to trace transactions and cluster addresses to entities. Should one of the addresses from a clustered entity make a transaction to a KYC exchange, the entire cluster, with all of its balances and transaction history, can be tied to a real world identity. Augmented with metadata acquired by KYC services, transactions and addresses can be mapped to identities, turning the pseudonymous timechain to a database of who owns what and who paid who. This is highly dangerous. With the latest big data analysis software, a government could sift through bulk financial data to create profiles of users, enforce a police state or engage in social engineering; criminals could seek out wealthy victims to target, companies could snoop on their employees spending behavior.

“No one shall be subjected to arbitrary interference with his privacy”

Universal Declaration of Human Rights

Privacy is a fundamental human right, essential to autonomy and the protection of human dignity, serving as the foundation upon which many other human rights are built. If intrusive surveillance companies are allowed to continue their malpractices with further adoption of Bitcoin, this could become a threat to personal safety, human dignity, the operation of a free market and ultimately, a free society.

“The way rights work is, the government has to justify its intrusion into your rights.”

Edward Snowden

Edward Snowden’s revelations have demonstrated that the right to privacy is not something humans can trust their governments to enforce. Weighed up against international terrorism, human rights have always drawn the short straw. The direction that international regulations led by FATF are headed prove once again that users cannot rely on institutions to protect their rights, that corporations and regulators cannot be trusted to safeguard the human right to privacy.

“We must defend our own privacy if we expect to have any.”

Eric Hughes

Bitcoiners know that freedom is fought for and earned. Consequently, users need to take matters into their own hands and arm themselves with defensive technology and best practices to safeguard their privacy with free code. On paper, privacy is a human right. But in reality, it’s a human fight against ever more data and control obsessed corporations and authorities.

Discovery of Coinjoin

While traditional banking provides a fair amount of privacy by making identities and their transactions only known to the trusted third party, Bitcoin inherently separates identities from transactions which are public.

The data applied by surveillance companies and KYC exchanges aims to abolish the identity-transaction separation. To this end, they cluster addresses using the common input ownership heuristic, which is the assumption that if a transaction has more than one input then all those inputs are owned by the same entity. As of early 2021, very commonly this assumption is true, which is why surveillance companies can apply it successfully.

Thankfully, Satoshi designed Bitcoin in a way that the protocol holds solutions against surveillance attacks. Heuristics can only be meaningfully applied if they hold true significantly more often than not. When the number of false positives exceeds a certain threshold, the heuristic becomes unusable. In Bitcoin, this can be achieved by changing the way that users create transactions. The blueprint for this change was laid out by Gregory Maxwell in two BitcoinTalk posts (here & here).

“This message describes a transaction style Bitcoin users can use to dramatically improve their privacy which I’ve been calling CoinJoin.”

Gregory Maxwell

In 2013, Maxwell proposed Coinjoin, a way of transacting Bitcoin that makes it difficult for observers to determine who paid who and which output belongs to whom. To that end, multiple spenders coordinate to combine multiple inputs into a single transaction. This happens completely trustless, meaning users always keep custody of their bitcoin and do not have to trust a third party.

Herein lies a key difference to custodial mixing services or tumblers, where users must trust that the third party they sent their bitcoin to is honest and sends another party’s coins back as agreed.

But even if the mixing service is well-intentioned and they send someone else’s coins, the coin’s history will remain attached to it, now traceable to the new owner.

In comparison with mixing services, Coinjoin is therefore clearly superior as it is more akin to melting many inputs to brand-new outputs, with each of their histories detached.

Lastly, no party must take custody of any other party’s coins and run the legal risk of being classified a money transmitter or virtual asset service provider – a classification that introduces the regulatory burden of being obliged to collect personal data and employ the above mentioned “best effort” to comply with AML laws.

Coinjoin transcations have been possible since day 1 of the protocol, but were limited due to their complexity, and only used by a few who understood the craft of rolling up transactions. However, there has always been a consensus that this type of transaction should be made easily accessible to a larger number of users as Bitcoin adoption progresses.

A bounty pool with the purpose of promoting research and development for Coinjoin (currently holding 30 BTC) attracted numerous developers to this task, and shortly thereafter, the first privacy-focused wallets emerged. In recent years, usability has steadily improved and Coinjoin has ousted custodial mixing services, establishing itself as the go-to technique in the best-practice repertoire of privacy-conscious users. The implementations most broadly in use are currently Joinmarket, Wasabi Wallet and Samourai Whirlpool (overview). All three enable users to coordinate equal-output Coinjoins to break links to transaction history and increase the fungibility of their bitcoin.

However, the increase in use of Coinjoins has caused a dystopic reaction from exchanges advised by surveillance companies. Since late 2019, there have been reports of exchanges creating friction for users who used Coinjoin, hassling them with questions about the source of funds, the reason for Coinjoin usage and demanding other accounts.

Coinjoins can reliably obfuscate the transaction history, but it is possible for an observer to identify that a specific output was involved in a Coinjoin by the multiparty equal-output transaction visible on-chain.

There is no specific legal requirement in any jurisdiction to flag Coinjoin use or deny service to Coinjoin UTXOs. It is simply more convenient for legislators to enact vague regulations and keep the ecosystem guessing. This way, virtual asset service providers have to anticipate what might be against the law and, in order to minimize the risk of license revocation, implement much more restrictive policies.

“We completed our compliance review and determined to ban your account with Paxful as it’s beyond our risk-appetite. We understand your privacy concerns, but the substantial amount of funds from the Wasabi wallet is high-risk for Paxful.”

Paxful

If a legislator were to attempt to define when a Coinjoin transaction should be rejected, it would have to answer the question of how many hops must be between a supposedly sanctionable transaction and its transfer to a regulated exchange for the exchange to be allowed to service it or not. However, once such a definition takes place, everyone would know how many hops it would take to fall off the grid. Regulation would therefore be tantamount to an instruction to circumvent that very regulation. By keeping the rules vague, the legislator conveniently avoids this situation at the cost of blameless users, who, stigmatized for the use of best practices, find it more difficult to secure their right to personal data protection.

“For privacy to be widespread it must be part of a social contract. People must come and together deploy these systems for the common good.”

Eric Hughes

At this point, it must be noted that privacy coins like Monero are in no way better off than Bitcoin transactions in this regard. According to the (flawed) logic applied for Coinjoin flagging, every Monero transaction would be flagged as conspicuous. After all, the problem is not a technical one, but a social one. The only way out of this mess is to collectively honor the need for financial privacy and stop playing with those, who don’t.

Make every spend a potential Payjoin

Another very promising tool in the fight for on-chain privacy is Payjoin. It is a special type of Coinjoin transaction between two parties where one party pays the other. The major benefit of a Payjoin transaction is that it is indistinguishable from regular transactions that surveillance companies apply the common-input ownership heuristic on, but in the case of Payjoin, the heuristic fails.

Screenshot of Payjoin transaction menu from JoinInBox GUI for Joinmarket on Raspiblitz

In a regular transaction surveillance companies assume that all inputs belong to the payer and cluster the sending addresses to the same entity. But this assumption is broken with a Payjoin, because here one input belongs to the payee. Since it is impossible to differentiate Payjoin transactions from regular transactions with multiple inputs, also called steganographic transactions, the most powerful heuristic employed by surveillance companies to deanonymize users is broken and becomes unusable if adopted more broadly.

Here, adoption doesn’t necessarily mean that users actually use Payjoin for every transaction – for the common-input ownership heuristic to become unusable it would theoretically be sufficient that enough wallets implement this feature in a way that it becomes probable that users could have potentially used it. If enough wallets adopt Payjoin, surveillance companies are forced to adjust the success probability of their heuristics to a degree that interpretation becomes ambiguous.

The Bitcoin Wiki has a site that tracks adoption of Payjoin in wallets. Driving adoption for Payjoin is a particularly low-hanging fruit for more on-chain privacy as it doesn’t require that everyone uses it for everyone to profit from it.

Software Wallets with Payjoin Support, Screenshot from https://en.bitcoin.it/wiki/PayJoin_adoption

Censorship-resistance is Bitcoin’s most important property that many other fundamental properties directly rely on, but censorship-resistance itself relies partly on fungibility. Breaking the common-input ownership heuristic would be a crucial win for more fungibility in Bitcoin, and consequently for all other Cypherpunk properties. Payjoin adoption made a big step forward when JoinMarket and BTCPayServer implemented it. If only a few more would follow, on-chain privacy could benefit asymmetrically.

Of course, the mere presence of the Payjoin option in wallets does not entirely suffice. It also needs to be used. In the next article we will therefore guide you through the process of setting up Payjoin as a BTCPayServer merchant and how, as a customer, you can Payjoin with JoinMarket.

Written by @_pretyflaco, thanks go out to @HillebrandMax and @fulmolightning for input and advice. Featured image from https://en.bitcoinwiki.org/index.php?curid=271660

Bitcoin Lightning Nodes

WHY BITCOIN CAN ONLY BE AS FREE OPEN SOURCE…

March 21, 2021March 22, 2021
by @_pretyflaco

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 11^th 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 8^th 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.

gold standard pic.twitter.com/lmqIvgk5Aa
— nix-bitcoin (@nixbitcoinorg) March 16, 2021

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.

Well here’s the drop. We present NEO GENESIS BITCOINIZATION.

Our love letter to the #bitcoin project and everyone pushing for it to reach it’s fullest potential.

You might have to frame-by-frame this one if you’re the type that’s gotta catch ‘em all. ;D pic.twitter.com/y3Bdpt7V2M
— ??????????? (@munnybadger) March 19, 2021

Lightning Network

The LightningATM – Pocket Edition

September 18, 2020January 18, 2022
by LightRider

The LightningATM is a fully functional Bitcoin ATM. It was invented, designed and improved by @21isenoug.

The product itself and its documentation is outstanding. We invite you to go down another rabbit hole in the Bitcoin universe.

The LightningATM – Documentation

The LightningATM – Github

In July, a new project was born – the Pocket Edition, as 21isenough announced on Twitter:

I made a thing 🤓 #LightningATM – Pocket Edition

Fits in (almost) ever pocket ⚡ Bring it everywhere and introduce people to #Bitcoin / #LightningNetwork

✅ 100% Open Source
✅ Beginner friendly
✅ No camera, no button
✅ LNURL only
✅ Lightweight, small
✅ Affordable pic.twitter.com/ks9uFPOIn9
— 21isenough (@21isenough) July 24, 2020

This was not only the first Bitcoin LightningATM, as it also became the first ToGo Bitcoin ATM. The Pocket Edition is way smaller and the hardware requirements have decreased as well.

You don’t need the camera or the button for the Pocket Edition. So, you not only save space, but you also save some money to stack more sats.

Who wouldn’t love you for bringing The BitcoinATM on a date?

But there are more hardware changes

Due to less space inside the case you also need another display for this version of The LightningATM.

All parts needed for the Pocket Edition, visit shop.fulmo.org

It is recommended to use the Waveshare 2.13in display. You‘ll also need an adapter for a band cable. Otherwise, you will have trouble placing the display correctly in the case.

Raspberry Zero, Waveshare adapter and display

To be honest, I am not the “deep tech guy” and had some trouble setting this up, so I decided to write this guide to help others out there. If anything is not clear or if you find any mistakes, please reach out to me. This guide will be updated accordingly.

1. Correct wiring (detailed plan see 1.1)

You need to connect the screen adapter with the Raspberry Zero. For that you take the included jumper connector with 8 jumper cables.

There are 8 colors:

Purple
White
Green
Orange
Yellow
Blue
Brown
Grey

I followed this wiring plan when setting up the display (old version/new one below):

Jumper cable color	Pin on the Pi Zero board
Grey	3.3V (1)
Brown	GND (6,9,14,…)
Blue	19
Yellow	23
Orange	24
Green	22
White	11
Purple	18

Wiring plan

1.1 Detailed plan for different versions

Once you have checked twice that you have connected the cables with the right pins you can proceed to the software setup.

2. Software setup

Make sure you have followed all the steps in the official documentation to the end before you proceed.

Keep in mind that the Pocket Edition is an extension of the original Lightning ATM. So, we’ll only need a few additional steps.

First you have to install the waveshare Python library.

Execute the following commands:

$ cd ~
$ git clone https://github.com/waveshare/e-Paper
$ cd ~/e-Paper/RaspberryPi*/python/
$ sudo python3 setup.py install

If you want to test for the correct installation and correct wiring of your display you can use the example programs included in the library.

Before running the test make sure that your screen adapter switches are set to A and 0.

To run the example file:

$ cd ~
$ cd e-Paper/RaspberryPi_JetsonNano/python/examples/
$ sudo python3 ./epd_2in13_V2_test.py

If everything is set up correctly you should see something like this:

e-Paper Demo Screen

Everything looks fine? Great!

Now you have to go to your config.ini file:

$ cd ~
$ nano ~/.lightningATM/config.ini

When the file is opened, change display variable to waveshare2in13

See below:

# Define what screen you are using with the ATM
# Current options are:
# display = papiruszero2in
# display = waveshare2in13
display = waveshare2in13

Confirm with Crtl + x and y to save the changes.

That’s it!

Now start your Lightning ATM again.

$ cd ~/LightningATM/
$ ./app.py

You should now see this on the screen:

And we’re done! I hope this was explained easy and logical enough.

Additional tips

Since the Pocket Edition doesn’t have a button I would also change the payoutdelay variable in the config.ini to something more than 0.
If you want to change the coin correspondence to the pulses generated by the coin acceptor you can change this in the app.py file.

    if config.PULSES == 2:
        config.FIAT += 0.02
        config.COINCOUNT += 1
        config.SATS = utils.get_sats()
        config.SATSFEE = utils.get_sats_with_fee()
        config.SATS -= config.SATSFEE
        logger.info("2 cents added")
        display.update_amount_screen()
    if config.PULSES == 3:
        config.FIAT += 0.05
        config.COINCOUNT += 1
        config.SATS = utils.get_sats()
        config.SATSFEE = utils.get_sats_with_fee()
        config.SATS -= config.SATSFEE
        logger.info("5 cents added")
        display.update_amount_screen()
    if config.PULSES == 4:
        config.FIAT += 0.1
        config.COINCOUNT += 1
        config.SATS = utils.get_sats()
        config.SATSFEE = utils.get_sats_with_fee()
        config.SATS -= config.SATSFEE
        logger.info("10 cents added")
        display.update_amount_screen()
    if config.PULSES == 5:
        config.FIAT += 0.2
        config.COINCOUNT += 1
        config.SATS = utils.get_sats()
        config.SATSFEE = utils.get_sats_with_fee()
        config.SATS -= config.SATSFEE
        logger.info("20 cents added")
        display.update_amount_screen()
    if config.PULSES == 6:
        config.FIAT += 0.5
        config.COINCOUNT += 1
        config.SATS = utils.get_sats()
        config.SATSFEE = utils.get_sats_with_fee()
        config.SATS -= config.SATSFEE
        logger.info("50 cents added")
        display.update_amount_screen()
    if config.PULSES == 7:
        config.FIAT += 1
        config.COINCOUNT += 1
        config.SATS = utils.get_sats()
        config.SATS = utils.get_sats()
        config.SATSFEE = utils.get_sats_with_fee()
        logger.info("100 cents added")
        display.update_amount_screen()
    config.PULSES = 0

I hope this guide was helpful. Please let me know if you find any mistakes or if you have any advice for improvements.

If you are searching for a case, or a construction set for the Pocket Edition you can buy one in the FULMOShop.

And, of course, you can pay with Lightning!

Bitcoin Lightning Nodes

RaspiBlitz Unboxing

May 22, 2020May 22, 2020
by Philipp Giese

Becoming a first class citizen of Bitcoin – My experience with the Raspiblitz

“Be your own bank” – a saying strongly associated with Bitcoin, similarly close, perhaps even more than the Cypherpunk saying “Don’t trust, verify!”. And that is true: Bitcoin promises a monetary system which is not built upon different layers of trust. So you don’t need to trust VISA, your bank, an exchange, the FED or the ECB.

That‘s the ideal, but how does reality usually look like? Even when people are not storing their bitcoins on Coinbase or Binance, a lot of enthusiasts think that the journey to trustlessness ends with a hardware wallet. As reliable as hardware wallets oftentimes tend to be, it is a new layer of trust – and unfortunatelly, hardware wallets are unreliable sometimes.

So, is a paper wallet the solution? Well, a paper wallet is much simpler than a hardware wallet and hence not as error-prone (but much more cumbersome to use, but that’s another story).

With a seed phrase on a sheet of paper… are we trustless now? Of course not, we still have to trust other parties to host the Blockchain!

I hosted a Bitcoin client a long time ago, however, I took it down and never started a new one. A dirty little secret, right? From someone who is quite active in the Bitcoin community it should be expected that he is a first class citizen of Bitcoin. As a data nerd, getting in possession of the whole Blockchain was always quite a temptation for me. Needless to say, setting up and hosting a full node was one evergreen on my bucket list.

What prevented me from “being my own bank”? Beside a huge workload on my day job, I think the main reason was an overestimation of the required hardware and bandwidth requirements. With currently over 300 GB and a growth rate of 100-200 MB per day the greedy hoarder inside me got active. “What if you exceed your bandwidth?”, “Won’t that affect your Netflix-binging?” and other stupid excuses came up.

Finally, during the preparation for the Lightning Hacksprint, the Bitcoin idealist in me won against my inner sloth and thus I was happy that Fulmo helped me getting hands on one Raspiblitz, the Raspberry-Pi-based Lightning Node. As the nerd that I am, I had some prior experience with other Raspberry Pi and Arduino-based projects. So I wanted to assemble the Lightning Node by myself and decided for the Raspiblitz – Heatsink Case.

In this article I would like to describe my first steps towards being a full member of the brotherhood of Bitcoin. The aim is not to provide a guide. The reason is simple: Another guide is not really needed! Setting up the Raspiblitz, transferring funds to it and opening the first channels on the Lightning Network is not complicated at all. At every step it is clear what the software of the Raspiblitz wants you to do, the Github page of Raspiblitz is full of information and the community is eager to help. The aim of this article is rather to illustrate how easy it is to get a Lightning Node up and running.

Getting the Raspiblitz to run

Having said that, a complete technical layman might at first feel a little bit overwhelmed by the collection of electronic items:

But don‘t be afraid: assembling the hardware is as complicated as building something out of Lego – or even more simple. The aforementioned Github Page of the Raspiblitz project is quite helpful, so it ony took a couple minutes until I ended up with an assembled Raspiblitz:

Yes, there are still some steps to go to a fully functioning node! Up until now we only have assembled some parts. No software, no Blockchain and no funds. So – you guessed it – no fun! So let‘s describe the next steps towards a fully functioning node. As you will see: no need to be afraid of being a first class citizen.

The first step you have to do is installing the operating system for the Raspiblitz. The current version is 1.5 and can once again be found on the mentioned Github page. As you can see: a lot can be found there, so simply put the link into your bookmarks. The easiest way to get this operating system up and running is to write the socalled iso-file on a SD card. That can be done with programs such as Balena Etcher. After writing the iso-file on the SD-card, simply plug this card into the Raspiblitz, connect the latter to a power source – and it‘s alive!

The system boots up and an address is shown over which you can access your Raspiblitz. The address will have the form 192.178.168.228. To access your Raspiblitz from another computer being a friend of the terminal is advantageous. So, open bash or another shell of your choice and enter:

ssh admin@192.168.178.228

You will be prompted for a starting password (which you’ll have to change later on). After some additional steps, the Lightning node is up and running.

Okay, “running” is perhaps not completely correct: The Blockchain is not yet downloaded. Being a bit patient pays off: Synchronizing the whole Blockchain from scratch takes a while!

After some time (usually around 48 hours) you can pride yourself: You now belong to the people with a complete copy of the Blockchain. You are part of the foundation of Bitcoin. Welcome to the elite, pal!

The final step to Lightning: opening and funding channels

Yes, with a node set up, up to this point you won‘t be able to transfer any bitcoins – be it via the Lightning Network or on the base layer. Some funds will still have to be transferred to your full node. Doing that is the same as sending some bitcoin, so everybody who played aaround with a mobile wallet, with a Trezor or an Electrum wallet will know how to do that. Also opening Lightning channels is not that complicated; the menu describes quite well what you have to do.

To open a channel to a peer, you have to connect to him. I set up my first Lightning channel to Fulmo‘s Lightning node, so I‘m all set for the next Lightning Hackday or the day when I can buy nifty Lightning basecaps or T-shirts at the Fulmo shop. All the information needed to connect to a possible peer can be found at 1ML:

After the connection is established it‘s easy to fund a channel with this peer. Simply state the amount in satoshis. Then you will have to wait for three confirmations and the first channel is opened.

The next steps as a first class citizen

Your Lightning node adventure does not stop here. Sure, you can now send and receive money via the base layer and via Lightning network, but you can do so much more. You can connect several mobile wallets with ease, you can use Joinmarket as a Coinjoin service … there are a lot of possible next steps. For people not loving the terminal as much as I do, there is also a web user interface called „Ride the Lightning“ available:

Speaking of web user interfaces: You don’t need to trust external Blockchain explorers anymore! With the Bitcoin Blockchain at your home, you have everything you need to set up your own Blockchain explorer:

Similar to the lessons regarding the Lightning Hacksprint, I can highly encourage everyone to set up a Raspiblitz. It‘s very easy and straight-forward, the bandwidth at your home won’t break down and you will do an essential job for the decentralization of Bitcoin. “Don’t trust, verify” won‘t be a simple saying anymore, you will live it now. So, get your hands on a Raspiblitz, set up this Lightning node and become a first class citizen of Bitcoin! I’ll be waiting on the other side.

Lightning Network

How to survive your first Hackathon

May 15, 2020May 16, 2020
by Philipp Giese

My lessons learned at the Lightning Hacksprint

So you want to get your hands dirty and interact with the developer-community around Bitcoin. Great! You seem to understand that “be your own bank” means more than “number go up”. BYOB implies that everyone is proactively involved getting Bitcoin and Lightning running. We are building up the new kind of money. And to do that, in a trust-minimized way, needs everybody.

But where to start? Hackathons can be a good opportunity to take the tech-pill. Or, even more convenient from the comfort of your own home: Dive deep into the coding community of Bitcoin by participating at the Lightning Hacksprint. A wrap-up of this Event is available on Youtube.

The last event, which took place between May 9th and May 10th, was a blast. I can highly recommend everyone interested in Bitcoin and the Lightning Network to be there when the next Hacksprint, organized by Fulmo, takes place. It does not matter if you are a professional developer.

That being said some technical experience can help and prevent you from some humbling experience. Because, to be honest: my biggest lesson learned was that I am not as smart as I thought I would be. Armed with some data science experience (mainly in R, some experience in Python) I knew that it would not be a cakewalk for me but never thought that I was stuck quite early at the beginning. At a first glance the sad news was that I could not participate in the way I planned to do.

The Lightning Hacksprint was Nevertheless a great experience. I could follow development work around, experiment with the code on my machine and in that sense really live the “Don’t trust, verify” in its fullest extend.

Moreover, I learned quite a lot for future Hacksprints. So lets dive right in and look at my personal lessons learned!

Create a distraction-free environment

On the weekend of the Lightning Hacksprint, I was not alone at home. While I could hide myself in my bedroom (which I did for most of Saturday) it was obviously not ideal. Moreover, I had to do some phone calls, and had an appointment on Sunday evening.

At regular Hackathons you are taken from your normal surroundings which can help a great deal, but thanks to Corona we have to find a way to get rid of the distractions at home. So for the next Hacksprint I plan to really seal myself off from the rest of the world.

Get your communication tools ready

The second lesson should be well-known in times of corona: Get all communication tools running! The communication during the Lightning Hacksprint was primarily done over two platforms: Mattermost was, as an open-source-alternative to Slack or Microsoft Teams, the messaging platform of choice, while Jitsi was used for video conferencing. Different projects used additional software to keep in touch but all in all one big lesson was: Check whether the tools at hand work well.

How is the internet connection? Is Jitsi working? And how about your microphone? I personally had to use both my Laptops, one for hacking, one for listening to Jitsi. Moreover, I had to check several Headsets until I found one which worked well. While that was in that case not impeding the work of others obviously work could have been much more fluent with a little bit of preparation.

Install the mandatory programs

My biggest mistake was that my software environment was not completely prepared. While it cannot be stressed enough that everybody should run a Full node (and setting up one is, thanks to the Raspiblitz, pretty easy), some development projects don’t need a running full node. However, the Bitcoin client bitcoind as well as a Lightning client (lightningd when working on a project around c-lightning) should be installed.

Oh, and I should stress installed correctly. My initial approach regarding bitcoind was to download a precompiled version “to save some time”. That ended up in some weird aliasing and extending of $PATH but a decent interaction between lightningd and bitcoind could not be achieved. The solution that worked for me was then to install bitcoind from source.

Even before that, dependent on your respective system and at the task in hand, you will need some programs. Some programs which you definitely won’t regret having installed are:)

C and C++
git
Python (>version 3.0)
Pip
Some editor or IDE. Most operating systems are shipped with several editor options.

That list, obviously, can be extended dependent on the challenge you plan to work on. If the project involves Rust, it is obviously recommended to install it. If you work with Python, installing the Lightningd-Library pyln would be a good idea.

So one important lesson learned was: get the needed tools together. Already before the Hackathon, get to know these tools. If not you risk losing falling behind the other people working on a project – or, even worse, you slow everyone down.

To install these programs, even when done from source, you don’t need to be an expert programmer. Most of the programs have decent installation scripts which can be invoked with several commands. What is needed, though, is a little bit of tinkering on the command line. With that we come to the next point.

Become a Terminal-maximalist

If you are a Linux-user (or if you know that Mac-OS is, in fact a BSD derivative) you will already know it: the Terminal is your friend! When developing, the Terminal is not only convenient but one of the most important tools you’ll use. The installation of the tools mentioned above will take place on the command line. A lot of editors such as Nano or vi(m) are per default run from the command line, others such as Emacs have the option to do that.

Note also that I said Terminal- and not PowerShell-maximalist. While Windows 10 had made giant steps forward with their Windows Subsystem for Linux, the integration within the Linux file structure for the tools mentioned above is best in a *nix-like system. The community is also larger so that, if you are stuck, more people could help you. Finally, its also a great way to prepare yourself for a Raspiblitz. Yes, when the Lightning Node of Fulmo is up and running a lot of things can be done in the different menus. However, for debugging the Raspiblitz knowledge about the Terminal can be a huge help.

Grab your coffee and hack!

The fifth and most important lesson: do it! Bitcoin-developers are no reclusive, elitist cabal. They are very welcoming to newcomers and quite happy when people want to participate in a Hackaton. Of course, as always the Golden Rule “don’t be a nuisance” applies. Like in other communities a little bit research prior to asking the community can help. During a Hackathon or Hacksprint everybody is quite busy so asking really basic questions can be a distraction. So flex your ~~Google~~ Duckduckgo-Skills and try to find answers before asking every question.

That being said: Irrelevant of your experience I can invite everyone to observe the more technical side of Bitcoin. Even if you think you cannot work on one of the proposed challenges just watch these evolving from the sidelines. You can also work on your Raspiblitz, for example update it to a new version or getting in touch with some new features. So if you have one at home and wanted to ask the developers anything: These Lightning Hacksprints are a great opportunity.

See you guys at the next Hacksprint!