As a Bitcoin payments API infrastructure provider, one of the many items we aim to always improve upon is `developer time to payment` — how long does it take for a new ZEBEDEE developer to perform their first global Bitcoin payment?

Because of that, our team is always focused on introducing new ways to quickly get started in a secure server environment and interacting with the ZEBEDEE API or SDKs.

Replit is an online integrated development environment (IDE) that allows users to write, run, and collaborate on code directly from their web browser. Basically, any developer can spin up an entire development environment on the language of their choosing, and go from first code commit to full production deployment all in the same web interface.

Add the flexibility developers have with cloud-based IDEs like Replit, to the simplicity of the ZEBEDEE API for global instant Bitcoin payments and you have a winner!

3-min Walkthrough

Head on over to Replit.com and create a free account if you don’t already have one.

Once you’re in, find the zebedee-nextjs-dev-playground template here:

replit.com/@andrerfneves/zebedee-nextjs-dev-playground

Click the USE TEMPLATE button on top right and give your new project a name. Your repl instance will begin to boot up and you’ll see the robust IDE interface from Replit begin to take shape in the page.

We’re basically done, now just need to connect a ZEBEDEE API Key to this new repl instance.

If you don’t yet have a ZEBEDEE account, head on over to the official how-to documentation or the ZEBEDEE Developer Dashboard signup page. Once you’ve got your account setup and verified, create a new Project and fetch its LIVE API Key from the dashboard (important: it HAS to be a LIVE API Key, a SANDBOX API Key will not work). It should look something like this:

Now to place the ZEBEDEE API Key securely in the Replit dashboard, search for the Secrets tool on the sidebar:

Click to NEW SECRET and name it ZEBEDEE_API_KEY and paste the key you copied from the ZEBEDEE Developer Dashboard.

That’s it! You’re all set.

Now press the big green RUN button on the top of the Replit page and you should see a new Webview module pop up with the template’s frontend loaded.

You can now head on over to your repl’s web url, mine is: https://zebedee-nextjs-dev-playground.andrerfneves.repl.co, and you should see your newly deployed ZEBEDEE-powered application!

The bottom 4 navigation item links take you to other ZEBEDEE API and ZEBEDEE Developer Dashboard learning resources. You can also find detailed documentation about the @zbd/node Node.js SDK. Lastly, there are guides on how to best deploy this starter kit to services like Vercel and Replit (this guide!).

At the top right of the web app you will find the OPEN PLAYGROUND link. Clicking that will take you to the ZEBEDEE + Next.js Dev Playground page which contains modules for the main use-cases of the ZEBEDEE API — Payments and Payment Requests (Charges), Lightning Address Payouts, Withdrawal QR codes, BTCUSD price ticker and much more.

On the top right you can see the ZBD Project Wallet detailing the balance of Bitcoin (in satoshis) available to this ZEBEDEE API Project key.

Each module is self-contained, which means you can just fill in each of the form elements and hit Submit to watch the magic happen. Results will appear inline.

You can now literally send Bitcoin instantly anywhere in the world! No big deal.

Here’s a Bitcoin Lightning Network payment request QR code I created by filling in the two input fields and hitting 1 button click.

Here I am sending a Bitcoin payment that’s settling instantaneously through the Lightning Network — this time sent to a Lightning Address (e.g. andre@zbd.gg).

The template is meant to serve as both a set of example source code files for developers to learn and get ideas from, as well as a full-blown backend + frontend app development environment. Because it is based on the Next.js framework, developers can get started editing code directly on the template’s JavaScript files and watch their changes reflect live on the accompanying Webview.

Now, Go Build!

The goal with writing this guide and the ZEBEDEE Next.js Template starter kit for Replit is to simplify the process and reduce the steps necessary for app developers to build global instant payments into the fabric of their games, apps, and virtual user experiences.

ZEBEDEE is here to support you on your journey.

The future is waiting. Go build it!

-AN

Troubleshooting

If you start your repl and it provides a message like the one below, it means you have not properly configured the ZEBEDEE_API_KEY in your Replit project’s Secrets.

ZEBEDEE is the next-generation Fintech built on top of Bitcoin and Lightning Network protocols. Looking to build your next game or app with Bitcoin capabilities?

ZBD API is your one-stop solution!

The Andre Neves Newsletter

The Rise of Paid Nostr Relays

Unless you’ve been living under a rock for the past few months, you have heard of the up-and-coming revolutionary and possibly-decentralized data protocol called Nostr. Nostr is a generic communications protocol that has a myriad of potential applications…

Read more

3 years ago · 4 likes · 4 comments · André Neves

This is a quickstart guide for those that wish to run a paid Nostr relay. There are now tens of relay implementations out there, but only one with plug-n-play support for Bitcoin Lightning Network payments — Nostream.

This is a technical walkthrough of how to get it all setup!

VM Setup

Choose your preferred VM provider - whether you use Linode, Digital Ocean, AWS, GCP, Azure, etc. For this guide I used the following setup in DigitalOcean:

• Ubuntu 22.10, 8GB memory, 160GB NVME SSDs

I recommend at least 8GB of memory given the resource intensive nature of always-on websocket connections. Once your instance is up and running, SSH into that VM and follow the next steps.

# Update deps
sudo apt update

# Install nodejs, npm, nginx, certbot
sudo apt install nodejs npm nginx certbot python3-certbot-nginx

# Setup new `nostream` user (don't run nostream on root)
useradd -m -G docker nostream
# If the group `docker` doesn't exist run groupadd docker

# Set new nostream user password
passwd nostream

# Set bash shell for nostream user
chsh -s /bin/bash nostream

Setup Docker + Install

Commands below will install Docker in your VM.

# Create the keyring folder
sudo mkdir -p /etc/apt/keyrings

# Fetch and add it to folder
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Setup proper folder permissions
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Setup `apt` Docker repository (this is a one-liner)
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker
sudo apt update && sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

# Check installation is successful by checking verions
docker --version

Setup NGINX

Use the commands below to setup NGINX reverse proxy.

# Delete the default nginx settings file
rm -rf /etc/nginx/sites-available/default

# Paste in new settings file contents (see heading NGINX Settings below)
sudo nano /etc/nginx/sites-available/default

# Restart nginx
sudo service nginx restart

# Map DNS A record to IP of VM machine (see DNS Settings below)

# Request SSL cert from letsencrypt/certbot
sudo certbot --nginx -d subdomain.mydomain.com

NGINX Settings

Use the contents below as the contents of the default NGINX settings file. Do remember to change the subdomain.domain.com to your domain.

server {
    server_name subdomain.domain.com;
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_pass http://127.0.0.1:8008;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

DNS Settings

To map your VM’s IP address to your subdomain.mydomain.com you need to have an A record like below in your domain DNS settings.

You may need to setup a static/reserved IP address in order to map the A record to the subdomain.mydomain.com.

ZEBEDEE Dashboard Setup

Let’s now go ahead and set up your ZEBEDEE account. Start by signing up at ZEBEDEE Developer Dashboard Sign Up.

When you’re in, you will need to quickly verify your email address (look out for an email from ZEBEDEE with a 6-digit code). Once you’ve verified your email, head on over to the left-hand sidebar and click PROJECTS, then CREATE NEW PROJECT.

Once your project is created, you will be taken to the PROJECT DETAILS view. Each project in the dashboard has a fully-programmable Bitcoin Lightning wallet, and each wallet can be managed using the API Key provided in the API tab, as shown below.

Copy this API Key, you’re going to need it when setting up Nostream.

Bonus: you are also encouraged to place your VM’s IP addresses in the whitelisting field to ensure API calls to ZBD using your API Key are only ever coming from the provided IP addresses.

Now that we’ve gotten the ZBD API Key, let’s place it in the configuration file for Nostream and set it live!

Nostream Setup

Now that your VM is all setup, and you’ve got your ZBD API Key, let’s install and configure Nostream to run a paid relay powered by ZBD.

# Change to nostream user
su - nostream

# Clone `nostream` repo
git clone https://github.com/Cameri/nostream.git

# Open a TMUX session
# (to be able to detach and maintain process running)
tmux

# Start the relay
./scripts/start

# You want to start the relay once such that all Docker images are downloaded/built, and the default settings.yaml file is automatically copied over.

# Stop the relay (you will see the NOSTREAM logo once it's running)
Ctrl + C (you can use ./scripts/stop as well)

# Edit the settings file to your liking
# (see Settings.yaml Configuration below)

# Add local.env file to root
touch local.env

# Edit local.env file and add ZEBEDEE_API_KEY and SECRET
# SECRET is a 128bit random hash
nano local.env

ZEBEDEE_API_KEY="your API key goes here"
SECRET="your SECRET goes here"

# You may need to add a `env_file` property to docker-compose.yml
env_file
  - local.env

# Restart Nostream
./scripts/start

# To detach from the TMUX session
Ctrl+B  +  D
# To re-attach to the TMUX session
tmux a

Settings.yaml Configuration

Go ahead and edit the contents of your Nostream settings file. The file can be found at .nostr/settings.yaml

At first, make sure to change the info properties so they match your taste. This information is public and is provided to any client app that connects to your relay.

Then scroll down to payments properties and enable the ZBD processor and select the admission fee cost you’d like to charge. You can also add any pubkeys to a whitelist if you wish to bypass the charge.

Under paymentsProcessors make sure to change nostream.your-domain.com to your actual Nostr relay domain.

Change limits.event.pubkey.minBalance to the amount you are charging for admission to your relay. (this should not be 0)

Your paid relay configuration is now complete! Go back up to continue with the commands and add your ZEBEDEE_API_KEY to local.env file.

Done!

Once you restart the relay, you should see a console that looks a little bit like this.

The special part is `Payments Provider: zebedee` and `Pay-to-relay = enabled`. You’re all set, let’s test the relay!

Check Relay Connectivity

In order to check that the relay is setup correctly, head on over to WebSocketKing and test the connection to your subdomain.domain.com.

If you’re able to connect to your relay, then it is time to test that the paid access functionality is working. To go through that flow head on over to https://subdomain.domain.com and follow the admission payment flows.

For more details check out the How It All Works section on the The Rise of Paid Nostr Relays sister post below:

The Andre Neves Newsletter

The Rise of Paid Nostr Relays

Unless you’ve been living under a rock for the past few months, you have heard of the up-and-coming revolutionary and possibly-decentralized data protocol called Nostr. Nostr is a generic communications protocol that has a myriad of potential applications…

Read more

3 years ago · 1 like · André Neves

Upgrade Guide

If you’re updating from a previous version of Nostream to the latest pay-to-relay version, the commands below are for you:

# Stop nostream relay
./scripts/stop

# Remove old Docker network (you may not need this)
docker network rm nostr-ts-relay

# Stash any local git changes applied to the relay codebase
git stash -u

# Pull latest nostream code
git pull

# Bring back locally stashed git changes
git stash pop

# You may want to change your settings.yaml here

# Restart relay
./scripts/start

Security

You also want to make sure to apply a sensible set of firewall port accesses. The bare minimum would be to open ports 80 and 443 for HTTP/HTTPs and WebSockets. Port 22 is default for SSH’ing into a VM. (This config really depends on how YOU set up your Nostream VM).

In Digital Ocean, you can head to Droplet > Networking > Firewall.

Conclusion

That’s it! You’re all setup. This Nostr relay will now only accept fetching and posting of new events by those users that have paid the admission fees.

Now sit back and watch those sweet sweet satoshis stream into your ZEBEDEE wallet as you provide decentralized communications relay infrastructure to the world!

Focus on providing the best Nostr relay infrastructure for your users, and let ZBD focus on what we do best — Bitcoin Lightning Network APIs and infrastructure provisioning.

If you’re trying to run a paid Nostream relay, get in touch with me on Twitter @andreneves or DM me on Nostr and I’ll get you onboarded with an invite code.

ZBD provides the industry-leading Bitcoin solutions with the most in depth array of Lightning Network API protocol support ranging from Lightning invoices (BOLT11 payment requests), to LNURLs, to Lightning Addresses, and even Keysend (spontaneous payments). We’re here to support you and your teams on your journey to introduce real value to user experiences!

If you’re building on Bitcoin and Lightning Network, it must be on ZBD.

Till next time!

- AN

If 1 week in BitcoinDev-land feels like 2 years, then 1 week in NostrDev-land is at least a full decade. The sheer number of new client apps, advanced relay implementations, and developers getting their hands dirty with Nostr is simply staggering. The ecosystem is growing so fast that there is already a Nostr Conference schedule for March called Nostrica.

Developer-interest metrics can be notoriously bad at identifying patterns and trends. BUT, if we are to take into account the recent wave of interest into the Nostr protocol simply by looking at the number of GitHub stars on the repository - WOW!

Now you may be thinking that this is probably akin to the growth of other open source protocols that have received similar adoption. And you would be right to think that. But the difference is actually pretty stark when you compare Nostr’s growth with other protocols of similar kinds. Below you see the chart comparisons for Nostr, bitcoin, IPFS, and LND GitHub stars. While it’s clearly really early days for the Nostr protocol, its growth thus far has been nothing short of incredible.

Network Growth

As the Nostr network continues to grow, and software solutions for both clients and relays continue to mature, one of the big discussion topics that comes up time and time again is monetization business models.

Most of the cost of running the Nostr network is on its distributed relay infrastructure. Relays must handle the storage of events, the compute cycles that allow for clients to connect, send, and fetch events, as well as the necessary bandwidth used to relay these events to tens of thousands of users. Currently all of the Nostr relays are being run by enthusiasts — folks that are paying out of their pockets to provide infrastructure for clients to connect and post to.

No one is earning any real return from running Nostr relays in production at the moment, and this must change for the continued growth of the network.

For the network to mature, there must be incentive structures in place that ensure relay operators are incentivized to provide always-online infrastructure to users. Any decently mature distributed network will also have to deal with much more adversarial conditions around spamming and denial-of-service attacks.

While Nostr is itself a lightweight protocol, scaling relays to tens of millions of users will be very costly. Therefore it is imperative that we arrive at monetization schemes for Nostr relay operators to earn returns on their server infrastructure provisioning.

Fee Monetization

While it’s all fun and games to theorize about monetization techniques for Nostr relays, when it comes to actually building these on relay implementations it’s a different beast altogether.

It is important to understand that this is NEW. No one has successfully monetized a Nostr relay, so any and all attempts right now are nothing more than that — attempts. There will be models that work and models that don’t. Ultimately we must start somewhere.

Bitcoin is the perfect fit for the money layer of the Nostr network. Apart from the obvious reasons around its decentralized nature, censorship-resistant capabilities, and global adoption reach, Bitcoin fits into Nostr because of the Lightning Network. By relying on Lightning Network payment requests we are able to achieve a money layer that provides cheap and instantaneously-settled value transfer.

There are various ways for a relay operator to charge for the work their relay is doing on behalf of its clients. Specifically I believe there are 3 distinct types of fees that operators could begin entertaining in order to make their relays more sustainable from a cost perspective, and more stable from a DDoS and spam-protection perspective.

Storage (pay per size)

The entirety of the Nostr protocol surrounds a generic event object that contains 7 simple parameters. All actions inside of Nostr are events. If you’re making a post to your feed — that’s an event. If you’re editing your profile metadata — that’s an event. If you’re liking a post on your favorite app — that’s an event.

All of these events are sent by clients to relays, and relays have to store that data in order for other clients to fetch it at a later date/time. It then becomes clear that the more events a relay has, the larger their storage needs are. And with the current growth of the network the expectation is that there will only ever be more users, making even more events.

What if relay operators could charge users/clients based on how much data they store on their behalf? Maybe the path forward is to charge X satoshis per every Y MB of event data that is stored on a user’s behalf?

Publication (pay per event)

If we know that everything in Nostr is an event, and that in order to interact with anyone in the network one must publish events, why shouldn’t relay operators simply charge users per event? The proverbial `pay-for-what-you-use` is another model that could be tried by relay operators. The more the user does with this relay, the more it would cost for them.

The biggest challenge for this pay-per-event model to work is FRICTION! Microtransactions are a burden to users if they are not kept out of sight, and interrupt the user experience at every engagement. Users will simply churn out and not return.

I still have a lot of hope that this is a model that will be attempted, but it does feel a bit early for it to work at scale, in an interoperable manner across all client apps and relays.

Admission (pay per pubkey)

KISS = Keep It Simple Stupid

Maybe we should start small, simple, and iterate from there. A straightforward monetization mechanism could be to have a simple allowlist that includes all of the public keys / users that have paid an admission fee set by the relay operator.

The relay operator will then be able to monetize that service with an upfront fee for providing it to users. Additionally, operators are given the ability to further decide to remove users / public keys from the allowlist if they breach any of the Terms of Service they stipulated. Users not in the allowlist will have their relay connections dropped, and no further posting or fetching of events is available for that public key. This mechanism also allows operators to deter spammers, and provides for a more stable Nostr data experience when compared to public free relays.

While it remains to be seen how operators will handle actively monitoring their users and events, it is quickly becoming clear that running a large scale Nostr relay is not a small task, and requires active maintenance resources.

Enter Nostream + ZBD

Nostream is one of the most feature-rich Nostr relay implementations out there. It is written in TypeScript, authored and maintained by Ricardo Arturo - a prolific developer and Core Nostr Contributor. This relay implementation has got support for the most used NIPs, fully configurable rate limiting settings, blocklisting and allowlisting of pubkeys and event keys, and much much more.

Nostream’s latest feature: Paid Relay Access

On the latest version of Nostream, a relay operator is able to connect a ZBD API key to their relay, and with 2 simple configuration settings activate paid access support.

From that moment on, that relay is effectively monetized through the Lightning Network and payments can be performed by any user from anywhere in the world.

When initiating your Nostream relay, with a simple set of configuration parameters and a ZBD API key, anyone is now able to directly monetize the storage, compute, and bandwidth costs of running a Nostr relay!

How it all works!

When a user visits the homepage of the paid Nostream relay, they are shown the one-time admission fee requirement screen. The user is also provided a detailed Terms of Service that relay operators can choose to modify to their own desires.

The payment orchestration flow is done through Bitcoin Lightning Network, so when a user clicks pay 1000 sats, a Lightning invoice is created and displayed as a QR code. This payment request is payable by any Lightning-enabled Bitcoin wallet in the market.

Here I’m using the ZBD Browser Extension for Google Chrome to make the payment directly from my browser with 1 click.

Once the payment is complete, the user’s public key is then added to that relay’s allowlist. From then on, that user is able to successfully connect to the relay. They can now post and fetch events as much as they want.

To make the entire flow even simpler, Ricardo was able to configure each Nostream relay to have its own identity inside of Nostr (public key). Which means that the same information that is shown in the website’s UI is also sent to the user as a private DM message. If their application handles paying directly with a wallet (like Snort does below), the payment flow can be even smoother.

Once the payment settles, the relay also sends a message stating that their public key has been added to the list of admitted users.

Even with just this initial implementation of a paid relay by admission fee, we have already identified a few paths worth exploring further:

• Creation of a set of separate NIPs that define events for a relay to send payment requests directly to clients, and have that UI/UX be handled differently than just a DM message.

• Creation of subscription services such that relays are able to automatically let users/pubkeys know their access is going to be terminated unless payment is completed within X days.

Given the recent surge of new users to Nostr, one theme has been clear: free relays are melting under the increased demand, while paid relays are providing the most reliable services.

Both nostr.milou.lol and Ricardo’s eden.nostr.land are currently running Nostream with paid relays configuration. And more are popping up everyday! If you are seeking a more stable experience for sending and fetching events in Nostr, give a paid relay a try!

Focus on providing the best Nostr relay infrastructure for your users, and let ZBD focus on what we do best — Bitcoin Lightning Network APIs and infrastructure provisioning.

If you’re trying to run a paid Nostream relay, get in touch with me on Twitter @andreneves or DM me on Nostr and I’ll get you onboarded with an invite code.

ZBD provides the most in depth array of Lightning Network API protocol support ranging from Lightning invoices (BOLT11 payment requests), to LNURLs, to Lightning Addresses, and even Keysend (spontaneous payments). We’re here to support you and your teams on your journey to introduce real value to user experiences!

If you’re building on Bitcoin and Lightning Network, it must be on ZBD.

Hopefully the next post will be on running a fault-tolerant high-availability Nostr relay. Yes, enterprise nodes are already here!

- AN

We’ve all seen this story before. An exciting new application that promises to disrupt an industry sector, or introduces some novel technology, and gets everyone hyped-up. Shortly after the team publishes the release to the Apple App Store — lo’ and behold it gets rejected for reason A, item Z, or 3.16.7 rule 25.

This isn’t new. This is actually the norm. The status quo is simply not good enough.

Apple is using its power to force app creators who publish iOS apps on their App Store to pay 15-30% for any in-app purchase, and require those transactions to be processed by Apple’s own payment processing gateways (Apple Pay / IAP). This vendor lock-in is harmful for innovation and leads to exploitative measures.

Thankfully, an alternative exists: The Web! Why should Apple be allowed to take 15-30% of the value created by the team who created the app, who after many failures and thousands of hours of work were finally able to prove product-market fit? Apple is clearly exploiting its monopoly to extract more than their fair share. I'm not saying Apple shouldn't get a share, but it should be significantly lower than 15-30% to be competitive with current market dynamics.

The good news is that Bitcoin Fixes This. The Lightning Network enables bitcoin to be used as money. Bitcoin is interoperable across different applications for small and large payments, with incredibly low payment processing fees (1% or 1 satoshi, fractions of a cent). This is much lower than the traditional finance cost of payment processing, which is 2.9% + 30 cents.

Additionally, legacy systems incur users much larger flat base fees, driving up the minimum amount of funds and the type of fund-flows supported. Bitcoin applications do talk to other bitcoin applications and systems, unlike most USD systems, which provide faux interoperability to customers. Learn more by watching Andre Neves CTO and Co-founder of ZEBEDEE discuss The Future of Payments at a recent talk at MIT.

The ability to support micropayments as low as fractions of a cent allows for transactions that are inclusive of any use case — anyone can afford to transact in this network. Our applications can infuse money into their experiences and make them richer, especially when it comes to e-commerce and social interactions. This lowers the barrier to entry to offer payments in and out of web apps, with transactions that are easy to implement and have no deposit or settlement risk.

In a single night, I was able to build a wallet web application using the ZBD APIs.

I built this ZBD Labs Wallet App to showcase what is possible with Bitcoin and ZBD APIs. The wallet allows users to pay and withdraw funds for real and virtual goods or services, and deposit funds. Here is a live demo of the features. Imagine building your own app experience with monetization opportunities and ways to provide more value to your users.

Any game, application, service, or platform can interact with, and use Bitcoin as its money now. And it is all interoperable with other services, because we all speak Bitcoin.

I hope this inspires folks to add Bitcoin to their experience and make richer UX flows for their users. I hope this inspires folks to look at The Web as the most open medium for building applications.

Think of the new monetization opportunities, the cost-savings on payment processing, and the faster speed to market! All of this can be achieved while supporting many more users and use cases because of lower barriers to entry. That is what Bitcoin offers us on The Web, especially with advanced UX protocols like LNURL.

You don't need to be a Bitcoin expert to add it to your app. The ZBD APIs make it extremely easy to do so, and we have guides and API reference details available on our Documentation Portal.

🔥 If you're interested in building with ZEBEDEE, contact our sales team.

If you're new to Bitcoin and the Lightning Network, check out my Lightning Network 101 and LNURL 101 presentations. You can see the digital economies that can be built in my Lightning for Creators video.

To close out the year with a bang, we decided to record a new Tidbits episode! Lo and behold the one and only #nostr creator

@fiatjaf and I discuss all things happening in Nostr-land and what's going on since the public funding / support from @jack. This is a laid back conversation and we cover a wide-ranging set of topics, which include:

• Main challenges for Nostr adoption

• "Stop using Nostr, start building Nostr"

• Nostr is an open protocol - can build more than Twitter

• Future of Nostr relays

• How things escalated over the past 3 weeks

• How to help the network's growth

• ...and much more

Check it out on your favorite podcast player:

https://anchor.fm/lightning-tidbits/episodes/Lightning-Tidbits-769571-e1ssfqm

Happy holidays / NYE!

See you in 2023

This guide is now slightly outdated due to updates in Nostream relay server implementation. If you want to setup a Nostream instance, check out the guide below. You may skip the payment-related sections if you wish to make a FREE relay.

The Andre Neves Newsletter

How to Setup a Paid Nostr Relay

ZEBEDEE is the next-generation Fintech built on top of Bitcoin and Lightning Network protocols. Looking to build your next game or app with Bitcoin capabilities? ZBD API is your one-stop solution! This is a quickstart guide for those that wish to run a paid Nostr relay…

Read more

3 years ago · 2 comments · André Neves

This is a quickstart guide for those that wish to run a Nostr Relay. There are tens of relay server options and implementations, but to keep things simple for newcomers to the network, I’m using the friendly `nostream` built in TypeScript and packaged as a Docker Compose YML file.

Nostr Recap

nostr - Notes and Other Stuff Transmitted by Relays

Nostr is the simplest open protocol that is able to create a censorship-resistant global "social" network once and for all. It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works.

Recently Jack Dorsey checked out the Nostr protocol first released by ZEBEDEE developer fiatjaf and realized that there’s a LOT of promise and value to the protocol design decisions. So much that he deployed ~$250k to foster the Nostr development community.

While we are running a beefy production-ready nostr relay on nostr.zebedee.cloud already, I wanted to make a simple guide for newcomers that wish to run a relay server and begin interacting with the network themselves.

FWIW: this setup is different than the infrastructure setup for `nostr.zebedee.cloud`.

Let’s get started!

Setup VM

Choose your preferred VM provider - whether you prefer Linode, Digital Ocean, AWS, GCP, Azure, etc. For this quick guide I used the following setup in DigitalOcean:

• Ubuntu 22.10, 8GB memory, 160GB NVME SSDs

I used these specs for this relay, but there are not yet enough benchmarks to suggest exactly which specs to choose.

Once you’re all setup, SSH into that VM and follow the next steps.

CLI Commands

# Update deps
sudo apt update

# Install nodejs, npm, nginx, certbot
sudo apt install nodejs npm nginx certbot python3-certbot-nginx

# Setup Docker GPG key
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Setup `apt` Docker repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker
sudo chmod a+r /etc/apt/keyrings/docker.gpg
sudo apt update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

# Check installation is successful by checking verions
docker --version
npm --version
node --version

# Clone `nostream` repo
git clone https://github.com/Cameri/nostream.git

# Delete the default nginx settings file
rm -rf /etc/nginx/sites-available/default

# Paste in new settings file contents (see heading NGINX SETTINGS below)
sudo nano /etc/nginx/sites-available/default

# Restart nginx
sudo service nginx restart

# Map DNS A record to IP of VM machine (see DNS SETTINGS below)

# Request SSL cert from letsencrypt/certbot
sudo certbot --nginx -d subdomain.mydomain.com

# Open a TMUX session (to be able to detach and maintain process running)
tmux

# Start the relay
npm run docker:compose:start

# To detach from the TMUX session
Ctrl+B  +  D
# To re-attach to the TMUX session
tmux a

Nginx Settings

Use the contents below as the contents of the `default` nginx setting.

server{
    server_name subdomain.domain.com;
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_pass http://127.0.0.1:8008;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Setup DNS A Record

To map your VM’s IP address to your subdomain.mydomain.com you need to have an A record like below in your domain DNS settings.

You may need to setup a static/reserved IP address in order to map the A record to the subdomain.mydomain.com.

Check Relay Websocket Connectivity

In order to check that the relay is setup correctly, head on over to WebSocketKing and test the connection to your subdomain.domain.com.

Conclusion

That’s it! You’re all setup. This nostr server will ingest and relay any and all events broadcast to it. This isn’t necessarily how a production server would want to be run, but this is a good start.

For more information around limits and event types configuration read more at nostream GitHub repository. Also do note that nostream only supports the following NIPs (Nostr Improvement Protocol) at the moment:

Welcome to Nostr!

Join the #nostr Telegram group to join the development community around this project. You may want to add your relay to nostr.watch for discoverability.

Cheers!

Updates/Edits:

• Dec 31st: Changed `nostr-ts-relay` to `nostream` new package name, and added better info on docker install issues - [RESOLVED]

• Dec 19th: Changed from using `snap` to install docker in favor of officially supported method with `apt` and Docker’s own repository - [RESOLVED]

• Dec 18th: Fixed issue with improper quotations and dashes pasted into the code section of Substack - [RESOLVED]

If money is to be digital, instantaneous, and global, then it must also be interoperable.

This is not our reality. We live in a non-interoperable financial world. A world where global wire transfers between banks get stuck for over 3 weeks. A world where fintechs and neobanks promise interoperability but give you more proprietary APIs. A world where we can’t send money from Cash App to Revolut.

It is 2022, and we must do better.

What if there was another way? What if the payment rails were instead built on money that was inherently interoperable at the base layer? What if users enjoyed fee-less, instantaneous transactions with one another on a global scale, regardless of provider choice?

The future of payments must be built on true global interoperability across users and providers that rely on the same base money - Bitcoin.

This is a multi-part series on how Bitcoin, Lightning Network, and Lightning Address are making money truly interoperable on the web stack. We explore ZEBEDEE product work that begins to address these issues in a Bitcoin-first financial world.

Fiat providers lack user interoperability

There’s an illusion that exists about interoperability between banks, fintechs, and money service businesses around the world. It may seem trivial to have two banking providers that speak the same money language be able to transact with one another seamlessly.

But like I said, that’s all an illusion.

In reality, banking partners that speak the same money language maintain vastly different technical standards and are thus not truly interoperable. This lack of standardization debases one of money’s most important properties — its ability to be freely transferred between any two parties.

Although both Cash App and Revolut understand the same money language of the US dollar and can freely transact with one another at the institutional level, their users aren’t afforded this luxury. Whether one is a user of HSBC or Chase, sending money to a user of Venmo or PayPal is virtually impossible. Transferring funds across providers has always been a laborious and expensive endeavor for end users.

Have you ever actually tried sending from your Cash App account to your Revolut account? Why can’t you?

One of the primary reasons why Cash App users can’t easily send money to Revolut users (or vice versa) is that an open permissionless global US dollar network standard that any participant can connect to does not exist. Cash App has its integrations with tradfi banking partners, and Revolut has different ones. This is the same for all banks, fintechs, and neobanks that rely on any fiat currency as their base money.

While there have been advancements in certain regions of the world to standardize inter-banking systems such as Open Banking/PSD2 in the EU and Zelle in the US, these systems are inherently not interoperable with one another and depend entirely on fiat currencies that themselves aren’t global in nature - e.g. a US bank still wouldn’t simply be compatible with an EU bank account.

The majority of these providers’ systems and APIs are still fully closed source, proprietary, and share little in common standards. This leads to lots of fragmentation and segmentation of our financial infrastructure world, a world marred by years-long banking partnership integrations that yield little-to-no substantial improvement in user experience across non-interoperable financial service providers.

Thankfully Bitcoin exists

Just like the internet turned information into data, Bitcoin turns value into data. Value that can be transferred, programmed, and reconciled by anyone in the network with true finality in a real-time fashion. Did I mention Bitcoin is global?

Also just like the internet, Bitcoin’s use cases and capabilities will only continue to expand as years go by. Those working on the early stages of internet infrastructure certainly did not envision a future where kids would be playing computer video games at 8K HD video definition directly from a server machine located in a different continent.

We’re still at the very early stages of what true digital sound money will achieve for society.

If you’ve never made a Bitcoin payment over the Lightning Network, I highly encourage you to take a minute here and do so. I recommend the ZEBEDEE App to get started.

One of Bitcoin’s strongest value propositions is that it is permissionless.

Akin to using the internet, there are countless ways of using Bitcoin. You can hold some coins in a hardware wallet for savings purposes, you can run your own bank by hosting and managing a full Bitcoin node stack at home, or you can rely on service providers to send and receive Bitcoin payments on your behalf. The choice is entirely up to the user. There’s no one dictating you must do X or Y with your Bitcoin. Don’t listen to those saying you can never spend your Bitcoin, or that it must only be used for savings in cold storage.

Bitcoin is a permissionless money system. It is to you whatever you think it is.

That being said, Bitcoin and Lightning Network, Bitcoin’s Layer-2 payments technology, are standardized technical protocols which require participants of the networks to interact with one another in specific ways.

Bitcoin Lightning payment interactivity

Let’s walk through a current user payment scenario with Alice and Bob. When Alice wants to pay Bob in Bitcoin, it would be expected (and necessary) for Alice to ask Bob for a Bitcoin address such that she can then send a transaction to the desired destination (note: onchain address reuse is discouraged for privacy-preserving purposes). The same can be said about this interaction if performed over Bitcoin’s Lightning Network. Alice needs to ask Bob for a Lightning payment request such that she can attempt to make a payment against it.

Not only do these payments require active interaction between the two involved parties, but a Bitcoin address or Lightning invoice can be daunting to those less-technical Bitcoin users.

While interactive payments like these are great for some types of transactions, such as buying coffee at the store or checking out from an e-commerce website where a single-use time-expiring payment request is created for the sole purpose of that one payment, it doesn’t cover all use cases, especially not those in asynchronous and on-demand scenarios.

What if there was a way to programmatically and automatically request a new payment code from Bob, instead of Alice asking for one every time?

LNURL → LN + URL → Lightning + Web

LNURL brings Lightning Network invoices to the web layer (think apps, websites, servers) in a standardized manner such that interoperability between providers is always achieved. It is a set of HTTP-based open-source API protocols that sit on top of the Lightning Network and perform payment request orchestration. LNURL’s aim is to improve end-user experiences by standardizing how the sending and receiving of Bitcoin Lightning Network invoices happens behind the scenes between two participants - usually a User (wallet) and a Service Provider (e.g. website, store, provider, exchange).

While it may seem that the first QR codes shown are identical to this LNURL QR code above, they are actually quite different. The latter can receive multiple Lightning payments of various amounts, from any wallet, and without expiry time.

By leveraging LNURL technologies, instead of having to ask Bob for a new payment request each time, Alice can now simply scan Bob’s provider’s LNURL QR code to programmatically pay him at any time, for any amount, in an on-demand fashion.

While this is already a major step up when it comes to improving user experiences when making on-demand payments, we are still dealing with QR codes. QR codes are universal, can be scanned by any smartphone or camera, and are easy to understand. Their ease of use, comprehensive range of flexibility, and large data storage capacity is what have made them so popular on a global scale.

But QR codes are not the future of payments, certainly not the future of web-first programmable payments. QR codes are interactive, and usually require two devices/mediums - one for scanning and one being scanned. As product builders, we should strive to provide better user experiences for both in-real-life (IRL) and online environments. For IRL flows (usually 1 payer to 1 payee), we simply need to take a look at how NFC technologies for smartwatches, cards, and tags have begun to take center stage in most modern payment experiences (e.g. touch credit cards, Apple watches, recent LN NFC developments, etc). On the other hand, for online-first payment flows (N payers for M payees) we still lacked a replacement for the good old pay me QR code.

Bridging the user divide

At its core, an email address is nothing more than an internet identifier stating that a user inside of a provider can be reached through the following address user@provider.com. For example, a Gmail user called Satoshi is emailed through satoshi@gmail.com (the same can be said of @yahoo.com, @hotmail.co.uk, @microsoft.net, or any other DNS-based domain). You can think of Gmail in this instance as Satoshi’s Email Service Provider.

Similarly, if Bob is a user of the ZBD platform, one would be able to reach him at bob@zbd.gg. Except that ZBD is not an Email Service Provider, but a Bitcoin Lightning Service Provider. Instead of sending emails to this address, one would send Bitcoin Lightning payments.

This is what is known as a Lightning Address, a massively simpler way for anyone to send and receive Bitcoin instantly over the Lightning Network.

First announced late last year, the Lightning Address specification has now been adopted by most of the wallets and service providers in the industry. It is hard to come across modern Bitcoin Lightning wallets that don’t support sending and/or receiving payments to Lightning Addresses.

The open-source protocol builds upon the LNURL specification and maps a payment QR code with an internet identifier (an email address-looking string). Ours are andre@zbd.gg and santos@zbd.gg. Go ahead, pick your favorite Bitcoin Lightning wallet and try to make a payment to any of our Lightning Addresses → We dare you!

Back in the Alice and Bob example: instead of having to ask Bob for a payment request every time, or having to visit Bob’s webpage to scan his provider’s static QR code, Alice can now use any modern Bitcoin Lightning wallet and simply send a payment to bob@provider.com - no interactivity necessary between Alice and Bob.

Yes, you read that right!

You can now send Bitcoin payments worldwide just like you send emails.

We are talking about truly global & instantly-settled asynchronous payments for users across interoperable Bitcoin Lightning service providers.

The same way you can send emails across providers, from Gmail to Outlook to Yahoo to Zoho, in an on-demand fashion, arriving instantly in the person’s inbox, thanks to the Lightning Address protocol you can now do the same with native internet money.

It’s so easy, even your grandmother could do it.

Given the fact that Bitcoin and Lightning Network are permissionless decentralized protocols, and the Lightning Address specification is fully open source (MIT licensed), anyone in the entire world can participate in this network regardless of geographical location, implementation details, or the actual amount of Bitcoin being sent or received.

Bitcoin means that a sovereign individual who self-hosts their entire money technology stack at home is completely interoperable with Fortune 500 companies’ Bitcoin and Lightning infrastructure, from day 0.

Provider-interoperable user accounts

The ZEBEDEE team recently released a brand new feature called Linked Accounts to users of the ZEBEDEE App. This feature enables UI and UX flows that showcase a new frontier of final settlement capabilities across geographical borders enabled by the use of native internet money — Bitcoin.

By leveraging the Lightning Network, Bitcoin’s layer-2 payments network, and the Lightning Address open-source protocol, we’re able to provide users with human-readable internet identifiers that allow anyone to receive global payments in an asynchronous & on-demand manner.

One of ZEBEDEE’s goals when building digital products is to craft user experiences that are so intuitive they can become second nature for users. Bitcoin and Lightning present a lot of technical complexities, and our aim is to simplify and abstract away the hard-to-understand parts from the user’s experience with the technology.

When withdrawing game winnings from the ZEBEDEE App, verified users will see a new Linked Accounts menu option, displayed above. Bipa, a Brazilian-based Bitcoin and Lightning Network exchange, is our first official Linked Accounts integration partner. Given that both ZBD and Bipa had Lightning Address interfaces for their users, the entire technical integration from kick-off to the first production build took just under 3 weeks!

All it takes is for the ZBD user to select the Bipa provider in the app and enter their Bipa Lightning Address. Users can then transfer Bitcoin from ZBD (US) to Bipa (Brazil) over the Lightning Network, reaching settlement finality in milliseconds and incurring virtually no fees.

That’s it! 3 simple taps and money has reached final settlement on a global transfer between two different providers. Bonus points if you use the auto-convert capability which turns your Bitcoin into Brazilian reais at the time the transaction settles.

Editorial (Santos Hernandez)

Back when I worked at American Express (Amex), I was part of the Global Data Repository team and as a Product Owner, I was involved in many bank-to-bank integration projects. These interbank projects would always span multiple years, going through months of commercial negotiations, followed by intensive product strategy and planning, to then finally arrive at actual software development and testing. Then, and only then, could these integrations receive their final production-ready implementations and go live to bank customers. I was personally involved on the team that integrated a Brazilian-based bank with American Express’s cards network, as well as the very first Chinese-American payment network to be integrated into the Amex system.

The reason these integrations always took so long during the development phase was that each and every bank did things their own way. There were very few interoperability standards that a new bank or fintech could follow to be easily connectable to all (if not most) of the participants. Every integration required its own technical solution, meaning that integrating the 1st bank, did not make integrating a 2nd, 3rd, or 4th fintechs any faster or easier.

All of these issues disappear under a Bitcoin financial system where all participants choose to adhere to one set of monetary network standards. And with the Lightning Address protocol, fintech providers can pass this powerful capability down to their users and serve them human-readable identifiers, reaching true interoperability between Bitcoin Lightning service providers.

Integrating Lightning Address means integrate once, connect everywhere.

The value grows as the network effects play out. Providers can now become fully interoperable with one another in a matter of weeks instead of months or years. By consuming the same open-source money standard of Bitcoin, the open-source payments network of Lightning Network, and the open-source user identifier protocol of Lightning Address, users can now send money instantaneously across the globe, to any number of users of any provider. No chargebacks, no delays, no outages. Just pure seamless UX for users to send global payments in real-time.

And we haven’t even touched on the fees! Due to traditional banking fees, microtransactions at scale aren’t feasible for any amount below $10 or in the case of wire transfers, approximately $75 due to a $35 wire transfer fee. You would also need to wait for the settlement, which could take days and carries a ton of risk for banks due to fraud.

The implications of these recent Bitcoin and Lightning Network developments are massive from a global and final settlement perspective, and we should all be paying close attention.

About Santos Hernandez:

Santos’ background is in building products and product teams at fintech companies, most recently being a Product Owner at American Express where he was on the team responsible for all things corporate data, payments, risk & compliance, data quality, marketing & sales, and banking partnership integrations. Currently he is the Business Lead of Product and Engineering at ZEBEDEE, where he is responsible for product design, development, and general strategy.

P.S. →Linked Accounts functionality is currently only available to Brazilian users through ZEBEDEE’s recent integration with Bipa. Stay tuned as more integrations are currently underway to support users of the various other countries and regions ZBD supports.

Resources

If you are a Bitcoin service provider that would like to learn more about Lightning Addresses you can check out some of the resources below:

• Lightning Address → lightningaddress.com

• Lightning Address for Service Providers → https://zebedeeio.notion.site/Lightning-Address-for-Service-Providers-0deeadc930b94697af919b21e71fe8b1

• LNURL Documentation → https://github.com/fiatjaf/lnurl-rfc

• Lightning Decoder→ lightningdecoder.com

Hello and welcome to LTW! This week we have the outstanding MintGox Bitcoin Esports tournament happening on Sunday the 31st at 2pm EST. Along with the community favorites Bitcoin Bounty Hunt and SaruTobi, ZEBEDEE will be hosting the second Bitcoin-Infused CS:GO deathmatch tournament.

Something tells me this is the last tourney before public beta release…

Alright, onto the technical things:

LND v0.12 Beta

After a few release candidates, the release for LND version 0.12 beta has been officially posted, and while we’ve covered some of the new features/changes in the releases of LTW #666,209 and LTW #662,816 I figured it couldn’t hurt to highlight a few others.

Automatic Database Compaction

If you’ve been running LND at scale for a while, you’ll notice that its database can get quite large after months of use and lots of onchain/offchain transactions have been performed. This is because bbolt database library used by LND does not give back free space to the system after data is deleted (intentional). However, large database files will usually lead to rather slow startup times.

Thankfully there is a way to compact your bbolt database. Effectively this compaction feature will create a new copy of the bbolt database only containing actual data and excluding any reserved space from previous data deletion operations. As you’d expect, it also helps with validating the integrity of the data in your bbolt database.

While one could always perform database compaction processes manually, an automated procedure has been added to LND that performs the compacting function on every startup (given some arbitrary cadence — e.g. every X days). To enable automatic compaction of your channel.db file use the --db.bolt.auto-compact flag, and to swap its cadence use the --db.bolt.auto-compact-min-age. Setting --db.bolt.auto-compact-min-age to 0 will force the process to run on every startup.

Check PR#4667 for more information.

Anchor Output Channels

We’ve already discussed Anchor Channels on LTW #666,209 but I did want to mention there was PR#4917 which modified some behavior.

This commit reverts the anchors-by-default change, and instead makes anchor commitments an opt-in option. The plan is to enable anchors by default further down the line.

Instead of anchor channels being the default for LND v0.12, the team decided node operators would likely need more time to make strategic decisions about anchor upgrade plans.

• How do the fee update sweeps actually execute?

• Can you Sybil-detect peers or analyze reliability to reduce your desired reserved UTXO size?

• Could you swap available off-chain funds for on-chain fee increases?

Olaoluwa Osuntokun from Lightning Labs does mention in the CHANGELOGS that “it's worth noting this is not going to be opt-in forever: anchors are a major step on a path to fundamental improvements in channel security.”

Nevertheless, one can already opt-in to anchor channels by setting the --protocol.anchors flag at startup. Other nodes that have this flag set will automatically open new anchor channels with your node.

Graph Optimizations

Another performance improvement that is packaged into the LND v0.12 beta release is a refactor to enable batching of all insertion operations that relate to the channel graph. This update should greatly speed up initial graph downloads when the LND node is starting up (recent benchmarks have shown a 3x speed increase).

Check PR#3367 for more information.

Check CHANGELOGS for more information on LND v0.12 beta version.

LNsync’s your network graph

One of the current pitfalls of running Lightning nodes on mobile devices is the always-online requirement. A Lightning node must be online primarily for two reasons:

• sending, receiving, and forwarding payments

• ensuring no channel-connected peer node is cheating your channel state

While not heavily used in the industry at the moment, Watchtowers are seen as a potential solution for the latter. The former however is a different concern. Nodes need to know the network graph in order to be able to calculate paths that route HTLCs, and without connectivity it is impossible to know the latest state of the network. While there have been improvements to initial graph downloads across implementations, it is common to have to wait long seconds/minutes for your mobile node to catch up with the latest network state — totally hindering the Lightning fast user experience.

This week Blockstream announced LNsync — a server-assisted gossip synchronization mechanism for Lightning nodes. Think of LNsync as a helper web-server that your mobile Lightning node can reach into and query for the latest state of the network. LNsync is powered by its own C-Lightning nodes that are constantly ingesting network graph data into a separate indexed database.

Using the historian plugin, we collect, deduplicate, and store all the gossip messages received by our C-Lightning nodes. The information is stored in a database and indexed for fast retrieval.

Because LNsync is consuming all of the changes in the network, it knows the changes pertinent to your node since it was last online. By making that information readily-available to the mobile node in a compact format, your node is able to re-sync with the latest state of the network in record time, allowing for payment route calculation to happen faster.

For example, catching up two hours results in about 500KB of uncompressed data, delivered in just over a second, while catching up on 24 hours results in about 6MB of data and requires approximately 2.5 seconds. This is significantly faster than a full sync using the gossip protocol.

This is a powerful tool because mobile wallet applications can now query changes from a specific point in time through an API powered by LNsync that delivers a minimal set of gossip messages required to catch up with the rest of the network.

Read more on the press releases: Announcement, In-Depth Engineering Blog

C-Lightning v0.9.3 Release

The C-Lightning team have just posted the release for version 0.9.3 of the node software, codenamed Federal Qualitative Strengthening. While this is a minor release there are a few goodies that are worth highlighting, both for users and node operators alike.

Lightning Offers

Rusty Russel has been working on an experimental implementation for Offers in C-Lightning. Offers are special Lightning invoices that allow for multi-use, refunds, and even different currency denominations. Although it is still a work in progress, in C-Lightning v0.9.3 there is experimental support for Offers.

“If you ever wanted to have an inline communication step with the other endpoint of a payment then take a look at this.”

Check out the RFC for technical details on how Offers work.

Custom Node <> Node Messaging

v0.9.3 also adds experimental support for sending and receiving arbitrary onion messages between nodes in the network. Node operators can use  sendonionmessage to send an onion encrypted/routed message, which node recipients can receive and parse using a plugin that register for the onion_message or onion_message_blinded hook.

Check PR#4328 for more information.

No More Reckless

From v0.9.3 onwards the C-Lightning software will default to using mainnet Bitcoin as the network of choice. Those using testnet Bitcoin C-Lightning nodes beware, after an update to v0.9.3 ensure that you are explicitly choosing testnet as the network.

Check the RELEASE NOTES and CHANGELOGS for more information.

Things I Would Share This Week

• Taproot Activation Discussion IRC Meeting — Michael Folkson announced a meeting to discuss details around BIP8 with regards to Taproot activation mechanisms and strategies. Join the ##taproot-activation IRC channel on Freenode at 19:00 UTC on February 2nd to take part.

• ZEBEDEE announces Bitcoin-Infused CS:GO — In the last MintGox event the team demonstrated the Infuse product on a live CS:GO Esports tourney. To be among the first to use Infuse and win sats playing Counter Strike, sign up here.

• WallStreetBetChairman tweets — No comments necessary

That's all for Lightning This Week, see you again in a few blocks time.

—AN

Hello and welcome to LTW. To start things off on a happy note, the team behind MintGox ESports tournament have released the details for the next event on Sunday January 31st. A total prize pool of 10 million satoshis are up for grabs for those willing to be challenged in matches of CS:GO, Bitcoin Rally, BBH and Turbo84.

The team was interviewed on the latest Swan Live Lounge podcast and released a video that explains the thinking behind MintGox and how it is different from any conventional ESports tournaments. Join MintGox and witness the future of Bitcoin Gaming.

Infusing Counter Strike with Bitcoin

If you’ve been living under a rock you may have missed the announcement, but the ZEBEDEE team have officially infused Bitcoin into Counter Strike: Global Offensive. Yes — that Counter Strike!

The purest form of global, digital economies are video games, but they lack a purely global and digital form of transactional value. So why not take an existing popular game and integrate Bitcoin as the value transfer protocol. The question we wanted to answer is: Does this add a new dimension to the gameplay that dramatically increases enjoyment and engagement?

On December 27, 2020, [ZEBEDEE] demonstrated this concept live at MintGox in front of an online audience of over 5,000 viewers. We successfully infused Bitcoin into Counter-Strike: Global Offensive (CS:GO), a multiplayer first-person shooter video game with 20 million monthly active users. And with that, the first public reveal of ZEBEDEE’s newest product, Infuse, will bring Bitcoin to the world’s most popular games.

With the power of Bitcoin’s Lightning Network, ZEBEDEE’s Infuse product will allow any CS:GO player to play Counter Strike and win sats against their opponents. Public release is expected in Q1 of 2021 with lots of servers ready to play. Get your Lightning wallets ready. To see Infused CS:GO live, make sure to participate in the next MintGox tournament.

Bitcoin Magazine Article: Bitcoin’s Killer Application: Skin In The Game

What is Trampoline Routing?

When Alice wants to pay Bob over Lightning, Alice’s node must first calculate a liquid route to send that payment along, such that it successfully arrives to Bob’s node. Recently Bastien Teinturier from ACINQ posted an updated specification of the Trampoline Routing mechanism the team has been using for over a year now with their Phoenix mobile wallet users.

Trampoline routing in its essence allows a spender (Alice) to pay a receiver (Bob) without needing to calculate a route between the nodes. Instead Alice can simply route the payment to a trampoline node that is then able to calculate the last part of the route to reach its destination. One can easily visualize how a set of trampoline routing nodes can be very powerful when used in tandem. If one trampoline node doesn’t know the last part of the route to reach the receiver, it can send that payment to another trampoline node which has a different set of peers and could be connected to the receiver. When a payment is sent to a trampoline node, we call that a bounce.

As mentioned before, ACINQ is using a trampoline routing node setup to handle incoming payments to users of their Phoenix mobile wallet. Since Lightning nodes need to be online in order to receive payments, this is super useful for mobile Lightning clients which are offline most of the time. Additionally when a node is offline for long periods of time, its understanding of the network graph/gossip is outdated, so route calculations could/would fail. Why calculate the route yourself, when you can let a trampoline routing node do that job for you?

This proposal allows nodes running on constrained devices to sync only a small portion of the network and leverage trampoline nodes to calculate the missing parts of the payment route while providing the same privacy as fully source-routed payments.

One obvious downside of relying on the current implementation of trampoline routing nodes to route your payment is loss of privacy. In order to route the payment to its destination, the trampoline node must know the details of that destination node. When running the trampoline node that backs the users of the Phoenix wallet, ACINQ is able to see the destination of all its users’ payments. The updated specification proposes a solution to this privacy leak by relying on onion-wrapper trampoline route details such that the trampoline node is unable to learn the node identifier for both the spender and receiver at any one time.

If you’d like to learn more about Trampoline Routing, check out Bitcoin Optech’s glossary.

Lightning-Dev Mailing List: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002928.html

LN RFC Specification: https://github.com/lightningnetwork/lightning-rfc/pull/829

New LND Documentation

Most software engineers would agree that what makes a great developer product is its documentation. With the recent releases of Pool, Loop, Lightning Terminal, and Faraday it was time for the Lightning Labs team to show some love for its documentation portal.

As a provider of software development tools for Bitcoin and Lightning Network, I’m thrilled to be able to point newcomers to this guide and have them choose their desired path, and level of complexity. With detailed guides for beginners, intermediate, and advanced users, the Builder’s Guide to the LND Galaxy has something for everyone.

Builder's Guide to the LND Galaxy: https://docs.lightning.engineering/

Anti-UTXO probing on dual-funded LN channels

A common issue when starting your Lightning Network trajectory and running your own node is opening and managing LN channels. Not only are operators encouraged to maintain liquid balanced channels, but they must also ensure their node is always reachable online so that payments can be successfully routed through those channels. Right now, when opening LN channels, the funds that get deployed are only coming from the side of the initiating node. This means funds can only be sent from the initiating node (as all liquidity is on their side of the channel), and effectively blocks the initiating node from receiving any payments on that channel.

In a not-so-distant future, all Lightning implementations aim to support dual-funding channel functionality. This means there will be support for the ability to open a new channel between two nodes where the initial funds are coming from both the node initiating the request and the node receiving the channel-open request. This will allow payments to be sent and received by both sides as soon as the channel is opened.

That said, a major concern with dual-funding channels is UTXO probing:

Before the initiator can sign the dual funding transaction, they need the identities (outpoints) of all of the UTXOs the other node wants to add to the channel. This creates the risk that an abuser will attempt to initiate dual-funded channels with many different users, learn their UTXOs, and then refuse to sign the funding transaction — harming those users’ privacy at no cost to the abuser.

An initial idea in 2016 was Proof of Discreet Log Equivalency (or PoDLE for short), first proposed by Gregory Maxwell for the JoinMarket protocol. It allows an initiating node (Alice) to commit to a UTXO in a way that prevents anyone from identifying that UTXO — Alice can show proof of owning the UTXO without revealing the details of the UTXO. Another proposal was posted by Darosior in the beginning of 2020 which dealt with interactively creating the dual-funding transaction using a chain construction through half-signed sighash_single & sighash_anyonecanpay transactions.

Recently we saw Lloyd Fournier post a new proposal to the Lightning-Dev mailing list where he expands on these previous ideas. Fournier proposes a simpler version of the half-signed implementation that is just as effective. In the new proposal the initiating node (Alice) creates and signs, but does not broadcast, a valid transaction that spends their UTXO back to themselves. This signed transaction is given to the receiving node (Bob) and can be verified as a valid transaction without giving details about the UTXO used. This is done as a token of good faith — if Alice fails to actually sign the dual-funding-channel transaction later on, Bob can simply broadcast the good faith transaction which forces Alice to pay an onchain fee, thus incurring costs and disincentivizing this behavior.

The idea is to adapt this protocol for Lightning Network in order to prevent attackers from learning which available UTXOs are controlled by Lightning node users.

Original PoDLE post for JoinMarket: https://joinmarket.me/blog/blog/poodle/

Lightning-Dev Mailing List: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-January/002929.html

Things I Would Share This Week

• Eclair v0.5.0 — In LTW #662,816 we covered Eclair in Enterprise Environments discussing the new architectural capabilities of the Eclair node software. The ACINQ team has since then posted version v0.5.0 of the implementation which includes this multi-node architecture, as well as many other goodies.

• LND v0.12 rc5 — Lightning Labs team just posted the latest Release Candidate for the LND software implementation. Node operators are encouraged to help test and find bugs.

• Bitcoin Core v0.21.0 — The latest version of Bitcoin Core was posted earlier this week. While there are lots of goodies to read from the changelog, I’m highlighing this because, you know, 21M BTC and version 0.21. It’s a must.

That's all for Lightning This Week - see you next time!

—AN

Hello and welcome to this week’s LTW. This is the last edition of 2020, so let’s make it a big one! To start off I’d like to invite you all to participate in this weekend’s MintGox Bitcoin-powered ESports Tournament on the 27th of December at 2PM EST. It is free for everyone to participate. All you need is a Lightning wallet like this one and you can win prizes of up to 1 million satoshis by playing online video game tournaments against other LN-gaming enthusiasts from around the globe.

MintGox #010 has a total event prize pool of 10,000,000 satoshis, and in addition to the community favorites Bitcoin Bounty Hunt, Turbo84, and Bitcoin Rally, the ZEBEDEE team will be announcing our latest Lightning Network gaming integration into one of the world’s most popular online games. You don’t want to miss this exciting event, one where it’s virtually impossible not to stack many sats.

The Kraken has risen

Kraken exchange has recently announced they will be supporting deposits and withdrawals through the Lightning Network starting mid-2021. In an interview with CoinDesk, Pierre Rochard from the Kraken team mentions that the recent improvements around Wumbo channels (large LN channels) and Multi-Path Payments (large payments that can be split automatically) were among the many reasons Kraken believes the network has matured, and thus the team is ready to integrate.

While there is still some time before any Lightning features are ready for primetime usage by Kraken users, it is great to see large players in the Bitcoin ecosystem gaining conviction about Lightning’s capabilities as a frictionless, cost-efficient transactional layer for Bitcoin.

“In 2021, we are committed to hiring a team to focus specifically on the Lightning Network, as part of our continuing effort to deliver the best possible experience for traders and investors. We expect to allow clients to withdraw and deposit Bitcoin on Lightning in the first half of 2021, which will allow clients to move their Bitcoin instantly and with the lowest fees.”

Kraken hopes to initially release a set of Lightning Network APIs, with support for LN withdrawals, and then follow that with iterative developments and features.

Official Kraken Press Release: https://blog.kraken.com/post/7225/a-need-for-speed-kraken-to-launch-bitcoin-lightning-%E2%9A%A1%EF%B8%8F-integration-in-2021/

LND v0.12 Release Candidate 2

The Lightning Labs team just posted a new Release Candidate for LND v0.12. The new major version of the software brings a lot of exciting features and improvements, specifically as it relates to committing/merging code that provides support for some LN protocol updates worked on throughout the year. Below I highlight a few of the features that a node operator should look out for in the new version.

PSBT Support

The LND internal onchain wallet can now create and sign PSBTs. In combination with the ListUnspent RPC this allows users to implement full coin control.

The feature also brings us closer to the future of having true watch-only onchain wallets powering LND, where an online node would only have public keys to track the UTXO’s, and can then delegate signing to an offline HSM or other LND node that has the private keys.

Anchor Channels

While Anchor Channels have been available to all LND users from v0.10 onwards, LND will now default to using this new channel type if both peers support it.

Anchor Outputs are special outputs in LN commitment transactions that are designed to allow the transaction to be fee-bumped.

The Anchor Channel type is a new type of channel that is much safer in high onchain fee scenarios, as it allows for bumping the fees after the channel has been force closed, instead of making the peers agree on a future close fee during channel opening. It also allows for a different economic model of fee-handling that puts the burden of paying chain fees on the peer that wants the channel close to happen the quickest.

This is also a nice improvement as less of the channel capacity needs to go towards the commitment fee reserve, and can instead be used for payments. In addition it allows bundling multiple HTLC transactions together into one, potentially saving on chain fees in force close scenarios. The commitment transaction still needs to be signed up front with a fee that ensures its mempool acceptance, and this fee now defaults to 10 sat/vbyte. An operator can configure this further by using the new --max-commit-fee-rate-anchors flag.

If you would like to opt-out of using Anchor Channels altogether, you must use the new --protocol.no-anchors flag to disable it.

Multi-Node Management

Gone are the days where an LND node was required to create on-disk unencrypted admin credential macaroons. With v0.12, hosting nodes on cloud hardware was made much safer by adding a stateless initialization mode that instructs LND to not store any unencrypted macaroons on the file system. Instead, the admin macaroon is returned in the response of the wallet creation request and must be stored by the caller of that request. One can now effectively spin up LND nodes in cloud providers like AWS / Azure and rest assured that the provider does not have access to the admin credential macaroons.

There are many more PRs and commits merged into this new release, for a full set of changelogs, refer to the Release Notes for v0.12.

New Channel Recovery & Backup Strategies

Given that the Lightning Network is an off-chain distributed system, and that channel state is only ever stored by its two connected peers, backups of channel state are of the utmost importance for node operators. In the current setup for Static Channel Backups (SCB), you must create a new backup each time you open / close a new channel. While SCBs are a great way to achieve fast recovery of funds, if for whatever reason you fail to create a backup when a new channel is opened, the only next option is to wait for your peer to close that channel on their own.

Lloyd Fournier recently posted to the Lightning Dev mailing list proposing a different approach to achieve fast recovery of channel state/funds without the need for static channel backups. By leveraging a deterministic key derivation method, your node would be able to search through the list of public Lightning nodes, combine information about the private keys derived from your node’s HD wallet with information about each node’s public key, and determine whether or not it had a channel with you (note: this backup strategy would only work for public channels).

Another proposal by Fournier that was posted to the Lighting Dev mailing list was the Covert Channel Recovery through Oblivious Signatures. In current LN, the existing mechanism to close a channel requires that your peer broadcast their unilateral commitment transaction. It’d be much cleaner and better if the commitment transaction was instead a mutual close transaction — less fees, not easily identifiable as an LN channel transaction onchain, and immediate access to funds. However a mutual close transaction does not support LN’s penalty mechanism, so if you request a channel close and your peer gives you an incorrect mutual close transaction (with less funds towards you for example), you’re unable to penalize them. While this isn’t technically a problem if you have the latest channel state, if you’ve lost your state / were unable to back it up, you’re now out of luck.

Fournier’s suggestion is to rely on oblivious signatures, which use a cryptographic primitive called oblivious transfer, which in short allows your peer to send you their mutual close transaction in an encrypted manner. Once received, you will be able to either use the transaction as is, thus closing the channel, or to prove that the transaction data cannot be decrypted, thus maintaining the channel active. The assumption here is that by using this oblivious transfer procedure every time your node reconnects to your channels, you wouldn’t need to reveal to your peers that you have lost any channel state data until after they’ve provided you all the information you would need to recover it.

Interesting new concepts proposed by Fournier on backing up channel state and fast recovery of channel funds. If you’re interested to read more details on the proposals, check the mailing list posts below:

Covert channel recovery with Oblivious Signatures: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002911.html

Recovery of Lightning channels without backups: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002911.html

Eclair in Enterprise Environments

When running Lightning Network nodes at scale, among many other things, operators need to be concerned about general node availability and redundancy. What happens if the node becomes unreachable or simply crashes? Does your node infrastructure setup have automated failover support? Do you have a disaster plan in place?

A concept familiar to most cloud engineers is high-availability (HA) — a system characteristic that aims to ensure uptime/operational performance under any circumstances. It is very common for essential services/servers to have at least 2 running instances — if something happens to one, the second instance can step in and handle requests/load. Up to this point it hasn’t been clear how to achieve a true high-availability infrastructure setup with Lightning Network nodes, as most of the node software itself has been tightly coupled with the data and networking layers.

PR #1566 changes this story for Eclair nodes. It merges code that provides Eclair operators for a way to run a `front-node` — essentially an Eclair node that abstracts out all of the connection-handling/messaging to and from the network, and allows it to be distributed across many Eclair instances. This provides a solution to achieve high-availability (HA) when running Eclair in production environments. As you can see from the diagram above, if one of your Eclair `front-node` crashes, another `front-node` can handle the load while a new ephemeral instance is spun up to replace it.

Another benefit of this separation is that CPU/bandwidth-intensive messages to handle node and channel discovery can also be handled by these `front-nodes`. Gossip messages, and channel syncing requests can now be taken care of by ephemeral, highly-available and fault-tolerant, distributed Eclair instances inside your production environments.

If you’d like to learn more about running Eclair in enterprise production environments refer to SuredBits latest field report, courtesy of Bitcoin Optech.

Things I Would Share This Week

• Bitcoin Optech 2020 Year In Review — Another year has gone by, another amazing Bitcoin Optech YIR newsletter. This is a must read as it covers all sorts of Bitcoin and Lightning protocol developments, including DLCs, Wumbo channels, Bitcoin Vaults, CoinSwap, PayJoin, MuSig2, Taproot, LN Pool and much much more.

• Lightning Network node provider Voltage adds ThunderHub support — If you’ve ever wanted to spin up a cloud-based Lightning Network node, look no further than Voltage. The team just released one of their customers’ most-wanted features: native ThunderHub support. ThunderHub is an open-source Lightning Network node manager that provides a great dashboard interface to use and manage your Lightning node. Starting today you can deploy a ThunderHub dashboard for all your Voltage nodes with a single click.

• We rendered a million web pages to find out what makes the web slow — This group analyzed the top 1 million pages on the web and tracked just about every conceivable metric, producing the first data-set to connect performance, error tracking and library-use on the web. The article thoroughly analyzes what the data can tell us about creating high performance modern web sites.

That's all for Lightning This Week. Happy Holidays and Merry Xmas from myself and the ZEBEDEE team. I look forward to bringing you weekly Lightning Network updates in 2021. See you in ~1,000 blocks.

—AN

Saluton my fellow Lightning enthusiasts!

Another week, another set of Lightning Network updates fresh from the interweb feeds. One topic of discussion that has seemed to pick up a lot of unnecessary attention on Twitter this last week was the recent discussion around sats vs bits when denominating values in Bitcoin.

Let me settle this tough one for you real quick: Sats are the standard.

Now that we got that out of the way, onto more interesting technical topics.

UTXO Stake Certificates

Channel-jamming attacks are network attacks where a malicious user/node finds a way to lock large amounts of bitcoin in a series of channels, effectively creating a `jam` in the routing of HTLCs. This is usually done by delaying the acceptance or rejection of the routed payment, so none of the previous nodes in the routed path will get paid / reveal pre-images. We’ve known about these possible attack vectors/scenarios since as early as 2015, and some similar `flooding` approaches have also been presented more recently.

Until the payment eventually times out, each channel used to route the payment is unable to use those funds to route other user’s payments. Since a route may cross more than a dozen channels, that means every bitcoin controlled by the attacker can prevent more than a dozen bitcoins belonging to honest nodes from being used for honest routing.

— Bitcoin Optech #126

With the intention of solving these channel-jamming attacks, Gleb Naumenko and Antoine Riard recently released a post to the Lightning-Dev mailing list explaining their proposal supporting the use of Stake Certificates.

Post: Mitigating Channel Jamming with Stake Certificates

The main idea behind the Stake Certificates proposal is for each payment to include a form of cryptographic proof that proves its spender controls some amount of bitcoin onchain (UTXO ownership proofs, a.k.a. fidelity bonds). This would allow routing nodes to have different policies and requirements based on the availability of certificates in the encrypted onion payload — how much value can be routed given how much proof of a certain stake of bitcoin is shown.

For example, Alice’s node could announce that it would route payments up to 0.01 BTC from anyone who could prove they controlled at least 1.00 BTC onchain. This would allow someone to route a payment through Alice’s node but limit how much of her capital they could tie up.

While this is an exciting approach to solving channel-jamming attacks (one that isn’t mainly comprised of different upfront channel fees), the team does note it is early days of development and there are quite large hurdles ahead — primarily the creation of such privacy-preserving cryptographic proofs.

You can also read the original post on the BitMex blog here.

Gossip Gets Throttled

Maintaining a network graph of the Lightning Network topology is a computationally-intensive task for the node software, and reducing the overall networking traffic can generally improve the stability of the network. There have been ongoing efforts by the Lightning Labs team to reduce the overall noise of graph messages that LND nodes send and receive. To further these improvements, LND will now default to throttling graph updates more strictly than in the past.

PR 4810 adds a new protocol configuration option to allow the enabling/disabling of gossip messaging throttling for each new node/channel. While the default is to enable the throttling functionality, operators are always able to deactivate it.

PR: https://github.com/lightningnetwork/lnd/pull/4810

Lightning Network Time Machine

Christian Decker or Blockstream/C-Lightning has released a CLI tool that is able to reconstruct the topology of the Lightning Network given a node’s stored gossip messages.

In Christian’s own words:

“We can replay the gossip messages in order and reconstruct the network as it would have looked like at a specific time in the past. This tool does just that, including the 2-weeks passive pruning logic (if a channel hasn't seen an update in the last two weeks they are considered dead).”

This is quite a nifty tool that would allow an operator to emulate the network topology from their own node’s viewpoint given a specific timestamp in the past. Because communication between Lightning nodes happen over gossip messages, by essentially replaying all of the messages one-by-one in chronological order, an operator can technically reconstruct the network state at any given time in the past — a Lightning Network time machine.

Source Code: https://github.com/lnresearch/topology/pull/1

Things I Would Share This Week

• Lightning Decoder v0.6.0 Release — If you’re a developer working with the Lightning Network, decoding and understanding BOLT11s and LNURLs is core to your development workflow. The latest release v0.6.0 of Lightning Decoder addresses some bugfixes and introduces support for automatically fetching and rendering LNURL Pay and Withdraw metadata.

• Bitcoin Magazine Podcast interviews the MintGox crew — Learn about the MintGox Bitcoin ESports Gaming series and the future of human commerce in gaming environments and worlds, powered entirely by Bitcoin and Lightning.

• 4.20% of all bitcoins in the network are currently held in corporate treasuries.

That's all for Lightning This Week. See you all in ~1,000 blocks.

Note: If I have misrepresented you or your company/project please reach out.

Hello and welcome to LTW! I don’t like intros — next!

Automating The Loops

Maintaining healthy balances across the many channels in a Lightning node is one of the most important tasks as an operator. Poorly-managed channels will lead to routing and payment failures, which are likely to impact how peer nodes’ routing algorithms see your node — less favorable to forward HTLCs through. While there are a handful of ways to balance one’s own Lightning channels, Submarine Swaps have quickly become an industry standard.

Submarine Swaps are atomic on-chain (Bitcoin blockchain) to off-chain (Bitcoin Lightning Network) swaps. Or vice versa, often called Reverse Submarine Swaps.

Initial implementations were made by Alex Bosworth, and the name was originally coined by Olaoluwa Osuntokun — one half is above water (on-chain), one half is below water (off-chain).

Loop is Lightning Labs’ product for providing Submarine Swaps for any node operator. Loop In and Loop Out provide both the chain-to-offchain and offchain-to-chain interfaces necessary. This means a node operator can rely on Lightning Loop to easily move funds from onchain to a ‘depleted’ Lightning channel, or from a ‘full’ Lightning channel to an onchain address.

While Loop/Submarine Swaps provided much needed functionality to operators, much of the process was still done manually. And if not, scripts to automate these procedures (if-this-then-that scenarios) would be built internally to the companies/teams. This week Lightning Labs announced Autoloop, which automates the entire process of making Loop Ins and Loop Outs.

“[Autoloop is] a new feature in Lightning Loop that allows Loop users to automatically balance liquidity, saving time and making using bitcoin on Lightning more efficient.”

With Autoloop, an operator simply has to set the % of inbound and outbound capacity they want in a specific channel (aka how they’d like to balance liquidity in the channel), and specify fee limitations — the rest is taken care by Autoloop. Every so often, Autoloop will check each channel in your node against the criteria set for it and if there are incorrect balancing scores, it will automatically initiate Loop Outs.

Yet another strong release from the Lightning Labs team!

NOTE: Autoloop only has Loop Out support right now. Loop In coming soon.

For those interested in learning more about upcoming features of Autoloop, please refer to issue #319. For full press release post can be found here.

C-Lightning v0.9.2 - Now with 0-of-N Multisig

This week we saw the C-Lightning team post a new release of their node implementation. This is a significant release with new CLI-level notifications, better channel state reporting, and stable plugin-hook call ordering. In lieu of re-writing what the team has already put on their CHANGELOG, I’ve simply decided to highlight a few points I found interesting.

Why did my channel close?

C-Lightning now keeps track of channel closure rationales. Wonder "why did my channel close" no more. All channel state changes are now listed in listpeers's state_changes.

Can I change the fee-rate for each commitment transaction?

New optional argument commitment_feerate on the multifundchannel command — useful for setting one feerate for the funding transaction and another for the channel commitment transactions.

Can I order the sequence of my plugins?

Plugin hook call-ordering is now real. Hooks can now specify that they must be called 'before' or 'after' other plugins.

Tired of not getting any updates?

With notifications, the close command will publish notifications (think CLI status updates) for slow closes. Must have allow-deprecated-apis set to false for these to work.

Read more on CHANGELOG and RELEASE.

NOTE: This release c-lightning-generated PSBTs are only considered valid by bitcoind v0.20.1 and above.

New Bitcoin Vaults

This week we also saw the announcement of Revault, a project by Kevin Loaec and Antoine Poinsot that aims to implement a new mechanism for creating Bitcoin vaults. The general idea is to build a multi-layered process using time-locks and different spending policies to dramatically reduce the possibility for complete steal of funds.

The secure storage and transaction of funds is a big challenge to Bitcoin users and especially to companies managing a substantial amount of bitcoins. The censorship resistance and lack of identity features of Bitcoin make it hard to setup a traditional control of expenses.

We propose a self-managed custody architecture for multi-party holders (such as a company or their third party custodian) aiming to dis-incentivize theft while limiting the impact on the practical movements of funds. A multi-layer access process is enforced wherein parameters (e.g. the length of time-locks value or the spending policy) of the system can be customized depending on the use-case and the needs of each user.

It’s always exciting to see releases like this that continue to innovate and improve on a user’s experience while self-custodying Bitcoin. Important to note that in the release a few technologies are highlighted as the reason why the project is feasible right now, specifically Miniscript, Bitcoin Core’s native descriptor wallet, and of course PSBTs.

Read the full paper here.

Things I Would Share This Week

• Bitcoin just reached a new price All Time High — Or did it?

• A Better Kubernetes from the Ground Up — If you’re a engineer/user of K8s, this was a really interesting read.

• DeepMind’s AI makes gigantic leap in solving protein structures — Fascinating work from Google’s deep-learning program for determining the 3D shapes of proteins.

That's all for Lightning This Week. See you all in ~1,000 blocks.

—AN

Hello Lightning enthusiasts. Another ~1,000 blocks gone, another Lightning This Week edition. No dilly dally today, cutting right into it, let's do this!

Lightning Network Static QR Codes

Last week ZEBEDEE released the zbd.gg companion app to the ZEBEDEE Wallet, which provides every wallet holder with a dedicated zbd.gg webpage linked to their unique ZEBEDEE gamertag providing a programmable, multi-use, interoperable QR code to accept payments of any amount with full commenting support.

One use for these new static QR codes that has become a quick favorite is in Livestreaming. Say you’re on a quest with your guild while streaming to Twitch, and you need some money to heal your character before tackling the final boss. Well, now it’s as easy as asking your Twitch viewers to scan the QR code on the screen. They’ll be able to send you emergency funds, along with a message, and participate in the quest that they helped make real.

Above you see MrCrazyJarvis and Christian Moss streaming and displaying their QR codes to receive tips and messages from their audience of viewers, directly to their ZEBEDEE Wallet mobile app. No longer are audience members simply passive participants in online events. Static QR codes help break the 4th-wall by allowing streamers to interact directly with their viewership through instantaneous micropayments and messages.

Value on the internet is no longer bound by a game, platform, or universe. Now internet money is accepted across any reality. All worlds speak Bitcoin.

ZEBEDEE QR codes are fixed QR codes that do not change, even when their underlying properties do. This enables interesting scenarios such as using QR codes for streaming, donations, and even in entirely offline environments.

While vital to the functionality of the network, Lightning Network invoices (BOLT11) have two major limitations: they are single-use and have a defined expiration time. While this lays out a great experience when performing on-demand or in person (IRL) payments, where sender and receiver are only interacting for an expected short period of time, it fails to provide similar flows online and in virtual environments. In these virtual scenarios, there may be many senders for each individual recipient, and payments may not be performed immediately after issuance of a payment request QR code. For example, if a popular game streamer is interacting with thousands of fans and viewers through a multi-hour stream, it would be impossible to create a single-use QR code for each of them.

This is where ZEBEDEE Static QR codes come in, powered by the LNURL Pay protocol. We empower you with a simple QR code that can be used in any setting, for an indefinite amount of time, to receive unlimited payments and messages from just about anyone in the Bitcoin Lightning economy — all tied to your ZEBEDEE Wallet and personal gamertag. Because Static QR codes are so versatile, your zbd.gg webpage can be used by your friends, colleagues, workmates, or guild buddies to pay, tip, gift, and send messages for as little as 1 satoshi.

Download ZEBEDEE Wallet here to get started!

CSV Configuration Options for LND

LND recently merged PR 4735 which adds further configuration control to the CSV (CHECKSEQUENCEVERIFY) delay of channels. Specifically this PR adds a new option MaxLocalCSV which specifies the maximum delay that the node will accept from a remote peer.

CSVs are a way to dynamically lock up the coins in the channel over a predefined time interval, and is enforced by the Bitcoin blockchain rather than the peer nodes themselves. CSVs will check for the current block height (the sequence) from the moment the transaction is included in a block, and will verify that the encumbrance scripts are met.

This change allows users to set a maximum CSV value that suits their specific use case and time preference. For example, given a channel between Alice and Bob, if Bob attempts to broadcast a false commitment transaction to attempt to fraudulently force close and give him all the funds in the channel, it is the CSV timelock that provides Alice a window of time to provide a breach remedy by broadcasting a penalty transaction.

Currently, CSV values are capped at 144 blocks, as an insurance that node operators won't set an unreasonably low CSV, possibly resulting in no channels ever succeeding.

Check the PR and the code diff here: https://github.com/lightningnetwork/lnd/pull/4735.

Backup Strategies for C-Lightning Operators

Managing a Lightning Network node is an active role. Node operators must ensure their nodes are available and online at all times, maintain an appropriate amount of well-balanced channels with well-connected peers, and take all precautions to ensure critical access keys/macaroons aren't improperly exposed. And while your Bitcoin node can re-fetch all of its blockchain data from any of its peers in case of disk failure/corruption, the same cannot be said about your Lightning nodes.

Lightning is an offchain protocol in which connected peers in the network can create channels with each other other, allowing for easy flow of funds. Every channel in Lightning has a state — a representation of the distribution of funds in that channel between the two peers. If Alice has a channel with Bob with 50,000 satoshis deployed, and Alice sends Bob 20,000 satoshis, the channel state must be updated to represent that payment accordingly, but this update is only ever visible by the two connected peers.

In other words, your Bitcoin onchain activity is recorded in all Bitcoin archival full nodes, so if you forget all your onchain activity because your storage got fried, you just go re-download the activity from your nearest peer.

But in Lightning, since you are the only one storing all your financial information, you cannot recover this financial information anywhere else. This means that on Lightning, you have to responsibly back up your financial information yourself, using various processes and automation.

Because of this every node operator should treat backing up their node's channel state with utmost priority. With that in mind the C-Lightning team has begun work on documenting the preferred/suggested ways of performing backups of your node's state, such that if an unfortunate situation occurs, you have defined paths and processes to safely attempt full recovery of funds, both onchain and offchain.

The document details the differences in sufficient criteria for recovering onchain vs offchain funds, and explains in length 4 different strategies for backing up offchain channel state: database file backups, RAID-based file system redundancy, remote NFS mounts, and PostgreSQL database clusters. Each of these have pros and cons, which depend on access to resources and backup/security-level choices.

I'd encourage any C-Lightning node operator to read through it: click here to read the Backup Strategies for C-Lightning (NOTE: PR still to be merged, so there could be changes to the document).

BONUS: C-Lightning has just tagged the v0.9.2 release but no changelog or announcement has been posted yet — probably something to look out for this week.

Channel Acceptors APIs

When managing a Lightning Network node, one mustn't accept just about any channels that are opened towards one’s node. This is why node implementations provide the ability to set minimum and maximum channel sizes, channel fee-rates, CSV timelock durations, etc. These are the criteria that allow a node operator to select which incoming peers they'd wish to have. That said, these are mostly non-interactive processes, and done automatically by node software — e.g. if my channel open request does not meet the necessary criteria, an error is thrown with a message to the peer.

While LND has had APIs to allow for interactively accepting or rejecting incoming channel openings, these didn’t provide much in the way of customization, until recently with the merge of PR 4683. If you rejected a channel with the ChannelAcceptor you were unable to send a message to let the peer know why that channel open was cancelled. Additionally, if you accepted a channel with the ChannelAcceptor API, you couldn't specify things such as close address destination.

This PR adds upfront shutdown, custom error support, and more fields that the ChannelAcceptor API can use, providing operators with more control over their incoming channel parameters.

With these changes, the ChannelAcceptor API becomes more useful as you can not only specify a custom error message, but also choose an upfront closing address for that channel.

Check the PR and the code diff here: https://github.com/lightningnetwork/lnd/pull/4683

Things I Would Share This Week

• MintGox #009 on November 29th 2020 — join us in this month's installment of MintGox, the Bitcoin Esports event, this time hosting tournaments for Bitcoin Bounty Hunt, Bitcoin Rally, Turbo84 and Sarutobi (play games and stack sats across mobile and desktop/web)

• PostgreSQL Benchmarks: Apple ARM M1 MacBook Pro 2020 — If you've been following the latest releases and announcements from Apple regarding their new M1 ARM chip, you'd enjoy this read. In my opinion Apple just once again made the MacBook Air the lead/role model of tremendous processing power in small laptops.

• Booting FreeDOS from a Vynil record — A lot of people have a lot of time in their hands, and when that happens someone is bound to try running an OS from a vinyl record. Because why the hell not?

That's all for Lightning This Week. See you all in ~1,000 blocks.

Note: If I have misrepresented you or your company/project please reach out.

Hello World,

IT LIVES — Lightning This Week is reborn! If you didn’t know, LTW is a project I started in November 2019 with the aim of creating a constant log of interesting developments happening in the Lightning Network space, with a deeper focus on the software engineering side of things. Every week I’d gather codebase changes (pull requests/issues) of major implementations, projects and documentation RFCs, new posted releases, discussions in mailing lists, and other general links, and then highlight a few items more in depth. After a few months of hiatus and some project restructuring, I’m happy to say LTW is back, this time as a Substack Newsletter.

The aim of Lightning This Week is to maintain tech-savvy Lightning Network (LN) enthusiasts and engineers at the forefront of the developments in the technology with a simple weekly digest. Short and sweet, straight to the point. I’ll also add in some opinion/interest links that I think might be worth your time.

Ecosystem is Growing

Oleg Mikhalsky and Moritz Kaminski just released a comprehensive research piece on the state of the Lightning Network. As the team states:

“Ongoing qualitative research on the advantages and disadvantages of the technology is providing reasonable evidence of the progress and remaining challenges, and the ecosystem has recently enjoyed more interest from the venture capital industry. But a comprehensive quantitative analysis was yet to be performed and we believe that this attempt paves the way for further systematic exploration of the ecosystem that will help answer questions about the domains of applicability of the Lightning Network and its incredible but yet to be fully uncovered economic and social potential.”

The research was conducted during summer-fall of 2020 and uses similar 2018 and 2019 research studies as base resources. The piece speaks for itself and I would encourage everyone to take a few minutes and read through it all. However, a point I’d highlight is how Gaming seems to be taking quite a central stage in this nascent industry.

We’ve now got game development tools and infrastructure for onboarding Bitcoin and Lightning into games enabled through ZEBEDEE. Lightning-enabled multiplayer games allowing players to earn and transact sats with one another by THNDR Games, Donnerlab, Satoshis Games, and others. And a monthly Bitcoin eSports Gaming event MintGox breaking the 4th-wall of interactions between audience, streamers, and players, enabled by the use of Lightning microtransactions. Be on the lookout for further developments in the Lightning Gaming front in the coming weeks and months.

Click here to access the entire database of companies and projects analyzed in this research piece — by Fulgur Ventures.

Swimming in the Lightning Pool

Lightning Labs team recently released the Lightning Pool product — a non-custodial, peer-to-peer marketplace for Lightning node operators to buy and sell channels. I think this is one of the most important Lightning-related product releases I’ve seen in a while, as Pool effectively makes Lightning liquidity a tradeable asset. The expectation that Bitcoin can yield returns is finally real, and it is achieved while maintaining full custody of your funds.

While the initial contract for Lightning Pool offers is set for providing incoming channels for a period of 2,016 blocks (~roughly two weeks / same as difficulty adjustment period), the team hopes to increase the offerings as the product matures and more network participants begin to provide liquidity. No longer must current node operators provide incoming channel liquidity free-of-charge. Pool helps create a market standard for Bitcoin liquidity in the Lightning Network.

At this time, there have been a total of 135 Lightning Pool contract offers that have been matched, totaling over 9.16 BTC in capacity. Long live Lightning financial markets!

Blockchain Eclipse Watchdogs

PR 1545 brings a new feature to the Eclair node daemon: Blockchain Watchdog — a watching tool that helps detect whether the Bitcoin node used by your Eclair Lightning Network node is suffering from an eclipse attack.

Eclipse attacks occur when a node is isolated from all honest peers but remains connected to at least one malicious peer. Without any connections to honest peers, the eclipsed node won’t receive the latest blocks on the most proof-of-work blockchain. This gives the attacker an unlimited amount of time to generate blocks containing double spends, so even an attacker with a small minority of hash rate can trick the victim into accepting confirmed double spends.

To achieve this the Eclair node will attempt to fetch block headers from multiple outside sources to compare with the local block headers from Bitcoin Core. If anomalies are found, the node is likely being eclipsed. The current external sources are set for blockstream.info, mempool.space, blockcypher.com and blockchainheaders.net, but more sources will likely be introduced. As it relates to Lightning specifically, a successful eclipse attack would provide the path for an attacker to hide a malicious channel closing attempt from you (with a false channel state that favors the attacker), as your Bitcoin node would never receive that block/header, and would thus be completely unaware that a Lightning peer is attempting to close a channel / steal funds.

Pubkey-Based HTLC Routing Discussions

Joost Jager recently proposed a change (addition?) to the Lightning Network RFC spec that would allow for a new HTLC routing mode based on a node’s public key instead of short channel IDs. The main advantage of short channel IDs is that they are short (8 bytes), but a great downside is that a channel ID corresponds directly to a channel point onchain. This is not a problem for public channels, as these channel points must be public such that other nodes are able to verify the channel’s validity/existence.

For private channels however, this is a data privacy leak as a channel point presumes the size of a channel, thus revealing the amount of funds deployed to such private channel. This makes nodes with large private channels a larger attack target, especially given Lightning Network nodes are essentially Bitcoin hot wallets. It would be a great upgrade in the context of a node operator with private channels that does not wish to leak information whenever they request an invoice.

Private channels are only disclosed in invoice route hints and don't need to be verified. The invoice is created and signed by the receiver […] Someone can theoretically request an invoice (or multiple invoices) from a service that accepts Lightning payments and inspect the route hints to gauge the service's node capacity.

There’s some discussion in the RFC issue around how to propose this (and future changes) — standalone BIP-style documents or a simple change to the specification. Click here to read more or opine yourself.

Things I Would Share This Week

• Rasbperry Pi 400 — If you’re a Raspberry Pi fan, the Pi 400 is a full Pi-based computer built entirely in a slick-looking keyboard. I’ve ordered one and hope to provide more details later.

• Bitcoin Bounty Hunt — Donnerlab just posted the latest version of BBH first-person shooter game with Lightning enabled. If you haven’t played it yet, get on it so you can participate on this month’s MintGox Bitcoin eSports Gaming event on Nov. 29th.

• NYC Mesh— a mesh network of interconnected nodes/hubs that provide internet access on a donation-based scheme. If you live in a densely populated area, you may have a similar project near you. Help out if you can!

That’s all for Lightning This Week. See you all in ~1,000 blocks.

Disclaimer: I’m always learning. If I have made mistakes or misrepresented you or your project/company please reach out so I can amend any posts.