Someone just mentioned they are starting out on the Plebnet telegram and asked a few questions and it got me thinking about what I would like to have known before I started my first node.
Here's a non-exhaustive starting list off the top of my head (but what about you, comment with yours):
  1. Launch a testate/regtest/signet node or cluster of nodes and play with rebalancing tools and other sidecar apps—always keep your testnet/regtest/signet nodes running so you can test software/hardware upgrades before enabling them on your main node. On testnet, you can connect to other testnet nodes, and on regtest, you can just spin up a bunch of your own nodes and test. Using Multipass, Proxmox, or raspberry pi nodes is great for test clusters. Getting testnet/signet coins is a huge pain, but there are ways
  2. Don't open tiny channels or liquidity pool loops with new nodes that don't have contact info (open very intentional channels to nodes that have contact info and that you can build a relationship with).
  3. Make a plan for your first set of 5-10 channels and batch open them in one go to save on opening fees, except for whatever channels you can arrange dual-funding to open. Generally, if you are not dual funding, use batching to save on fees when opening.
  4. Tune your node configuration settings (and understand all of them in detail before you launch)
  5. Your first set of channels should probably be around the same size (e.g. you might want to open 5-10 2M or 5M sat channels if you have 0.1-0.5 BTC to start out)—if you open a 10M channel to one node and four 1M channels other nodes, that one bigger channel will be wasted since you can’t send anything bigger than just under 1M through your node anyway.
  6. Look for a triangle swap that has really good partners and balance the triangle immediately after opening (again, coordinate fees and activities with your node partners and use your testnet cluster to learn hands-on)
  7. Be mindful of your startup hardware. A lot of nodes die because they are using cheap external HDD/SDD attachments to a raspberry pi. These are great for your test nodes with fake funds, but use better hardware or cloud hosting like Voltage for your production node (I almost launched my first node on a raspberry pi, luckily dodged a bullet)
  8. Be mindful of database issues—this is the most common cause for nodes dying and losing funds. If you are on LND and are using channels.db (default), make sure you have good hard drive storage and RAID redundancy (or as some node runners have had success, a plan to test and migrate your M2 drives every few months). If you are running a custom LND with postgreSQL (e.g. https://github.com/blckbx/lnd_postgres), think about database replication and backup. Whatever you decide for your software/hardware needs, make deliberate choices rather than just installing and running whatever is default. Also think about this when you plan for your failover scenarios. Get a UPS but you might want your network to fail before your node shuts off to prevent HTLC updates and db writes during what could be a poweroff event
  9. Use an auto-fee tool and ensure you have good partners that do the same to make rebalancing economical for each other
  10. Beware of opening your first channels directly to sinks (large nodes that just eat your inbound liquidity if you set the rate too low and you don’t see that come back for a long time if ever)
recommend setting this in lnd.conf
coin-selection-strategy=random
The default value (largest) will grind your UTXOs to dust
reply
1854 sats \ 0 replies \ @anon 26 Feb
Your list is great, I was thinking more high level for someone running a self custodial Lightning app such as Phoenix, Breez, Mutiny, Zeus, etc:
  1. Basic 4-7 minute explanation of channels and channel liquidity. This seems to be the most common thing that confuses and frustrates people at any level of LN use. If you don't understand these basic concepts you're in for a world of hurt.
  2. You should do this because you are passionate about the LN and can endure a few bugs/headaches, and not because you want to make a profit. If you can only tolerate a perfect bug free experience then the LN is a few years off from being up to that. It's so early.
reply
Don't run an implementation that doesn't support full rdbms with existing tooling to scale it and that focuses on bringing tokens to lightning instead of fixing the issues that plague the network
reply
492 sats \ 0 replies \ @OT 26 Feb
I would remind myself that Lightning is still very early.
Don't put in what you wouldn't want to lose.
Understand that there will be a lot of time spent troubleshooting/researching.
Understand that channels can be seen as linked with the LN node ID (unless using unannounced channels).
reply
About replication - does DB replication provide any advantage, compared to RAID1 with the same number of replicas? I think that with RAID1, if sector 100 of disk1 is unreadable, and sector 200 of disk2 is unreadable, then you still have all the data and it is easy to recover. By contrast, with DB replication I don't see a way to recover, at least haven't found anything in Postgres documentation. So RAID1 seems safer. Am I missing something? Maybe DB replication is more about availability if HW (not just disk) breaks down?
reply
postgreSQL db replication can be done across machines and data-centers--that's more of a cloud-centric model for scaling and redundancy, but if you want to be as production grade as a social network or financial institution, it might be desired to have the option to do offsite live replication. You can setup postgres in active-active so you could have a failsafe node that boots up and uses a remote copy of the db and just takes over... this is all much more detailed though for a pleb. Mostly, the advice for the node runner starting out is to do some reseach and pick a technology stack that is going to be the direction of least pain for studying and implementing, but in reality, any and all of the options can blow up.
reply
Lightning is a hell of a thing to run, ain't it?
reply