Posts

What sort of Lightning Node do you need? - Part 4

avatar of @brianoflondon
25
Dr Brian of London ✅
@brianoflondon
·
·
0 views
·
7 min read

Part 4 - Lightning Node Basics

See the other parts here

Conclusions upfront and @v4vapp news

All of the learning below about nodes is heading toward where I can hopefully bottle it up and pass it on.

As I said in my current DHF proposal, the long term goal is to make the kind of Lightning Hive Bridge which I'm running an open source package which any enthusiast can run. This is getting closer and when my current proposal runs out in a little under a month, I will submit a new one which will be a very substantial piece of work to make what I'm running relatively easy to pass on.

Lightning and Hive are being exchanged regularly in both directions and I'm seeing new accounts find the service often now. If you have used the Lightning Hive Bridge from @v4vapp I'd love to hear your feedback: post about it on Hive tagging @v4vapp or comment here please!

To Host or Not To Host

I've covered both the main reasons not to run a node (unlikely to make money routing unless you make it a full time obsession) and the other reasons to have a node (vastly improved Bitcoin transaction privacy and the ability to run a range of other apps along side it).

But assuming you do want to run a Lightning and full Bitcoin node, how should you do it? I'll explain my path and give back some learnings.

Self Hosted Umbrel at Home

My first toe in the water was with the Umbrel software on a Raspberry Pi 4. I bought the hardware here in Israel for around $300 which was a Pi 4 with 4gb or RAM, a power supply, a 1 TB SSD with an external enclosure and an SD card.

I set this up and turned it on and then waited. Eventually it took 10 days to download and synchronise with the entire Bitcoin chain. Toward the end of that Umbrel upgraded their software which fixed a problem which had been slowing me down. I also didn't have Fiber at that time, today I do. I suspect if I had to do a full re-sync and download my Raspberry Pi would take a couple of days.

You can use better hardware: more processor speed is good. The SSD is pretty much non-negotiable. It can be done on a spinning hard drive but the initial setup is particularly slow.

Pros

  • This setup is excellent if you want to learn about what it takes to run a Unix server. It's within your control, you can hook up a monitor and keyboard and hack away.
  • If you want to write small python scripts or interact with the node programmatically in some other way, having it on your desk is helpful. You don't have to worry so much about ports and networking.
  • Umbrel is set up to talk to the rest of the Lightning and BTC networks only via Tor. This is a huge privacy win but comes with some downsides.
  • You can receive Keysend Payments or streaming sats for a Value Enabled Podcast: this is a big one for podcasters. If you've installed Umbrel as your base, you'll find an app called Helipad which tells you about Boostograms and streaming payments received.
Side note

You don't need a node to receive streaming sats for a podcast if you already have a Hive Account! You can do that without running a Lightning node:

Short version: go to https://podcasterwallet.com/ and claim your podcast by getting an email sent to the address in your podcast's public feed. Then put in the following Public Key:

0266ad2656c7a19a219d37e82b280046660f4d7f3ae0c00b64a1629de4ea567668

And add the customKey of 818818 and the customValue should be your Hive name eg brianoflondon.

Cons

  • Your node has got to be running 24/7. If you have flaky internet running a Lightning node at home is a problem. Once you have open channels, the rest of the network expects you to be online. If you go offline for an extended period, your channel partners may well close channels on you, if you're lucky you'll get the correct amount owed to you. If you go offline for a long time, things can get problematic.

  • Your node is only connected via Tor. You don't have to open any ports on your router, but conversely, accessing your node from outside your home is slow and somewhat unreliable.

  • Channel management and where your sats are is going to be your responsibility. You might wonder why you don't receive any payments for a while then realise that you have no inbound liquidity.

  • If you want to run any kind of more sophisticated payment receiving system, which relies on a direct connection to your node such as BTCPay Server or LNURL, you'll need to be comfortable with port forwarding and possibly even setting up DNS forwarding and certificates.

Cloud Node from Voltage

After my first few months of building for @v4vapp, after I'd built the ability to receive streaming sats and forward those to Hive and the ability to swap Hive into Lightning, I hit a wall.

I realised in order to complete the service and offer Lighting into Hive by paying the standard Lightning QR code invoices, I was going to need to have my node "on the web". That meant opening up connections into my home to my Lightning Node.

Lightning is NOT like any other crypto: the concept of having "an address" to which you can send value is not quite there with Lightning. There are ways of sending unsolicited funds to a specific lightning address called Keysend and Amp and this is used for Podcasting 2.0 Value payments but this is a special exception. Even for this, the node receiving the funds must be online and have adequate liquidity in the right channels to receive.

If you click on this link, a window will open up and shortly afterwards a unique, one use only QR Invoice will pop up. That invoice will make a 3333 sat payment to my Voltage Lightning Node and then my software will send that on to my @brianoflondon Hive account.

Behind the scenes that web page (which I built) calls an API running on a server which I built. I'm opening up the docs for that API today and you can take a look at them

https://api.v4v.app/docs

This API is available for any Hive developer to use: put in a Hive account and a number of sats an you'll get back a long string you can turn into a QR code. Pay that and the corresponding Hive will be sent to the Hive account. It works. Any Hive front end could add Lightning tipping (like Twitter has) right now. Only on Twitter it only works if you KYC into Strike in the USA. On Hive you can already receive value.

I need to pair that external API with an external Lightning Node and I chose the provider Voltage.

Why not self host?

It turns out that because of the requirement to store the entire BTC blockchain, preferably on at least 1TB of SSD storage, paying for a cloud VPS server to do this is quite expensive. In fact it is prohibitively expensive and comes to over $80 per month on any option I could find.

Voltage are specialists

There are ways to share the storage of the blockchain but this is a specialist feature. Because Voltage have ways to do this, they can give an always on Lightning node for closer to $10 per month for a basic node. That's what I'm running on now and I'll upgrade as and when I need to.

I still have to manage it completely myself, but it turned out that switching from my own node at home to a cloud node really wasn't that hard.

Voltage use the same back end implementation of Lightning (LND) that I was working with on my Umbrel. There are some webhooks and other internal Voltage tools I use for unlocking the node remotely from my own server, functions which Umbrel doesn't have by default.

Pros

  • Voltage nodes run in a proper data center with 24/7 monitoring and support.
  • Automated backup systems.
  • The node runs on both Tor and clear-net and has a static IP and domain name. This is a huge advantage over running a Tor node at home. Tor slows down various aspects of Lightning and it does seem that payments and route finding are more reliable.
  • Using Voltage keeps the cost at rock bottom for this hardware because they're taking steps to share the 460gb of Bitcoin blockchain data across a number of Lightning nodes. This has no noticeable impact on performance or security but drastically cuts hardware requirements.

Cons

  • The node is remote and there are some extra steps like Whitelisting IP addresses which are necessary for security.

  • Voltage is a dependency and a single point of failure.

  • Backing up a Lightning node is not trivial and there really isn't a good solution to restoring a failed node.

  • Cost (running on your own hardware at home on an internet connection you pay for anyway is always cheaper!). Unless you actually have a business service in mind, it seems like a lot to pay for having a node of your own.

Conclusion and @v4vapp news

All of this learning is heading toward where I can hopefully bottle it up and pass it on.

As I said in my current DHF proposal, the long term goal is to make the kind of Lightning Hive Bridge which I'm running an open source package which any enthusiast can run. This is getting closer and when my current proposal runs out in a little under a month, I will submit a new one which will be a very substantial piece of work to make what I'm running relatively easy to pass on.

Lightning and Hive are being exchanged regularly in both directions and I'm seeing new accounts find the service quite regularly now. If you have used the Lightning Hive Bridge from @v4vapp I'd love to hear your feedback: post about it on Hive or comment here Please!

Support Proposal 201 on PeakD Support Proposal 201 with Hivesigner Support Proposal 201 on Ecency

Posted Using LeoFinance Beta