Blog

Finite Fields

Finite fields are the mathematical concept underlying elliptic curves which are used heavily in cryptography.

A finite field is a finite set of numbers and operations that satisfy 5 properties. Let us define a finite field of order p as follows:

F_p = \{0,1,2,...\ p-1\}

The set must meet these properties to be considered a finite field.

Closed Property

a,b\in F_p => a+b \in F_p

Additive Identity

a + 0 = a

Multiplicative Identity

1 \times a = a

Additive Inverse

a \in F_p => -a \in F_p

Multiplicative Inverse

Let\ a \ne 0\ and\ a \in F_p => a^{-1} \in F_p

In order to satisfy these properties we must redefine the mathematical operators (addition, subtraction, multiplication, division and exponents) in the context of a finite field.

We will denote the mutated operators for finite fields as follows to avoid confusion with the default operators:

+_f \ \ \ \  -_f\ \ \ \ \times_f\ \ \ \ \div_f\ \ \ \ a^{x_f}

Addition in Finite Fields

Let\ a,b \in F_p => a+_f \in F_p
a+_fb = (a+b)\%p

Subtraction in Finite Fields

Let\ a,b\in F_p => a-_fb\in F_p
a-_fb = (a-b)\%p

Inverse in Finite Fields

Let\ a,b \in F_p => -_f a\in F_p
-_fa = (-a)\%p

Multiplication in Finite Fields

Let\ a,b \in F_p => a\times_fb\in F_p
a\times _fb = (\sum_{n=0}^{b-1}a_n+_fa_{n+1})\%p

Division in Finite Fields

Let\ a,b \in F_p => a\div_fb \in F_p
a\div _fb =  a\times_fb^{(p-2)}

Exponentiation in Finite Fields

Let\ a \in F_p
a^{x_f} = a^{x\% (p-1)}\%p 

The Best Bitcoin Songs

Bitcoin – Captain Youth

Bitcoin – Soulja Boy

Bitcoin Beezy

Bitcoin All the Way Up

Welcome to the Blockchain

Love You Like a Bitcoin

10’000 Bitcoins – Laura Saggers – Original Music Video

Ode to Satoshi

Not This Time (The Bitcoin Obituaries Song)

Zhou Tonged – Holding (Billy Joel – The Longest Time)

Bitcoin Girl – Original Music Video (Official, 2014)

Zhou Tonged – Don’t Get Zhou Tonged!!! (Sister Nancy – Bam Bam)

Zhou Tonged – Cyprus Anthem (Swedish House Mafia – Don’t You Worry Child)

Bankster’s Paradise

Gramatik – Satoshi Nakamoto MUSIC VIDEO (feat. Adrian Lau & ProbCause)

Price Down, Pick Up!

End of Silk Road

Bitcoin Barron

How I set up my fees on c-otto.de

The following article was published behind a paywall on yalls.org. Please support the author by buying access to the post.

The author is Carston Otto. 

Information wants to be free. Paywalls set the price for liberation. 

I run the node c-otto.de (Amboss), which currently provides more than 19 BTC in 238 channels. My node forwards several thousand transactions a week, earning decent fees. I also automatically rebalance most channels, which is only possible due to the fee settings as described below.

I’m also the author of rebalance-lnd.

Start High

For most peers, I don’t know which fee rate is appropriate. Sadly, I already experienced that a new channel was drained and closed before I had the chance to tweak the fee rate. Because of this I had to pay for the open and close transactions, leaving me with close to no sats earned in fees.

The main problem of starting with a low fee rate also exists if my peer does not close the channel, and even if the peer opened the channel to my node: At the very least, I’m missing out on fees. I may also need to rebalance the channel (pull the sats back to my side), which can be too expensive given the low fee rate I charge.

I currently have 10,000ppm configured as the default fee rate (which is absurdly high), so that a new channel starts with 10,000ppm before I decrease it as described below.

Lower and Upper Bound

I rarely know a single good fee rate for any peer. However, I know which fee range may be appropriate. As such, for each node I consider lower and upper bounds, and set the fee rate accordingly based on the ideas outlined below. Currently, my default range is 2-1000ppm, so that a new channel always starts with 10,000ppm (as described above) which is then reduced to 1,000ppm.

Decreasing the Fee Rate

My fee settings should help a node become and stay active. No matter what the current fee rate for a specific channel is, it doesn’t help if I don’t forward any sats. As an example, 500ppm might be fine for a channel to BitFinex, but I won’t be able to route a lot to The Lorax (hi đź‘‹) at 500ppm. If I have lots of sats on my side of the channel, I can either wait and hope, or decrease the fee rate.

That way, possibly after decreasing the fee rate in several steps, I can find the “sweet spot” for each channel and see that it starts forwarding. Only then, with actual traffic at a known fee rate, it makes sense to ask certain questions:

  • Is the channel active enough to be considered “good”?
  • Do I want to open another channel to that peer (to provide more liquidity and possibly earn more)?
  • Do I want to invest into the channel in order to always have x% / y sat on my side of the channel (auto rebalance)?
  • Is the channel a good source for rebalance transactions?

Frequency of Adjustments

Even with a node as active as mine, changes like a decreased fee rate don’t have an immediate effect. The network needs to forward the updated information to other peers (gossip), and I need to wait for new payments making use of my channel.

Initially, I waited several days after every fee rate change, but more recently I learned that I’m also happy with more frequent adjustments in certain situations. If most of the funds are on my side of the channel, say 90%, the risk of draining the channel is rather low. As such, if I decrease the fee rate and don’t see any forwarding for a day or so, I feel confident that I can decrease it even further. If, however, I do see a forwarding transaction, I wait and see if the current fee rate is sustainable.

If I don’t have as much on my side of the channel, say just 20%, I tend to wait longer. As the channel is already imbalanced, I don’t want to worsen the situation by giving the network more incentives to drain the channel. However, as those sats are there to be forwarded, I will decrease my fee rate if the channel stays idle for some time. Whereas I might just wait one day for “full” channels, I tend to wait several days for “mostly empty” channels before decreasing the fee rate.

Sources

For peers that I consider sources, i.e. nodes that mostly send sats to my node and rarely are the targets of forwarding transactions, I want to make sure that the remote side always has funds to send to my node. As such, I need to decrease my fee rates to incentivize peers to send sats (back) to my peer, and to help rebalance-lnd using this channel as a source (see below).

In some cases, especially if lots of sats are on my side of the channel, I think it’s a good idea to configure a fee rate of 0ppm. That way I’d earn nothing by forwarding to the peer, but I’d be able to profit from sats routed from my peer through my node and out other channels (hopefully with a high fee rate).

Decreasing for Empty Channels

For channels which are empty, i.e. there are (close to) no sats on my side of the channel, it does not make any sense to decrease the fee rate. I won’t attract more forwardings (as I don’t have any sats to forward), and it won’t improve my chances of rebalancing (as I cannot take sats out of the channel).

As such, I just leave the fee rate the current setting and resort to other options (rebalancing, waiting).

Increasing the Fee Rate

I only consider increasing the fee rate for channels that are active, i.e. channels that are targets of forwarding transactions. No matter what the current fee rate is, if some channel is able to attract lots and lots of forwardings, I might as well increase the fee rate and see if (enough) people are willing to pay the higher price.

Of course, the increase fee rate may be too high, so that there won’t be any forwardings. In this case, I need to decrease the fee rate again (as described above). It might help to then try increasing again (after traffic starts to pick up again), but with a smaller step size: If an increase from 600ppm to 700ppm wasn’t successful, I might try increasing by just 50ppm instead of 100ppm next time.

Frequency of Adjustments

When considering increasing the fee rate of some channel, I look at the recent forwardings on that channel. If, for example, the channel forwards on 9 out of 10 days, I’m pretty sure that the current fee rate is good, and that a higher fee rate might also work.

In order to avoid channels being depleted (and, possibly, hard to rebalance), I increase the fee rate faster for mostly empty channels than for balanced or full channels. Similarly, I increase the fee rate less frequently for channels with lots of the funds on my side, to help my peer having funds on their side of the channel. As an example, if a channel already has 90% of the funds on my side, I only increase the fee rate if I see very frequent forwardings (which also means that, due to incoming traffic or rebalance transactions, my node doesn’t have any issue maintaining the high local balance).

Increasing for Empty Channels

While I don’t recommend decreasing the fee rate for empty channels, I think it’s a good idea to increase the fees for (mostly) empty channels. If, for whatever reason, my peer sends sats to my side of the channel, I can immediately benefit from the higher fee rate. Furthermore, if I try to rebalance the channel (sending sats to my side), the higher fee rate will give me more options.

Rebalancing

I’m using rebalance-lnd to rebalance most of my channels automatically. For this, the configured fee rates play a very important role.

In general, a rebalance transaction makes sense if you take funds out of a “cheap” channel (you charge a low fee rate), and send them back to you via an “expensive” channel (with a high fee rate). If, for example, you have a channel where you charge 40ppm and another where you charge 100ppm, sending funds from the former to the latter gives you the option to route the amount for 60ppm more than before.

Of course, after taking the sats out of the first channel, you won’t be able to route the amount at 40ppm. In addition, you also have to pay for the rebalance transaction, which is only reasonable up to the difference of 60ppm.

The logic in rebalance-lnd takes all three costs/fees into account and only considers rebalance routes that are “worth it”. As such, by having channels with low fee rates and lots of outbound liquidity, I can help rebalance-lnd to send sats to (mostly) empty channels with a high fee rate.

Because of this even channels with low fee rates can be very helpful to run my node, as rebalance-lnd automatically uses the “cheap” liquidity to transform it into “expensive” liquidity.

Conclusion

These are just my thoughts, none of this is universal truth. The lightning network constantly changes, which also means that the fee rates need to be adjusted frequently.

I hope my thoughts help you configure your own node, and maybe the spark some new ideas.

Good luck and have fun!

Feel free to reach out to me on Twitter (@c_otto83), Telegram (@carsten_o), or via e-mail (bitcoin@c-otto.de).

What are the incentives around on-chain fees in the Lightning Network?

The lightning network is a layer 2 scaling solution for Bitcoin. As such, the infrastructure of the network is grounded in layer 1 where fees are critical to assuring transaction settlement. In this article we will explore the incentives around on-chain fees in Bitcoin’s Lightning Network.

Fees Encourage Use and Growth

The lightning network was created to solve some of Bitcoin’s scaling issues. I’ve written before about how on-chain fees work and methods to increase transaction speed after it’s been broadcasted. If the mempool is quite crowded, transactions on layer 1 will only confirm if they have included a high fee. For those transactions which require fast settlement, Lightning becomes an attractive alternative in a high-fee environment.

When on-chain fees are low, participants are incentivized to exploit the cheap fees to improve the payment channel infrastructure on Lightning. They do this by closing and opening channels on their lightning network nodes. Each channel open/close is an on-chain transaction that links the layer 2 to layer 1 BTC.

When on-chain fees rise, infrastructure improvement slows and usage of the existing infrastructure rises as people seek to avoid on-chain fees.

The Funding Transaction

The funding transaction is the on-chain transaction that creates a new payment channel. As with any on-chain transaction, the fee applied determines how quickly the transaction confirms when the network is congested. (The minimum fee of 1sat/vbyte will also confirm quickly if the mempools are not full).

If the channel funder chooses a low fee, it may take days or weeks for the transaction to confirm and the channel to open. If the fee is too high, then the channel will confirm quickly and the funder just overpaid.

It doesn’t matter if the funding transaction takes days or even weeks to confirm. Funds are not at risk. However, the payment channel is only created and announced on the Lightning Network once the funding transaction is confirmed.

The Commitment Transactions (and HTLCs)

After the channel is established between two peers, they can continue to transact with each other by exchanging broadcast-able commitment transactions that spend from the original funding transaction and effectively close the channel.

Likewise, the HTLCs used for routing can be redeemed on-chain as a fallback mechanism to ensure routing nodes get paid in the event a peer is uncooperative.

The funder of the channel is the one who pays the fee to close the channel. Since the channel can be closed by either party at any time, the two parties need to agree on an acceptable fee rate used to broadcast the channel close transaction.

If the channel close has a low fee, then both parties’ funds will be locked up until the closing transaction is confirmed. If the fee is too high, then an HTLC may become unspendable if the amounts settled are lower than the fee paid.

Therefore, nodes send a FEE_UPDATE message to one another to negotiate a reasonable fee at all times.


What is the difference between MPP and AMP payment splitting?

Routing and pathfinding on the Lightning Network is a rapidly evolving area of research. The topology of the network allows for payments to be sent peer-to-peer over connected channels where liquidity can flow.

In this article, we’ll cover the differences between Multi-part Payments (MPP) and Atomic Multi-part Payments (AMP). To understand the differences, let’s first review Bolt 11 and Keysend payments.

BOLT 11 Invoice Payment

The receiver must generate an invoice which encodes the following:

  • receiver’s public key
  • payment hash
  • payment amount
  • timestamp
  • CLTV expiry
  • (optional) routing hints
In a BOLT 11 invoice, the payment sender must retrieve an invoice from the payment receiver.

With the invoice, the sender constructs a route to forward the payment along to the receiver using HTLCs that can be redeemed with a preimage that only the receiver knows. The sender can choose to use the routing hints provided in the invoice.

Once the receiver has been handed an HTLC that satisfies the invoice, he will reveal the preimage to the payment hash back along the route allowing each hop to redeem their HTLC as well.

BOLT 11 invoices are atomic, meaning the payment either succeeds or fails entirely, and they provide proof of payment because the only way the sender can know the preimage is if the payment worked.

Keysend

With keysend, the sender can make a spontaneous payment using the recipient’s public key. The sender generates a secret payment_key and inserts it into the onion such that only the receiver can read it.

As before, the payment is forwarded along to the destination using HTLCs.

Once the receiver has uncovered the payment_key, he can redeem the HTLC by revealing the key to every node along the path.

Keysend payments are atomic, but proof-of-payment is impossible since the sender knows the payment_key from the start.

Multipart Payments (MPP)

A multipart (or multi-path) payment is a concept for a lightning network payment where the required amount is sent over many smaller payments using multiple routes to get to the destination.

MPP is preferable for many reasons:

  • Privacy – the full payment amount is not revealed to any routing node
  • Larger payments – nodes can make full use of their wallet balance since they no longer limited by the size of their largest channel.

There are many proposed implementations of MPP. Each has various tradeoffs regarding proof-of-payment and atomicity.

We will review the following proposals of MPP:

  • Base AMP
  • Basic MPP
  • High AMP

Base AMP

In this proposal, the sender essentially makes multiple keysend payments to the receiver. However, the payments are constructed such that the receiver must have all the preimages from all the paths to claim the funds.

This approach gives strong cryptographic assurance of atomicity (hence why it is called Base AMP). However, as with keysend, the proof-of-payment is weak since the sender can also reconstruct the information needed to “prove” the payment was received. The sender knows all the preimages since he wrapped them in the onion to begin with.

Basic MPP

Basic MPPs use the same payment_hash for all paths through which the payment will be made. It also requires an invoice since the receiver is the one who will reveal the preimage providing the proof-of-payment.


The receiver however, does not release the payment pre-image until all successful payments have been received.

Basic MPP relies on an economic incentive for the receiver to claim ALL funds vs. just SOME of the funds. This is not atomic.

High AMP

High AMPs are a way to combine the above approaches and gain the benefits of both. i.e. atomicity and proof-of-payment.

This implementation requires PTLCs.

How to add Redundancy to your Lightning Node

In this guide you will learn how to add redundancy to your lightning network node. Since we’re just talking about hardware, many of these principals also apply to the fields of server administration and IT generally.

Redundancy is not the same as backups.

Backups, redundancy and watchtowers, as well as good security and privacy practice are all part of a holistic approach to effectively manage your node.

This guide is only about redundancy.

A Lightning node needs to be online as much as possible. Significant downtime can result in fewer earnings from routing payments, temporary inability to view balance or send funds, and even loss of funds.

Here are the redundancy techniques covered:

  1. Uninterruptible Power Supply (UPS)
  2. Dual Uplink
  3. RAID 1 Redundancy
  4. ECC Memory
  5. Bonus: a note on virtualization and clusters

You don’t have to do all these at once. Start with #1 and work your way down over time as you deem necessary.

A good rule of thumb: the capacity of your channels should never be more valuable than 100x the cost of your node’s hardware.

For example, a plain Raspberry Pi kit costs $300 USD. It should be upgraded when the capacity of all its channels reaches $30,000 USD. Assuming you have generally reliable internet and power already.

Uninterruptible Power Supply (UPS)

Power outages will cause downtime and, in rare cases, file-system corruption – causing you to lose data. This can result in loss of funds if your node attempts to broadcast an old state to a channel peer.

A UPS is essentially a surge protector with a girthy backup battery built in. If the main power goes out, the UPS will switch to battery power and keep devices running for a bit longer.

Even if the power outage lasts longer than the battery can supply, at least you have a chance to gracefully shut down your node to avoid file corruption.

Here’s Amazon’s Choice for a UPS

Remember to also connect your router to the UPS so you don’t lose network connection when the power goes out!

Speaking of networks…

Dual Uplink

We’ve all experienced internet outages. If your node goes offline for too long, it will be unable to respond to malicious channel peers that may try to cheat you. A better solution to this problem is offered as a service by lightning network watchtowers. However, watchtowers are not a form of redundancy.

Many people pay for multiple internet connections from different ISPs because they make use of them to add redundancy and increased bandwidth to their home internet connection.

Even if you only have one option for an ISP, you can probably use a 4G cellular connection or satellite-based uplink like Starlink.

A dual uplink network switch can add redundancy to your network using two internet connections

Using a dual-uplink network switch, you can feed ethernet cables from two internet sources and load balance between them for your node.

RAID 1 Redundancy

Whether you’re using an old mechanical HDD or an SSD, the disk that stores your node’s data, as well as the entire blockchain will stop working eventually. Most disks are designed to fail in a read-only state. This means you can still recover data but can’t write new data. However, there’s always a risk of data loss, especially if you were cheap and bought a low quality SSD without a DRAM cache.

RAID stands for “Redundant Array of Independent Disks”. So actually this section’s title: “RAID 1 Redundancy” is itself redundant. There are many kinds of RAID that specify how the data is split across disks. RAID 1 is simply a standard duplication.


When using RAID 1, you have two storage disks of equal capacity plugged in and powered by your node. Using linux software called mdadm, you can create a virtual RAID disk using the two drives.

Use this guide from Digital Ocean to configure your software RAID: How to Create RAID Arrays with mdadm Afterwards, linux will recognize your disks as a single device, and you can mount it and read/write like normal. Now when one disk fails, your node will keep running as normal as long as the other disk is working properly.

Please note that the Raspberry Pi 4 is not powerful enough to power two drives at the same time. If you wish to add RAID to a Raspberry Pi node, you can try using Externally Powered USB 3.0 to SATA adapters.

An example of an externally powered USB to SATA adapter. You will need two of these to run RAID 1 on a Raspberry Pi

Perhaps at this stage, you should consider upgrading from a Raspberry Pi to a RockPi 4 or even a spare desktop PC or full blown server.

ECC Memory

The universe is a hostile place. While you’ve been reading, thousands of particles from deep space have been blasting straight through your body and your computer. Sometimes cosmic rays are the only valid explanation for why a computer system crashes.

If you’ve ever had an unexpected computer crash that never happened again, the odds are surprisingly high that it was a memory error caused by a cosmic particle. While regular computers use error correcting bits in software to catch most of these kinds of errors, ECC RAM has an extra layer of protection baked in at the hardware level.

ECC RAM is used in servers and systems where high availability is a must. ECC RAM only works on certain motherboards that support it. It’s also slower than non-ECC memory and it cost significantly more.

Bonus: A note on Virtualization and Clusters

A very popular way to add redundancy in the enterprise world is through distributed servers running a virtual application. This approach relies on advanced networking and software configuration to essentially run a single software program across many computers connected over the internet.

Amazon Web Services offers tools and services that make this easier.

If you’re interested, look into learning Kubernetes and Docker. You should also have advanced knowledge of the Lightning Network penalty mechanism. Many people have lost funds because they didn’t understand how LN punishes people who cannot keep an up to date state. This is something that can be especially tricky when using a distributed cluster.

What’s the difference between a MAC and an HMAC?

message authentication code (MAC) is produced from a message and a secret key by a MAC algorithm.

The MAC of the message and an “orange” secret produces a “blue” MAC

The MAC algorithm is a one-way function. This means it’s impossible to decode the secret from the MAC. This also means that a MAC using the same message and a different secret will look completely different.

See how changing the secret to “green” produces a “yellow” MAC.

Why are MACs useful?

MACs are used to verify the integrity and authenticity of data. If you receive a message with a MAC and you have the secret used to create the MAC, and you know the MAC algorithm, you can recreate the MAC and compare it to the MAC that was sent to you. If the two MACs are identical, then you have verified that the message you received is the message that was sent; assuming only you and the sender know the secret.

While cryptographic signatures serve the same purpose, MACs are useful because they don’t rely on public key infrastructure and asymmetric key pairs. MACs only rely on symmetric keys that can be securely distributed using Diffie-Hellman key exchange.

What are HMACs?

MACs are similar to hash functions because they are both one-way operations and changing the inputs slightly produces very different outputs.

A hash produced from a message is a one-way function.

However, nothing about the definition of a MAC ensures that the message itself is not fully or partially recoverable from the MAC. Only the secret must be hidden. Hash functions ensure that all the inputs are unrecoverable from the hash.

Because of this, hash functions are often used in the process of constructing a MAC. When a MAC uses a hash function, it is called an HMAC.

An HMAC algorithm is a subset of possible MAC algorithms that uses a hash function.

Hash functions ensure that the message cannot be recovered using the hash. This adds additional security to regular MACs which can leak information about the original message. Since HMACs have all the properties of MACs and are more secure, they are the preferred kind of MAC.

Special care is required when applying the hash function to the message and secret to avoid length extension attacks. Hash functions are computationally intense so HMACs may not be suitable for all applications.

HMACs in the Lightning Network

On this blog, we write about Bitcoin 🙂

In the lightning network, payments are executed over many “hops” as each node constructs an HTLC with its channel peer to forward sats from the sender to the destination.

These nodes must communicate in order for the sender to construct an onion that will be sent along the route and decrypted by each node. In this process of communication, messages are authenticated with HMACs.

This communication needs to happen very fast and messages need to be verified. Even though lightning network nodes already have private/public key pairs, compared to HMACs, digital signatures are more computationally intense. So lightning uses HMACs to authenticate instead.

Why is it difficult to cancel a Bitcoin transaction?

Bitcoin offers the highest assurance of transaction finality of any asset known today. It is impossible to undo a transaction with multiple confirmations. However, it can take weeks or even months for a broadcast transaction to confirm if it is not sent with a competitive fee.

A signed and broadcast transaction quickly replicates in the mempools of most nodes in the network. Some of these nodes are miners and every transaction in their mempool represents a transaction fee that they could potentially claim. Therefore, miners have no incentive to remove a valid transaction from their mempool. Each node can determine the size of their mempool. If a mempool fills up, the node will begin to purge low fee transactions. However, some nodes elect to have large mempools and may rebroadcast low-fee transactions at times when the mempools are empty.

This game theory ensures that broadcast transactions will eventually be confirmed. But it can be inconvenient, especially if you didn’t plan on waiting weeks or even months for a transaction to confirm.

Nodes will generally ignore transactions that are attempting to spend the same UTXOs as another transaction already in its mempool. This is seen as a double-spend attempt and is purged to prevent mempool congestion.

Replace-by-Fee

With the release of Bitcoin Core 0.14.0 in 2017 bitcoin transactions could be sent using opt-in replace by fee (RBF). This allowed the transaction data propagated in mempools to indicate that a future version of this transaction could replace it if it includes a higher fee. Nearly one year after its introduction, RBF was enabled by default in Bitcoin 0.16.0.

Child-Pays-for-Parent

If the stuck transaction was not broadcast with Opt-In RBF, things get a bit more complex.

Child Pays for Parent (CPFP) may do the trick. Applying CPFP, miners don’t necessarily pick the transactions that include the most fees, but instead pick a set of transactions that include most combined fees.

Most transactions do not only send bitcoins to the receiver, but they also send “change” back to you. You can spend this change in a next transaction.

Some wallets let you spend this change even while it is still unconfirmed, so you can send this change to yourself in a new transaction. This time, make sure to include a high enough fee to compensate for the original low fee transaction. A miner should pick up the whole set of transactions and confirm them all at once.

If your wallet does not let you select which bitcoins to spend exactly — meaning you cannot specifically spend the unconfirmed change — you can try spending all funds in the wallet to yourself; this should include the change.

A Note on Lightning

A transaction on the lightning layer is also tricky to cancel. It achieves this in an interesting way involving agreed upon commitments and penalty transactions.

Each time a new payment is made in the channel, a new commitment transaction is created and shared with both parties to accurately reflect the agreed upon state of funds in the channel. Either participant may broadcast the commitment transaction at any time to close the channel and return funds to each party as laid out in the transaction.

We’ve just discussed how attempts to double spend or cancel on chain transactions are difficult. Therefore, there must be an extra layer of protection to prevent channel participants from publishing old commitments (i.e. undoing a transaction).

Lightning solves this by allowing the “cheated” channel peer to punish the cheater with a penalty transaction which sends the entire channel capacity to the “cheated” node.

However, the channel partner must be online to detect when it is being cheated. If the node is offline for the entire time that the cheater’s output is time-locked, then the cheater can successfully cheat; effectively undoing transactions within the channel.

Install charge-lnd and Put Routing Fees on Autopilot

In this article, you’ll learn how to automatically manage your channel fees with charge-lnd.

The Lightning Network is a free market for routing and liquidity. It’s up to each individual node to set the price of their node’s liquidity. Node operators do this by defining the base fee and the fee rate for each one of their lightning channels.

Base Fee

The base routing fee is a fixed amount of satoshis that will be collected every time you route a payment. It’s usually measured in millisats (mSats).
1,000 mSats = 1 sat

Fee Rate

The fee rate is a dynamic amount of satoshis based on the total amount routed. The fee rate is measured in milli mSats per sat.
10,000 milli mSats per sat = 1% fee rate

How to install charge-lnd

We’ll be using raspiblitz, but this should guide should work for any linux-based, LND lightning node.

Charge-lnd is a python-pip package. Pip is a package manager (like an app store) for Python.

Normally, you can install pip packages with a single command, but charge-lnd isn’t listed in the official pip repositories so you have to build it yourself.

Go ahead and ssh into your node to enter all these commands.

1. Switch to the bitcoin user on your node (its best to run charge-lnd as this user)

sudo su - bitcoin

2. Download the charge-lnd code to your node

git clone https://github.com/accumulator/charge-lnd.git

3. Create an application key authorizing charge-lnd to control your node

lncli bakemacaroon offchain:read offchain:write onchain:read info:read --save_to=~/.lnd/data/chain/bitcoin/mainnet/charge-lnd.macaroon

4. Change current working directory to the repository you just downloaded

cd charge-lnd

5. Install the setuptools package allowing you to build other packages

pip install -U setuptools

6. Build and install the charge-lnd on your node

pip install -r requirements.txt .

You might see a message like this:

The script charge-lnd is installed in '/home/bitcoin/.local/bin' which is not in PATH. Consider adding this directory to PATH or to suppress this warning use --no-warn-script-location

Linux keeps a global environment variable called $PATH which is just a list of directories where system tools are installed. This message is letting you know that charge-lnd was just installed in a directory that isn’t in PATH so you won’t be able to run it with just the name “charge-lnd”. You’ll have to run it by passing the full path to the program each time.

For this guide, we will not be modifying our PATH. If you’d like to check out this guide on How to Add a directory to PATH in Linux.

7. Check that it installed correctly

/home/bitcoin/.local/bin/charge-lnd -h

This should show the help menu for charge-lnd. Remember, this is only installed for the bitcoin user.

8. (Optional) logout of the bitcoin user

exit

Create a default policy config

Charge-lnd keeps a config file where you can define policy rules for setting fees. Read the charge-lnd docs to see all the properties you can set.

1. Open the charge-lnd config in a text editor

sudo nano /home/bitcoin/charge-lnd/charge.config

2. Use the interactive editor to add some config. For example:

[default]
chan.min_capacity = 500000
strategy = static
base_fee_msat = 1000
fee_ppm = 10

Save and quit the editor.

3. Apply the configuration to your channel fees

sudo -u bitcoin /home/bitcoin/.local/bin/charge-lnd -c /home/bitcoin/charge-lnd/charge.config

Automatically Apply the Policy at Scheduled Intervals

We’ll use the cron task scheduler to run charge-lnd at whatever interval you want!

WARNING: every time you change fees, your channel will be unusable for 10-60 minutes while the new channel policy update is flooded to the entire lightning network! It’s also considered rude to spam the network with frequent updates.

1. Switch to the bitcoin user

sudo su - bitcoin

2. Open up the cron task list

crontab -e

You might be asked to choose an editor. Choose nano if you’re unsure.

3. Add the cron task to the end of the file to run every night at midnight

0 0 * * * /home/bitcoin/.local/bin/charge-lnd -c /home/bitcoin/charge-lnd/charge.config

Those 5 characters at the beginning are called a cron expression. You can generate your own cron expression for any time interval.

Save and exit the editor.

Final Thoughts

Charge-lnd will only apply changes if it detects that a channel’s fee policy should be changed. These edits will likely be removed if you update your node manager software (i.e. raspiblitz, umbrel, etc.)

I hope this guide helped you step up your routing node game and maybe learn a little bit about linux and command line.

The Bitcoin Network Security Optimization Problem

Bitcoin will be successfully attacked because its network security is trending down despite rising hash rate. It must suffer an assault (perhaps multiple blows) in order to correctly price the minimum cost of security. Proof-of-work systems with a decreasing issuance schedule are performing a security budget optimization in real-time.

Let me explain…

Proof-of-Work Incentive Structure

Proof-of-work blockchains are secured by a global network of computers that perform energy-intense calculations. These miners are rewarded proportional to the amount of work (hashes) they produce to secure the asset they are mining.

Bitcoin miners recieve payment from two sources.

  1. The block reward – represents newly created bitcoin rewarded to miners as part of bitcoin’s predictable supply schedule.
  2. Transaction fees – the fees collected from all transactions that the miner includes in a block

An attacker with substantial hashrate could choose to hijack the network. They could delay payments by mining empty blocks (choosing not to collect transaction fees) or they could double-spend transactions made during their attack.

The attack would need to be sustained to be effective, however, it’s important to note that the adversary would not be able to alter old transactions or create new coins.

Proof-of-work is designed to make attacks costly, and cooperation rewarding.

An Alternative Measure for Proof-of-Work Security

Independent analyst, energy FUDster, and shitcoiner Morgan Bennett shared this chart which models the security of proof-of-work blockchains.

Proof of Work Network Security

Chart source: Tweet from Bennett

At first glance, this chart seems counterintuitive to anyone who follows bitcoin network statistics. It clearly shows a downward trend in security for all proof-of-work chains even though hashrate (for most networks) has been on the rise.

Perhaps this chart was intended to spread FUD about proof-of-work chains by intentionally framing them as doomed to fail. However, I think this data reveals something interesting about Bitcoin’s design that could become relevant once it faces a worthy adversary.

Hash Rate Alone is not Network Security

Here’s a chart showing the clear and steady increase in Bitcoin’s hashrate, for example:

Bitcoin Hashrate from 2010 to April 2021

Chart source: CoinWars

If an attacker needs “substantial hashrate”, doesn’t an increase in hashrate make the network more secure?

Not necessarily.

If all miners controlling hashrate are assumed to always act in good faith, then an attacker would need to bring on additional hashrate to outcompete the good faith miners.

However, this assumption is unrealistic. It is more likely that an attacker would bring hash online and cooperatively mine until the opportunity to attack becomes feasible.

This is why Bennett defines network security as the security budget divided by the network’s market cap.

Let’s break down what that means and why it’s a better measure for bitcoin network security than hash rate.

A Definition of Bitcoin Network Security

Bitcoin’s network security budget is what is paid to miners who act in good faith. Namely, the block reward plus transaction fees.

In theory, it is more appealing to attack coins with higher market caps per unit of cost that an attacker might spend. By dividing the reward paid to good faith miners by the market cap, we capture this relationship and arrive at a figure which represents the ongoing cost to attack the network.

This security calculation could explain why shitcoins don’t get 51% attacked very often despite their meager hashrates.

It also introduces another sly roundabout way that bitcoin protects itself from existential threats. Bitcoin’s valuation serves as a deterrent to attack, only increasing to levels it can sustain with the current levels of security.

This cost trends down for two reasons.

  1. Market cap rises – due to number go up technology
  2. The block reward decreases – predictably with the halvings baked in to Bitcoin’s supply schedule.
Bitcoin's Predictable Supply Schedule

Chart source: bitcoinblockhalf.com

If we expect bitcoin to pump forever and halvings to continue until all 21 million coins are mined, then for security to rise, transaction fees must also rise.

Will Fees Rise?

This is the 100 million satoshi question. We’ve seen fees rise significantly during bull markets as block space becomes a hot commodity. Interestingly, the fee spike helps maintain security in the face of an increasing market cap.

Read our piece on Why your Bitcoin Transaction is Unconfirmed and How to Fix it to learn more about fees.

The chain must be reserved for high-value settlement if fees are to rise. Additionally, adoption must grow so that more high-value settlements are demanded. Second layer scaling solutions like the Lightning Network are promising instant settlement of low-value transactions by “batching” them in high-value onchain transactions.

The Cost to Secure the Price

However, bitcoin network security doesn’t necessarily need to rise indefinitely. It only needs to stay above the minimum level required to prevent successful attacks. If the network were over secured, this would correspond to an undervaluation of the asset (low prices) or unnecessarily high fees.

If we view Bitcoin as an efficient system built on true price discovery of free markets, then this theoretical level of minimum security is unknowable until Bitcoin is successfully attacked.

Therefore the downward trend in proof-of-work network security is not a path to utter devastation, but rather an optimization of resources seeking to naturally discover the true cost to sufficiently secure the network.

A successful attack will likely crash the price, causing the security to rise dramatically, preventing the attacker from sustaining the assault. After which point, any price increase must correspond to an increase in fees to maintain a minimum security level.