Export translations
Jump to navigation
Jump to search
Settings
Group
Anonymous edits and privacy
Backup/Recovery
Balance of Satoshis
Balancing Nodes
Bash aliases
BoS Telegram AutoStart
Claim on Amboss
FAQ
Fees And Profitability
Getting started
Help! I do not see any routing through my node
Help! My sats are only moving in one direction
How to translate a page
Iterm2
Lightning Exchanges
LND Configuration Settings
Local PlebNet groups
Loop
Main Page
Maintaining node hygiene
Mosh
Node Hardening
Node Hardware
Opening channels
Plebnet logo
Plebnet Playground
Ppm
Project Ideas
Push Channel Opens
Resources
Running A Profitable Routing Node
Upgrading Umbrel Node
UPS
Welcome to Plebnet
Language
aa - Afar
ab - Abkhazian
abs - Ambonese Malay
ace - Achinese
ady - Adyghe
ady-cyrl - Adyghe (Cyrillic script)
aeb - Tunisian Arabic
aeb-arab - Tunisian Arabic (Arabic script)
aeb-latn - Tunisian Arabic (Latin script)
af - Afrikaans
ak - Akan
aln - Gheg Albanian
alt - Southern Altai
am - Amharic
ami - Amis
an - Aragonese
ang - Old English
anp - Angika
ar - Arabic
arc - Aramaic
arn - Mapuche
arq - Algerian Arabic
ary - Moroccan Arabic
arz - Egyptian Arabic
as - Assamese
ase - American Sign Language
ast - Asturian
atj - Atikamekw
av - Avaric
avk - Kotava
awa - Awadhi
ay - Aymara
az - Azerbaijani
azb - South Azerbaijani
ba - Bashkir
ban - Balinese
ban-bali - ᬩᬲᬩᬮᬶ
bar - Bavarian
bbc - Batak Toba
bbc-latn - Batak Toba (Latin script)
bcc - Southern Balochi
bcl - Central Bikol
be - Belarusian
be-tarask - Belarusian (Taraškievica orthography)
bg - Bulgarian
bgn - Western Balochi
bh - Bhojpuri
bho - Bhojpuri
bi - Bislama
bjn - Banjar
bm - Bambara
bn - Bangla
bo - Tibetan
bpy - Bishnupriya
bqi - Bakhtiari
br - Breton
brh - Brahui
bs - Bosnian
btm - Batak Mandailing
bto - Iriga Bicolano
bug - Buginese
bxr - Russia Buriat
ca - Catalan
cbk-zam - Chavacano
cdo - Min Dong Chinese
ce - Chechen
ceb - Cebuano
ch - Chamorro
cho - Choctaw
chr - Cherokee
chy - Cheyenne
ckb - Central Kurdish
co - Corsican
cps - Capiznon
cr - Cree
crh - Crimean Tatar
crh-cyrl - Crimean Tatar (Cyrillic script)
crh-latn - Crimean Tatar (Latin script)
cs - Czech
csb - Kashubian
cu - Church Slavic
cv - Chuvash
cy - Welsh
da - Danish
de - German
de-at - Austrian German
de-ch - Swiss High German
de-formal - German (formal address)
din - Dinka
diq - Zazaki
dsb - Lower Sorbian
dtp - Central Dusun
dty - Doteli
dv - Divehi
dz - Dzongkha
ee - Ewe
egl - Emilian
el - Greek
eml - Emiliano-Romagnolo
en - English
en-ca - Canadian English
en-gb - British English
eo - Esperanto
es - Spanish
es-419 - Latin American Spanish
es-formal - Spanish (formal address)
et - Estonian
eu - Basque
ext - Extremaduran
fa - Persian
ff - Fulah
fi - Finnish
fit - Tornedalen Finnish
fj - Fijian
fo - Faroese
fr - French
frc - Cajun French
frp - Arpitan
frr - Northern Frisian
fur - Friulian
fy - Western Frisian
ga - Irish
gag - Gagauz
gan - Gan Chinese
gan-hans - Gan (Simplified)
gan-hant - Gan (Traditional)
gcr - Guianan Creole
gd - Scottish Gaelic
gl - Galician
glk - Gilaki
gn - Guarani
gom - Goan Konkani
gom-deva - Goan Konkani (Devanagari script)
gom-latn - Goan Konkani (Latin script)
gor - Gorontalo
got - Gothic
grc - Ancient Greek
gsw - Swiss German
gu - Gujarati
guc - Wayuu
gv - Manx
ha - Hausa
hak - Hakka Chinese
haw - Hawaiian
he - Hebrew
hi - Hindi
hif - Fiji Hindi
hif-latn - Fiji Hindi (Latin script)
hil - Hiligaynon
ho - Hiri Motu
hr - Croatian
hrx - Hunsrik
hsb - Upper Sorbian
ht - Haitian Creole
hu - Hungarian
hu-formal - Hungarian (formal address)
hy - Armenian
hyw - Western Armenian
hz - Herero
ia - Interlingua
id - Indonesian
ie - Interlingue
ig - Igbo
ii - Sichuan Yi
ik - Inupiaq
ike-cans - Eastern Canadian (Aboriginal syllabics)
ike-latn - Eastern Canadian (Latin script)
ilo - Iloko
inh - Ingush
io - Ido
is - Icelandic
it - Italian
iu - Inuktitut
ja - Japanese
jam - Jamaican Creole English
jbo - Lojban
jut - Jutish
jv - Javanese
ka - Georgian
kaa - Kara-Kalpak
kab - Kabyle
kbd - Kabardian
kbd-cyrl - Kabardian (Cyrillic script)
kbp - Kabiye
kcg - Tyap
kg - Kongo
khw - Khowar
ki - Kikuyu
kiu - Kirmanjki
kj - Kuanyama
kjp - Eastern Pwo
kk - Kazakh
kk-arab - Kazakh (Arabic script)
kk-cn - Kazakh (China)
kk-cyrl - Kazakh (Cyrillic script)
kk-kz - Kazakh (Kazakhstan)
kk-latn - Kazakh (Latin script)
kk-tr - Kazakh (Turkey)
kl - Kalaallisut
km - Khmer
kn - Kannada
ko - Korean
ko-kp - Korean (North Korea)
koi - Komi-Permyak
kr - Kanuri
krc - Karachay-Balkar
kri - Krio
krj - Kinaray-a
krl - Karelian
ks - Kashmiri
ks-arab - Kashmiri (Arabic script)
ks-deva - Kashmiri (Devanagari script)
ksh - Colognian
ku - Kurdish
ku-arab - Kurdish (Arabic script)
ku-latn - Kurdish (Latin script)
kum - Kumyk
kv - Komi
kw - Cornish
ky - Kyrgyz
la - Latin
lad - Ladino
lb - Luxembourgish
lbe - Lak
lez - Lezghian
lfn - Lingua Franca Nova
lg - Ganda
li - Limburgish
lij - Ligurian
liv - Livonian
lki - Laki
lld - Ladin
lmo - Lombard
ln - Lingala
lo - Lao
loz - Lozi
lrc - Northern Luri
lt - Lithuanian
ltg - Latgalian
lus - Mizo
luz - Southern Luri
lv - Latvian
lzh - Literary Chinese
lzz - Laz
mad - Madurese
mai - Maithili
map-bms - Basa Banyumasan
mdf - Moksha
mg - Malagasy
mh - Marshallese
mhr - Eastern Mari
mi - Maori
min - Minangkabau
mk - Macedonian
ml - Malayalam
mn - Mongolian
mni - Manipuri
mnw - Mon
mo - Moldovan
mr - Marathi
mrh - Mara
mrj - Western Mari
ms - Malay
mt - Maltese
mus - Muscogee
mwl - Mirandese
my - Burmese
myv - Erzya
mzn - Mazanderani
na - Nauru
nah - Nāhuatl
nan - Min Nan Chinese
nap - Neapolitan
nb - Norwegian Bokmål
nds - Low German
nds-nl - Low Saxon
ne - Nepali
new - Newari
ng - Ndonga
nia - Nias
niu - Niuean
nl - Dutch
nl-informal - Dutch (informal address)
nn - Norwegian Nynorsk
no - Norwegian
nov - Novial
nqo - N’Ko
nrm - Norman
nso - Northern Sotho
nv - Navajo
ny - Nyanja
nys - Nyungar
oc - Occitan
olo - Livvi-Karelian
om - Oromo
or - Odia
os - Ossetic
pa - Punjabi
pag - Pangasinan
pam - Pampanga
pap - Papiamento
pcd - Picard
pdc - Pennsylvania German
pdt - Plautdietsch
pfl - Palatine German
pi - Pali
pih - Norfuk / Pitkern
pl - Polish
pms - Piedmontese
pnb - Western Punjabi
pnt - Pontic
prg - Prussian
ps - Pashto
pt - Portuguese
pt-br - Brazilian Portuguese
qqq - Message documentation
qu - Quechua
qug - Chimborazo Highland Quichua
rgn - Romagnol
rif - Riffian
rm - Romansh
rmy - Vlax Romani
rn - Rundi
ro - Romanian
roa-tara - Tarantino
ru - Russian
rue - Rusyn
rup - Aromanian
ruq - Megleno-Romanian
ruq-cyrl - Megleno-Romanian (Cyrillic script)
ruq-latn - Megleno-Romanian (Latin script)
rw - Kinyarwanda
sa - Sanskrit
sah - Sakha
sat - Santali
sc - Sardinian
scn - Sicilian
sco - Scots
sd - Sindhi
sdc - Sassarese Sardinian
sdh - Southern Kurdish
se - Northern Sami
sei - Seri
ses - Koyraboro Senni
sg - Sango
sgs - Samogitian
sh - Serbo-Croatian
shi - Tachelhit
shi-latn - Tachelhit (Latin script)
shi-tfng - Tachelhit (Tifinagh script)
shn - Shan
shy - Shawiya
shy-latn - Shawiya (Latin script)
si - Sinhala
simple - Simple English
sk - Slovak
skr - Saraiki
skr-arab - Saraiki (Arabic script)
sl - Slovenian
sli - Lower Silesian
sm - Samoan
sma - Southern Sami
smn - Inari Sami
sn - Shona
so - Somali
sq - Albanian
sr - Serbian
sr-ec - Serbian (Cyrillic script)
sr-el - Serbian (Latin script)
srn - Sranan Tongo
ss - Swati
st - Southern Sotho
stq - Saterland Frisian
sty - Siberian Tatar
su - Sundanese
sv - Swedish
sw - Swahili
szl - Silesian
szy - Sakizaya
ta - Tamil
tay - Tayal
tcy - Tulu
te - Telugu
tet - Tetum
tg - Tajik
tg-cyrl - Tajik (Cyrillic script)
tg-latn - Tajik (Latin script)
th - Thai
ti - Tigrinya
tk - Turkmen
tl - Tagalog
tly - Talysh
tly-cyrl - толыши
tn - Tswana
to - Tongan
tpi - Tok Pisin
tr - Turkish
tru - Turoyo
trv - Taroko
ts - Tsonga
tt - Tatar
tt-cyrl - Tatar (Cyrillic script)
tt-latn - Tatar (Latin script)
tum - Tumbuka
tw - Twi
ty - Tahitian
tyv - Tuvinian
tzm - Central Atlas Tamazight
udm - Udmurt
ug - Uyghur
ug-arab - Uyghur (Arabic script)
ug-latn - Uyghur (Latin script)
uk - Ukrainian
ur - Urdu
uz - Uzbek
uz-cyrl - Uzbek (Cyrillic script)
uz-latn - Uzbek (Latin script)
ve - Venda
vec - Venetian
vep - Veps
vi - Vietnamese
vls - West Flemish
vmf - Main-Franconian
vo - Volapük
vot - Votic
vro - Võro
wa - Walloon
war - Waray
wo - Wolof
wuu - Wu Chinese
xal - Kalmyk
xh - Xhosa
xmf - Mingrelian
xsy - Saisiyat
yi - Yiddish
yo - Yoruba
yue - Cantonese
za - Zhuang
zea - Zeelandic
zgh - Standard Moroccan Tamazight
zh - Chinese
zh-cn - Chinese (China)
zh-hans - Simplified Chinese
zh-hant - Traditional Chinese
zh-hk - Chinese (Hong Kong)
zh-mo - Chinese (Macau)
zh-my - Chinese (Malaysia)
zh-sg - Chinese (Singapore)
zh-tw - Chinese (Taiwan)
zu - Zulu
Format
Export for off-line translation
Export in native format
Fetch
<languages/> <div lang="en" dir="ltr" class="mw-content-ltr"> = Intro = Most new NodeRunners struggle with the concept of balancing the node and channel and in the process, they end up being too fixated on rebalancing and targeting that magic 50:50 balance on each and every channel at tremendous cost and frustration. If your inbound <> outbound it is mathematically impossible to achieve 50:50 split on every channel so stop wasting time and sats on obsessive rebalancing. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Let us look at the concept of balance from a holistic level. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> = What is a balanced node = A perfectly balanced node is one where Sum of Local liquidity is equal to the sum of Remote liquidity Sum of Localliquidity on every channel is equal to sum of Remote liquidity on that channel. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> It does not exist. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> You can also consider a perfectly balanced node as a mirage. It is not possible. If a node is doing its jobs, there will be movements of Sats on channels. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> ==Why balancing is required== </div> <div lang="en" dir="ltr" class="mw-content-ltr"> The way LND protocol is designed, the channel capacity (girth) is available publicly. You can check it on graph, public explorers (like https://amboss.space/), and even on block chain. The channel id is composed of Block_Transaction_Output. For example, channel id <pre>690334x2723x1</pre> indicates that this channel was opened in block 690334 transaction number 2723 in that block and output 1 (remember first output is x0) in that transaction. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> However, the local and remote balance of the channel is not available publicly and to the network. It can be probed and guessed but it is not published as part of network gossip (to avoid transmitting too many gossip messages and overwhelming the network). </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Imagine a network where B->A->M (your node) ->Z->Y </div> <div lang="en" dir="ltr" class="mw-content-ltr"> When node B wants to send some sats to node Y, it can create a route, which could pass via your node M, but if you are not a direct peer of B, Node B would never know how much is on your local balance to send outward towards Y. Node B would have Local/Remote information about channel B->A, but not about Local/Remote balance of A->M, M->Z, Z->Y. Node B would only know the capacity of the channels but not the Local/Remote balance. Node B is the initiator node, it will use its logic to guess and most senders assume the channel has 50% of the capacity available as local. If the lowest capacity channel in this path is A->M for 1_000_000 Sats, B would assume it can send at least 500_000 Sats + Fees. It will create and HTLC for that amount and pass it on to A, who will pass it on to M keeping the fees for A->M, who will pass it on to Z keeping the fees for M->Z, who will pass it on to Y, keeping the fees for Z->Y. However, if M->Z only has 200_000 sats on local, this HTLC will fail at that point (which you see as <pre>failure: TemporaryChannelFailure at 689892x1307x0 from nofrixion_tokyo</pre> if you run bos rebalance). If there is no other route, the payment will fail and B can only send 200_000 sats on this route. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> To prevent such failed HTLC, which also punish your node (M) in the eyes of B (sender) because you caused them the inconvenience of trying a route where there were not enough sats on your local side, it is *advised* to keep your channels balanced. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> *Cetaris Paribus, your local and inbound liquidity is constant* This could be a difficult concept to understand but unless you are sending payments (or receiving invoices), and you are not opening new channels and plebs are not opening channels into you, your total node capacity, your Local, and your Remote will remain the same. No amount of routing will change this balance (except the small amount of fees you will earn for routing). </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Imagine your node (M) * Channel 1 with A 1_000_000 girth, 300_000 Remote, 700_000 Local. Imagine your fee on this channel is 2_000 Sats (base fee) * Channel 2 with Z 2_000_000 girth, 1_200_000 Remote, 800_000 Local. Imagine your fee on this channel is 1_000 Sats (base fee) </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Your node would show a total of 1_500_000 Remote and 1_500_000 Local. Pretty good balance even though individual channels are not balanced. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> If A sends to Z a transaction of 200_000 for which you earn a fee of 1_000 (lucky you). Note, the fee on Channel M->Z is applied for the transaction not the fee for channel A->M. The channels will look like this </div> <div lang="en" dir="ltr" class="mw-content-ltr"> * Channel 1 with A 1_000_000 girth, (300_000 - 200_000 - 1_000 (fees)) = 99_000 Remote, (700_000 + 200_000 + 1_000 (fees)) = 901_000 Local. * Channel 2 with Z 2_000_000 girth, (1_200_000 + 200_000) = 1_400_000 Remote, (800_000 - 200_000) = 600_000 Local. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Note, that the fee was calculated for channel M->Z but it is collected on channel A->M. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> And your node will now show a total of 1_499_000 Remote and 1_501_000 Local. Your channels have gone out of balance but your Local is still the same + fees earned (1_000) </div> <div lang="en" dir="ltr" class="mw-content-ltr"> ==What are your options now== </div> <div lang="en" dir="ltr" class="mw-content-ltr"> # Do Nothing Doing nothing is usually a valid and zero-cost option. If you do nothing, you are hoping for traffic to flow from Z->A in future which will auto-balance your channels and you will also earn fees in the process. This should usually be the first option any node runner should think of instead of rushing into rebalancing routines. # Circular Rebalancing If doing nothing is not helping and you are not seeing two-way traffic, and at the same time you see a lot of traffic going to Z (which is failing at your node and eventually using other routes) and you want to be part of the action to earn fees for that traffic you can do what is known as circular rebalance. Which is essentially paying yourself which goes OUT of the channel with local balance and comes back in from the channel with remote provided there exist a path. Doing this cost the routing fees and you must evaluate carefully what you pay for rebalacne v/s what you earn on routing. If your routing fees for M->Z are very low and the rebalance fees is very high, you will make a loss over time. Plebs sometimes ask if Circular Rebalancing is bad. Well there is no good or bad - circular rebalancing is a "tool" and costs to use the tool. It can be used to fix a channel or it can be used to create a DIY disaster. # Loop out This is the most expensive route. You payout to a custodial lightning wallet (or LOOP service) and take the coin on-chain. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> ==How to achieve balance with fees== </div> <div lang="en" dir="ltr" class="mw-content-ltr"> If you visualise the node as a tap between connected water tanks, your fees determine how much the tap is open. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Low Fee will encourage movement from Local to Remote. You decide what fee you are comfortable with based on your profitability expectations. If you have a lot of local balance on a channel, consider lowering the fees to the level you are comfortable with and it should encourage routing out to remote. Remember, you can bring the horse to water but you cannot make it drink. In the same way just because you have a lot of liquidity on local and set fees to super-low does not mean the sats will move to remote. It depends a lot also on your peer, and how that peer is connected. If the peer has set all their channels on super-high fees, then nothing will move from your node to them, because nothing will move from their node to further out into the network. The only time your channel will be used is if someone is sending a payment specifically to your peer. Many wallets and merchants fall in this category. Think of it as being connected to a village with 8 lane highway but only a few dirt roads leaving the village further out. Who would use that highway? In essence, think before you open a channel with a peer and see how well connected they are and if they are running their node with the same love and care you put into your node. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Setting a high fee, when you do not have local liquidity, gives a signal to the network that you are moving to the hard shoulder on a motorway when you are running out of fuel instead of blocking a lane. This will reduce failed HTLC events on your node because a sender tries cheaper routes first before trying expensive routes. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Remember you only earn fees on your local -> moving to -> remote. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> And when your sats are on Remote, you are at the mercy of your peer and their fees to allow routing back to you. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Plebs make the noob mistake of setting very low fees when their sats are local, then complain when the sats move to remote and do not come back without expensive rebalancing. Think of it this way. You roll a heavy rock up the hill (at a high rebalancing rate) and then provided a smooth path down so the rock keeps tumbling down again to your local. Your fees should be higher than your cost of rebalancing (or your flow should be two way flow so there is natural rebalancing). See the section on running a profitable node [[Special:MyLanguage/FeesAndProfitability|FeesAndProfitability]]. </div> <div lang="en" dir="ltr" class="mw-content-ltr"> === Some Practical Ways To Get Your Sats on Local again === </div> <div lang="en" dir="ltr" class="mw-content-ltr"> # Do nothing, let it flow naturally. Set fees to encourage. # Do circular rebalance, it will cost. Set future fees accordingly. # Create a route that will encourage the network to push liquidity through your node. For example a reasonably priced LOOP channel (which is in demand) can push most remote sats to your node (and go out to remote on LOOP). # Ask a friendly node to pay your node via your peer you want to pull sats from using <code>bos send --in</code>. It will cost but you can get your sats on local and set fee accordingly in future. You can pay your friend on-chain OR return the favour in future. </div>
Navigation menu
Personal tools
English
Log in
Namespaces
Translate
Variants
Views
Language statistics
Message group statistics
Export
More
Search
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Tools
Special pages
Printable version