Once Lightning Lab announced (and surprised many) that they are releasing a beta version for mainnet, I decided that I want to deploy a node and work from there. My thoughts were to document the progress here once I successfully run the LN node and experiment with paying and receiving money across the network. Turns out its going much slower for me than I anticipated, hence I decided to break the log and document each decision and step I'm doing separately. I'm not sure whether there would be much interest in each blog post separately, but I'm hoping that overall it'll be of use to someone.
I'm not a Linux, Devops or Bitcoin/LN expert, so any of the decisions or operations I'm going to describe here and in future post are necessarily the right way to go. If you have comments on any, I would really appreciate it, and update the posts as they go along.
Run a full Bitcoin node:
LN server requires RPC access to a full Bitcoin node. So for practical reasons I should run one. I would easily allow some dude to have RPC access to my Bitcoin node, so I shouldn't expect other to do that too.
Run on AWS:
First I plan to run all servers on AWS. LN and Bitcoin servers need to be online. I'm using small instances in N. Virginia region. I selected this region as I don't have in mind any requirement for proximity to my location, all new AWS features are always available (at least historically) in this region first, and pricing wise its among the cheaper regions.
I'm deploying t2.small instances with 500G EBS memory. Per Bitcoin Core recommendation for running a full node, the minimum RAM needed is 2G. Memory wise the blockchain size now is more than 160G, and for sync (and maybe other) operations you should have at least double the size in memory.
In AWS small general purpose instances are the cheapest available that have 2G memory. The on-demand price for the instance only is $0.023 per hour, which is about $17 per month. Bandwidth and memory would add to this price, but that's the ballpark. If use of this instance is successful, its always possible to pay in advance and have cheaper prices per month using a reserved instance.
Use VIM as editor:
I'd like to be able to contribute to the LN open source code. I'd like to be able to develop on the same environment I'm deploying. I may be able to use docker on my laptop for that, but for now I want to use an editor I can run on remote instances as well, and can be operated fully using the keyboard. I'm usually more inclined to use emacs, but the vim-go package by Fatih Arslan looks like the right tool I should use. He has a Go development with vim-go Youtube video, and a tutorial.
Learning the vim-way takes practice. I have vim 101 beginners guide, vim buffers, windows and tabs, Demystifying Multi-file Searches in Vim and Let vim do the typing Youtube video open. Hopefully these resources are enough, together with the vim-go resources above.
Use Tmux:
If you need to open multiple terminals to a remote node, or do any operation for a period of time, you must use a terminal multiplexer. Otherwise it becomes unmanageable and each time you move your laptop or have a network disconnect you have to setup everything from the beginning. I've done some reading and decided to use tmux, which is installed by default on ubuntu 16.04. tmux shortcut & cheatshit is opened on my tabs.
Those are the tools and decisions I made. Comments and suggestions are welcome.