FAQ

From PlebNet Wiki
Jump to navigation Jump to search
This page contains changes which are not marked for translation.
Other languages:
English

FAQ

Q1 Recommendations for Good Peers

There is no straightforward recommendation.

1- I would recommend all my channels as good peers. My channel list is public (like everyone else)

2- Terminal ranks peers based on their criteria.

3- lnnode helps you do channel simulation of how your centrality is impacted by adding someone as a peer.

4- gridflare provides recommendations individual to your own channel.

5- Communicating within plebnet groups let you interact with node operators who you can judge from their interaction as good peers

6- ultimately anyone willing to open up their node for routing and investing, time, effort, and sats to operate a lightning node is a good peer.

Also see Opening channels and Resources


Q2 Other node cannot connect to my TOR node

If the other node is a clearnet node, you would need to add them as peer first before they can connect/open channel to you. Otherwise, they'll get the error: "no suitable address found" when trying to connect to your node.

You can add peer via RTL/ThunderHub or other apps or using command line ~/umbrel/bin/lncli connect <PubKey or URI of the peer>. For example to connect to my node as peer, please use

~/umbrel/bin/lncli connect 03c5528c628681aa17ab9e117aa3ee6f06c750dfb17df758ecabcd68f1567ad8c1

OR

~/umbrel/bin/lncli connect 03c5528c628681aa17ab9e117aa3ee6f06c750dfb17df758ecabcd68f1567ad8c1@zacadqiqgi43tdv4ztjet2fh22f72ol2tokotp5cqdbszgx6tpyqdxad.onion:9735


Q3 Viewing Stream-Lnd-HTLC output in human readable format

steam-lnd-htlc is script used to monitor HTLC events on your node. However the output is in JSON format which may not immediately be human readable format. This can be solved by adding a custom alias

alias strhtlc='tail -f ~/stream-lnd-htlcs/htlc-stream.json | sed -e '\''s/, /\n/g'\'' -e '\''s/{/\n{\n/g'\'' -e '\''s/}/\n}/g'\'' -e '\''s/'\''\'\'''\''//g'\'''

replace ~/stream-lnd-htlcs/htlc-stream.json by the actual path of your output file from stream-lnd-htlc script.

after this each time you type strhtlc you will start looking at the output which you can read on screen. To stop press ctrl-c

you can add this line in your aliases files so that it is remembered each time.

nano ~/.bash_aliases add the line

alias strhtlc='tail -f ~/stream-lnd-htlcs/htlc-stream.json | sed -e '\''s/, /\n/g'\'' -e '\''s/{/\n{\n/g'\'' -e '\''s/}/\n}/g'\'' -e '\''s/'\''\'\'''\''//g'\'''


Save and Exit ctrl-x then Y then enter


Q4 How do I run stream-lnd-htlc 24x7

1. You can run in TMUX. See Umbrel_-_Installing_BoS#TMUX_Instructions for high-level instructions on installing tmux.

2. Use disown python3 stream-lnd-htlcs.py --lnd-dir ~/umbrel/lnd --silent SILENT --human-dates HUMANDATES 1>/tmp/stream-lnd-htlc.log 2>&1 & disown


Q5 Is there a minimum amount of capital required for running a profitable node

Theoretically yes, you need to understand that for being profitable you need to recover the initial investments as well as ongoing costs. Your investments are in the hardware, UPS, etc. Your ongoing costs are electricity, internet charges, hosting fees if you run in the cloud, and channel open/close costs. In addition, you may optionally spend on rebalancing.

Therefore a very small node is unlikely to return to profitability over its useful life before new investments in hardware would be needed.

Considering the cost of hardware around 1.5M Sat and the expected lifetime of hardware as 5 years, a 10 M Sat node would need to earn 300_000 Sat a year (1_500_000/5) or 2,500 ppm (300_000/12/10) net profit per month to recover the investment. Assuming the node can route 100% of the local balance in a month, the node would need to earn 2,500 ppm net fees for each routing. In the same situation, a 100 M Sat node would need to earn the same 300_000 Sats a year but it drops to 250 ppm (300_000/12/100) net profit per month to recover the investment. Assuming the node can route 100% of the local balance in a month, the node can be profitable with just 250 ppm net fees for each routing.

Therefore larger the node, the higher the chances of achieving profitability.

Do read further on running a profitable node and all related sub-sections.


Q6 How to allocate capital on a node? If I have 100 M Sat, how should I divide it?

There is genuinely no straight answer to this question and each node is unique in its objective and structure. However, it is easier to build a base first before worrying about centrality and hopness. Generally as a rule of thumb keep

  1. 30% capital for big chunky channels possibly to main routes (which you would discover only after watching the flow). These could the from the top 50 or 100 from Terminal Engineering or channels which improve your centrality, betweenness, and hopness. See the section on Resources for more details.
  2. 40% for swaps/balanced channels you open in community which gives you one inbound to one outbound with well-connected nodes (you can do rings/triangle etc). Plebnet, #Plebs2Salvador, and other swap services are good place for these nodes.
  3. Remaining 30% for building the community/fun projects/helping/mentoring beginners nodes. The smaller nodes today could be next big deal for tomorrow.

Q7 How much do I wait if I initiate force close? How can I control it?

When you initiate a force close, you will need to wait for "to-self-delay" number of blocks before your funds are returned. This is to protect your peer from a malicious close by your side and allowing them time to dispute the channel state. You do not control how much delay your peer imposes on you. At the time of channel open the peers negotiate to_self_delay. You impose on them, they impose on you. The following pameters in lnd.conf control the delay.

; The default number of blocks we will require our channel counterparty to wait
; before accessing its funds in case of unilateral close. If this is not set, we
; will scale the value according to the channel size.

bitcoin.defaultremotedelay=144

; The maximum number of blocks we will limit the wait that our own funds are
; encumbered by in the case when our node unilaterally closes. If a remote peer
; proposes a channel with a delay above this amount, lnd will reject the
; channel.

bitcoin.maxlocaldelay=2016

If defaultremotedelay is not set, then the delay is scaled up along with channel size. 144 blocks is roughly 24 hours. Please note this is the delay you propose to offer to your peer (i.e. if they force close, they would have to wait 144 blocks before claiming your funds).

MaxLocalDelay defines what is the maximum you are prepared to accept. If your peer proposes more than this, the channel is not accepted. Keeping it too high exposes you to long delays in force close. Keeping it too low may reject some channel open requests. 2016 blocks is roughly 14 days.