Lightning This Week | 612,388
Private VPS through Lightning, Upfront Shutdown, RTL v0.6, Static v3 Tor Address, and Improved C-Lightning Node Failover
Hello Lightning Network enthusiasts, and Happy New Year! 2020 is the year of Lightning and ZEBEDEE aims to be at the forefront of the expansion of the network. First of, apologies for not posting LTW updates for the past two weeks — this was due to some internal deadlines as well as the break for the holidays. With that out of the way, we can go back to focusing on what matters — Lightning Network development. Lots of cool updates this week, let’s get to it!
Ride The Lightning (RTL) v0.6.0 Release
If you run a Lightning Network node there are few tools out there that compare with RTL’s expansive list of features. With support for both C-Lightning and LND it is one of the most friendly, yet feature-rich, open source control panels available. The recent v0.6.0 upgrade brings exciting new capabilities to the dashboard including better channel management, persona-based dashboard settings, and full dark mode support.
Release: https://github.com/Ride-The-Lightning/RTL/releases/tag/v0.6.0
Generate Static v3 TOR Address in C-Lightning
For those running C-Lightning behind Tor for increased privacy, you can now generate a static v3 Tor service address based on your node pubkey — just pass the following flag:
--addr=statictor:127.0.0.1:9051
With this a Tor node operator is able to keep the same public known Tor address static and fully independent of the .torrc configuration file (or the Tor instance itself). If you happen to move you node to another machine or server connection, as long as there is a Tor service running your node will be reachable through the same static Tor address.
Experimental KeySend LND Support
KeySend (also known as Invoiceless Payments, or Spontaneous Payments) is an experimental feature being tested and introduced to LND that allows a node to send funds directly to another node, without the need for an invoice to be paid. While KeySend is not part of the Lightning Network Specification yet, the LND team is moving forward with testing the feature and thus have provided a set of flag that can be used to allow the sending and receipt of spontaneous payments.
To enable receiving KeySend spontaneous payments, make sure to use latest master LND and start it with the --accept-key-send flag. Without this flag set, spontaneous payments will be completely rejected.
To send a KeySend spontaneous payment through lncli use the following (where <dest> is the pubkey of the destination node, and <amount> is the amount in satoshis):
lncli sendpayment -d <dest> -a <amount> --final_cltv_delta 40 --key_send
Only the payer and destination nodes are required to be running the experimental flag/latest master build, intermediate hops will support routing KeySend payments with any version of LND past 0.7.1.
Bonus: As mentioned in the PR, this is also the final step in enabling mainline lnd to send and receive chat messages (Whatsat).
Multi-Part Payments in Lightning Implementations
In Lightning This Week 607,974 we discussed AMP (Atomic Multi-Path Payments) and how its details had been agreed upon by the many implementation teams and had been merged into the specification. While AMP is still some time away in development (as it’s dependent on other features being tested/implemented), MPP (Multi-Part Payments) have already seen their time in the wild.
We’ve seen the ACINQ team add MPP support to their nodes/Phoenix wallet through trampoline payments, and we’ve had many PRs by the LND team to add support for MPPs in the many parts of the codebase. While the creation of MPPs is not fully abstracted into simple CLI commands yet, there is support for receiving MPPs without an operator having to perform additional tasks. C-Lightning has also added support for sending and receiving MPPs (but only at low level, which again means it’s not as simple to create MPPs yourself just yet, though possible).
MPPs are the first of a few stages of evolution we will see for Lightning implementations as the development moves toward full support for Atomic Multi-path Payments.
C-Lightning PR: https://github.com/ElementsProject/lightning/pull/3309
BitClouds: Private VPS through Lightning
Last week I discovered a new Lightning-enabled service called BitClouds that allows anyone to spin up a VPS (virtual private server) with a specific Linux distro simply by paying a Lightning invoice.
BitClouds offers regular distros like Debian and CentOS and Ubuntu, but it also has premade scripts for spinning up a VPN Server through OpenVPN, a Telegram Bot, or a Tor Hidden Service with FreeBSD, amid others. And the service is entirely open source as well.
It is really quite neat, in simple steps you can spin up a web server in Ubuntu with Nginx reverse proxy for only 420 sats (for 6 hours of use).
curl https://bitclouds.sh/create/ubuntuto request a spot Ubuntu instance- Pay invoice that is returned (
lnbc146...) curl https://bitclouds.sh/status/INSTANCE_NAME(e.g.xamir-331) to get the status of the server including SSH IP, port, user, and password- SSH into the server with
ssh root@INSTANCE_IPand use the password provided on step 3 - Run the command
sudo apt install nginx -yto install Nginx reverse proxy - Open your web browser and type
http://INSTANCE_IPand you should now see theWelcome to Nginxpage. This means your web server is running. Back in the server, edit the/var/www/index.htmlfile to see the contents of the webpage change.
Note: Currently the price for these spot instances is 420 sats for 6 hours of use, which assumes that the company is probably making money elsewhere by providing this service (e.g. possibly selling data gathered through those servers — so I’d advise against running mission critical software/sensitive information on these servers).
LND Adds Upfront Shutdown Option on Creation and Cooperative-Closing of Channels
This is a great PR for those concerned with onchain footprint and fee management. Before this got merged, LND would automatically generate a new onchain address to be used as the address for spending the coins when a channel is closed cooperatively (for more details on the different channel closing types in Lightning, read this answer on Bitcoin StackExchange).
With the merge of #3655, a node operator can, during channel creation, make use of option_upfront_shutdown_commitment to specify a script to which funds should be spent/paid out to when this channel is closed cooperatively.
PR: https://github.com/lightningnetwork/lnd/pull/3655
And with the merge of #3702, these capabilities are extended further by adding a new delivery_address property field to the CloseChannel request, effectively allowing node operators to specify an onchain address to close out/spend to on a cooperative closing of a channel.
PR: https://github.com/lightningnetwork/lnd/pull/3702
Bonus: Choosing an address for upfront shutdown during the creation of a channel will always take precedence over using the delivery_address field on the closing negotiation of a channel.
Improved Fail Over Node Support for C-Lightning
The C-Lightning team has merged a PR which enables an optimistic locking mechanism to the database the node is using. As C. Decker explains, if your node is currently connected to an external database such as PostgreSQL, this PR allows operators to fail over a node from one machine/container/server to another, without risking loss of funds (due to side effects, or data corruption, or even publication of old states).
To understand more of the details of this PR, I recommend reading through the PR notes themselves. C-Lightning seems to be moving towards a modern devops-friendly modular setup where parts of the application can be built/supported/managed in different architecture systems (e.g. running your database in a separate server as your Lightning node itself).
C-Lightning 2020 Thread
Lisa Neigut from the C-Lightning Blockstream team started 2020 with a long thread about features, code snippets, explanations, and even curious bits about the C-Lightning codebase and software ecosystem. Some interesting bits I noted are:
C-Lightning is a collection of daemons that talk to one another via file descriptors. Unix is the only OS that allows file descriptors to be passed to a new process at start, and that’s why C-Lightning hasn’t been ported to Windows.
Lightning was the first project to use SegWit-only addresses. This is because funding transactions need a strong guarantee that the transaction id (txid) of any signed transaction will not change. If the txid of the funding transaction changes, it would invalidate the pre-commitments that you sign for the shared 2-of-2 output that forms the channel balance, making your funds basically non-recoverable.
Full Thread: https://twitter.com/clightningcomit/status/1212810910731063297
C-Lightning on FreeBSD
This is a quick one, but for those running C-Lightning on FreeBSD machines, you now have the ability to install the binaries directly through pkg by running:
pkg install c-lightning
Doesn’t get much easier to spin up a Lightning node.
Bonus PR: YubiKey firmware now supports Secp256k1 out of the box. This could be something to integrate into HWI project for standardizing the communication between Bitcoin Core and Yubikey for signing.
Yubico Blog Post: https://www.yubico.com/2019/08/whats-new-in-yubikey-firmware-5-2-3/
That is all for Lightning This Week. If I’ve missed something important please let me know through the comments or on Twitter.
ZEBEDEE’s mission is to develop software and infrastructure to introduce first-class Bitcoin and Lightning support into digital experiences and gaming environments. This allows players, developers, streamers, and watchers to interact and instantly exchange value in a frictionless manner.
