BrunswickGanadoTutuilla
Bitcoin Lightning Network Node

BrunswickGanadoTutuilla

Rank: 6 / Tungsten Node
Capacity: 60,558,093 SAT (~0.606 BTC)
Channels: 29
Clearnet Lightning Address
03954e7547b198dae499f41d97b9055c9769d1b4da4534f2373a69b94d20712e19@64.33.171.130:9735
Tor Lightning Address
03954e7547b198dae499f41d97b9055c9769d1b4da4534f2373a69b94d20712e19@7brstdmwdhytltazjf4rwpk46dg7xulg252zb4checrjvjn3uthiuyyd.onion:9735
Pubkey
03954e7547b198dae499f41d97b9055c9769d1b4da4534f2373a69b94d20712e19
29 channels
Updated about 23 hours ago
Node
Capacity (SAT)
10,096,664
5,000,000
5,000,000
2,500,000
2,500,000
2,500,000
2,384,715
2,000,000
2,000,000
2,000,000
2,000,000
1,750,000
1,500,000
1,500,000
1,196,714
1,100,000
1,000,000
1,000,000
BrunswickGanadoTutuilla
BrunswickGanadoTutuilla
Last seen about 2 months ago · Joined 6 months ago

Geeking out on Lightning. Orange pilled AF. If you see fees on my channels that look inordinately high, its because the liquidity on my side is low and my fees-adjusting script is steering transactions away from there, not because I have unreasonable expectations. Fees are automatically set to zero for two days on new channels to allow rebalancing. Base-fee is always set to zero. ⚡️ brunswick@getalby.com

Verified

Opener

Passionate

Trustworthy

Honourable

Social

Resolver

Generous

LN+ Ratings Received:
12
0

Hubness Rank: 2867

Weighted for channel sizes: 2022

Lower numbers are better. Measures influence of a given node in the network. Better ranks imply a well-connected node that is linked to other well-connected nodes.

Hopness Rank: 4743

Weighted for channel sizes: 1197

Lower numbers are better. Measures how many hops it takes to reach any node on the network. The better the rank, the fewer the hops are required to reach other nodes.

Betweenness Rank: 2160

Weighted for channel sizes: 1655

Lower numbers are better. Measures how often this node falls on the shortest path between other nodes. The better the rank, the more likely the node will route a payments.

Metrics by LN node insight

Balancing with automatic fee adjustments

Balancing with automatic fee adjustments

Posted 5 months ago

Hello, I'm relatively new to lightning and just learned about fee adjusting scripts. With these, you can set fees on your channels based on their local v.s. remote balance and consequently steer transactions through your node so that your channels remain balanced. 

What are my options?

You could write your own script, or you can use someone else's wheel. First I tried a nodejs version but the main install method is broken, and after I manually compiled it, it would time out during rebalancing. It also didn't give much for configuration. Then I tried another one suggested on a website, charge-lnd a python based script. It works excellently. There are options to run it from cron or under systemd. It provides many config options and you can classify channels. You can apply different rules based on many criteria like activity, size, balance, remote or local end amounts, or node-id. 

What should fees be?

When I tried to figure out what values to use, I surveyed other nodes with 1ml. You can see what the fee settings are on any lightning node. I have found four primary categories of fee rates (percentage) with one variation (base-fee).

The first is the "default" which is 1 mSat base and 1 mSat per kSat (0.0001% or one millionth of the transaction). This is the default channel policy of  LND and probably others. You aren't going to make much in fees with this even with very high volumes. These are usually newbies, but sometimes the big boys stick with the defaults like coingate.com. A variation on this theme is the 'fixed fee' configuration where regardless of what is on the other end of a channel, all channels will be given the same fee structure ala "lncli 1000 100 144".

The second is the "on and off ramp" nodes, the ones that provide a gateway to fiat like Strike, Cashapp, Bitrefill and the ones that host custodial wallets like WOS, Muun and Bluewallet's lndhub.io. These usually have base fee set to 1 Sat, but occasionally they are set to 10 Sats (like lndhub.io) . The "big boys" like zaphq.io, set their fees to zero between their own nodes like between lndus0.zaphq.io and lndeu1.zaphq.io but to "outsiders" they set their fees to 2250 mSat/kSat (0.225%). Bitrefill.com's policy appears to be 1000 m/k, and lndhub.io appears to vary between 10000 (1%) and 1000 (0.1%). Given the high profitibility of their channels, they might be able to afford paying fees to rebalance critical nodes. More likely than not, when they need to balance between each other they coordinate zero-fee swaps over private channels, submarine swaps, or something else.

Then you have the "experienced router" who will use fluctuating fees to rebalance channels, but the fees will usually be set low to attract volume. They may have their mSat/kSat rate set to 40, 50, 100 or 250 for a balanced channel, but higher if the channel has remote liquidity, and lower if it has local liquidity.  They may apply a step-wise exponential curve based on channel liquidity percentage, or they may use a linear function, or a three-step high-middle-low strategy. In the case of triangle-swaps they will generally agree to temporarily set their fees for the balance but it shouldn't always be necessary if they have a high traffic node.

The fourth category is the 'altruistic node', these will have their node set to zero fees for everyone all-the-time. These can be an on-ramp for newcomers, but I'm unclear how they can sustain liquidity balance.

How do I benefit?

The conclusion I've come to during this rabbit-hole escapade is that the big-boys are all well-connected, and they usually don't want channels open to small-fry 0.1BTC nodes (if only for the inconvenience). The opportunity on lightning for us sub-BTC nodes is to stack-sats by setting fees low thus encourage high-transaction rate and connect to nodes a class higher and a class lower and in the same class as yours.

If you don't want to do the heavy-lifting when searching for the right nodes to connect with, I just discovered this.  Take a look at the Suggested Peers section of the terminal.lightning.engineering page for your node. They will give you some options to maximize your traffic if you aren't having enough success with triangle swaps.

When exactly are fees charged?

Its my understanding that fees are only charged when funds are sent out of a channel. For example, if you open a direct payment channel (on-chain) to a vendor to pay them with lightning, your lightning node will set-aside the fee before the payment goes out. The direct-connection will not pay any fees to the vendor because they are receiving the payment. In this case, the fee will be saved back into your node and you can spend it at a later time. In-effect a direct payment channel will incur no lightning fees.

In the case of your node routing someone else's payment, you do not collect a fee on the channel where the payment comes in, but you do on its way out. In the case of you being the destination node for the payment, your node collects no fees as the terminal receiving node.

Future-proof the network

Finally, I must mention base-fees. The common wisdom is that you want your base-fee set to one Sat per transaction. Some play with setting this to the minimum-but-non-zero value of 1 mSat/xaction. After listening to What Bitcoin Did and interviews with lightning developers, it appears this setting of 1Sat/xaction was intended only as a placeholder and for demonstration, and upon further reflection it should have been zero in production. This makes sense, particularly for us small-fries that want to encourage transactions. It also makes the network more flexible for purposes like messaging (sphinx) and other pico-transaction (dust) based applications. So I have to pass this along; Please consider setting your base fees to zero.

What about flooding/DDOS attacks you say? There are a few solutions for this, one is setting the minimum HTLC (minimum transaction size) to something nonzero (1 Sat is default), or you may want to look into circuitbreaker. I'm giving circuitbreaker a chance with the suggested configuration, but I'm unclear if its working or not after only having run it for a few hours.

Sample Charge-LND Config

This is probably all you really want to see from this post.  I'm running this script with cron from the pi user (raspibolt) with the following command. The electrum-server isn't necessary with this config, but I left it in in case you have one and want to use the onchain_fee fee strategy.

I started out with the raspberry pi OS image and stepped through the raspibolt instructions. charge-lnd had a library problem that was resolved in a ticket somewhere on github for the project which is implemented by calling charge-lnd through a bash script that exports a special library environment variable. This bash script should be set to executable, and placed in the same directory as the charge-lnd binary (charge-lnd's default install path is ${HOME}/.local/bin/.)

  • charge-lnd.sh
#!/bin/bash

export LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libatomic.so.1.2.0
# Yes the following line is intended to be obscure and cute, but it works
`dirname $0`/`basename $0 .sh` $@

The update script executes every hour on the 45-minute mark
  • crontab line
45 * * * * /home/pi/.local/bin/charge-lnd.sh -c /home/pi/charge-lnd/charge.config --electrum-server bitcoin.lan:50002


 As a point of reference, below is what I have in my charge.conf for charge-lnd. It uses a linear fee strategy, directly proportional to the remote v.s. local liquidity ratio applied to a number between 1 and 100 mSat/kSat. If your channels are balanced exactly at 50/50 the outgoing fee will be about 50. It also automatically suspends fees for new and unbalanced channels so your triangle swaps can happen at zero fees without your intervention. I had to make a few changes to this config to get it to work as intended. You must add htlc-min/max and base_fee or any other channel setting that is different between classes to each class because if a channel transitions from one class to another the defaults won't be implied. This is probably a bug in charge-lnd, but is resolvable by keeping this in mind.

  • charge.conf
# With the settings below, when channels are balanced,
# the ppm fee will settle to 50 mSat/kSat
# This file is evaluated sequentially, and the first
# match will execute on a channel, then the next
# channel will be reevaluated from the top.
[default]
strategy = proportional

min_htlc_msat = 100
max_htlc_msat_ratio = 0.99
base_fee_msat = 0
min_fee_ppm = 0
max_fee_ppm = 100
min_fee_ppm_delta = 5
time_lock_delta = 40

# Friends are those you want to keep at zero
# fees indefinately, at least until you
# remove them from friends.list
[friends]
node.id = file:///home/pi/friends.list
strategy = static

max_htlc_msat_ratio = 0.99
base_fee_msat = 0
fee_ppm = 0

# keep fees at zero for new incoming channels
# they haven't yet balanced, and their age is
# less than 5 days (720 blocks)
# This should give your triangle swaps sufficient
# time to balance
[new_incoming_channels]
chan.max_ratio = 0.05
chan.max_age = 720
strategy = static

max_htlc_msat_ratio = 0.55
base_fee_msat = 0
fee_ppm = 0

# keep fees at zero for new outgoing channels
# they haven't yet balanced, and their age is
# less than 5 days (720 blocks)
# This should give your triangle swaps sufficient
# time to balance
[new_outgoing_channels]
chan.min_ratio = 0.95
chan.max_age = 720
strategy = static

max_htlc_msat_ratio = 0.55
base_fee_msat = 0
fee_ppm = 0

# Cap fee at 5ppm when you have 90% or more
# liquidity
[high_balances]
chan.min_ratio = 0.9
strategy = static

max_htlc_msat_ratio = 0.99
base_fee_msat = 0
fee_ppm = 5

# Cap fee at 2250ppm when you have 5% or less
# liquidity and limit HTLCs to 10 kSats
[scarce_balances]
chan.max_ratio = 0.05
strategy = static

base_fee_msat = 0
max_htlc_msat = 10000
fee_ppm = 2250

# Cap fee at 250ppm when a channel has 20% or less
# liquidity, and limit HTLCs to 105 kSats
[low_balances]
chan.max_ratio = 0.2
strategy = static

base_fee_msat = 0
max_htlc_msat = 105000
fee_ppm = 250

2 Replies

Latest Swaps
Participating in 12 Swaps
Completed

Triangle Capacity: 1,500,000 SAT

View Swap ID: 8747
Completed

Square Capacity: 2,500,000 SAT

View Swap ID: 7356
Completed

Triangle Capacity: 2,000,000 SAT

View Swap ID: 7294
Completed

Triangle Capacity: 500,000 SAT

View Swap ID: 7066
Completed

Triangle Capacity: 5,000,000 SAT

View Swap ID: 7041
Description

BrunswickGanadoTutuilla

This bitcoin lightning network node identified by the pubkey: 03954e7547b198dae499f41d97b9055c9769d1b4da4534f2373a69b94d20712e19 also known by the alias: BrunswickGanadoTutuilla is accessible on the lightning network address: 03954e7547b198dae499f41d97b9055c9769d1b4da4534f2373a69b94d20712e19@64.33.171.130:9735 and 03954e7547b198dae499f41d97b9055c9769d1b4da4534f2373a69b94d20712e19@7brstdmwdhytltazjf4rwpk46dg7xulg252zb4checrjvjn3uthiuyyd.onion:9735 .

The node has 29 channels, and a total channel capacity of: 60,558,093 Satoshis, which is equivalent to ~0.606 BTC. The node's hex color is #68f442. The information regarding this node and it channels has been updated last on 2022-07-05 02:24:08 UTC.

This node page has been claimed by user: BrunswickGanadoTutuilla and has been verified through a digital signature as well. The user has created their account 6 months ago, and has been last seen about 2 months ago.

The user has participated in 12 swaps on LightningNetwork+. The node operator has opened 12 channels to LN+ users through Swaps. The user has received 12 positive ratings from other users. The user has generously donated to LN+ to support the operation of the site.

To learn more about this node, including historical data visit the following lightning network node explorers.