In Costing, Node management by bretton / 2021-05-17 / 0 comments
Follow-up Blog Post
This post is a follow-up to our earlier blog post regarding costing and bandwidth usage for a small device with Bitcoind and LND.
One of the problems some members have with their LND nodes is the cost of hard drive space at cloud providers. It doesn’t make sense to spend R2500pm on 500GB of cloud storage when you can buy a hard drive for less.
To address this, and encourage more LND nodes in South Africa, we purchased a beefy microserver and enabled remote RPC & ZMQ access for members to use as a Bitcoind backend to their cloud-hosted LND node.
It works great!
However, we were slightly naive as to the bandwidth usage this would introduce.
This screenshot is the new Bitcoind node with a single remote LND user.
It’s doing ~65GB a day in traffic and initially exceeded the bandwidth allocation from our provider. Our provider then increased bandwidth limits from 1TB to 2TB and doubled limits for all their colocation packages.
This next screenshot is our first node, with Bitcoind+LND on same device.
It uses around 1.5GB a day in bandwidth and doesn’t ever go over the allocation from our provider.
Concerns
At the current rate of bandwidth consumption, with one remote LND node using 1TB allocation in two weeks, we can expect to see 2TB of traffic a month.
Adding another remote LND node would add another 2TB of monthly data to the consumption, or an overage charge of R5760pm.
This means two remote LND nodes would incur bandwidth overage charges of R5760 per month. That’s not sustainable for a non-profit.
It would be cheaper to buy a miniserver and hosting, and run your own Bitcoind+LND node, as the Bitcoind-to-LND communication wouldn’t incur bandwidth charges.
Other options to explore include
- Limiting the amount of traffic between the remote LND node and Bitcoind
- Running Faraday on the new Bitcoind host, with accounts support, as covered by this fork. Then multiple LND users could have their own balances, and connect to their own LN wallets. However, this is not yet ready for production usage.
- Running something like LNDHub to share an LND instance on the same Bitcoind node.
Alternative options for home users
If you have fibre, you can run a device like:
Make sure to read the chapter on node management in Mastering the Lightning Network.
If your ISP provides a fixed IP, then you can run a routing node.
If you have a dynamic IP, then your best bet is to use tor and open channels to a node such as ours and make payments. Your home node then becomes a spending device, a self-custody hot-wallet.
Conclusion
There isn’t any direct benefit to having a Bitcoind host (in South Africa) with remote LND nodes, as the bandwidth will exceed the costs of purchasing a small server and colocating it.
However if you can get a good deal on bandwidth, perhaps 2TB per month per remote LND client, or unlimited bandwidth, then it makes sense to go this route.
If you want your own Bitcoind+LND node, then buy a small device and colocate it at an ISP, as covered in our earlier blog post. This is currently the best deal you can get other than running from home on fibre with fixed IP.