morata_voltz

bitcoin

Stay away from Voltz

Haiku7336

Hello buddy, i think you may see your email

Why could the quantum era be Bitcoin's greatest challenge? | Block Height: 874,398

![](https://m.stacker.news/67465)

>*[Narcelio](https://x.com/narcelio/status/1866262350480998453). (2024, December 10)*. **"Everyone needs to understand that the cliché 'Bitcoin will be the least of our problems' is completely wrong. At least for Bitcoiners, Bitcoin should be our greatest problem, our biggest concern."** [Post on X].
>*Retrieved from https://x.com/narcelio/status/1866262350480998453.*

# Introduction

Bitcoin is often regarded as one of the most secure and resilient technologies today due to its use of elliptic curve cryptography (ECDSA) and cryptographic hashing. However, a potential threat looms: quantum computing.

As quantum computing research rapidly progresses, a concern arises: What if the ability to break current cryptography is achieved before Bitcoin evolves to “Quantum Resistant” solutions?

In this article, I do not want to fuel FUD (Fear, Uncertainty, and Doubt), but rather educate on where the risks lie. I will explain:

* How quantum computing could compromise Bitcoin.
* Vulnerable cases (P2PK, P2PKH, SegWit, Taproot).
* Why public key exposure during spending is critical.
* How to prevent or mitigate the risk.

The goal here is clear: to understand the problem before it becomes a reality and, with that, prepare you and minimally introduce you to the post-quantum debate surrounding Bitcoin before it’s too late.

# Current Cryptography in Bitcoin

Bitcoin relies on cryptographic algorithms for its security, primarily two pillars:

* Elliptic Curve Cryptography (ECDSA): Derives public keys from private keys.
* Cryptographic Hashing (SHA-256 and RIPEMD-160): Ensures transaction and block integrity and immutability.

However, with advancements in quantum computing, these systems, considered secure with classical technology, may become compromised.

# Elliptic Curve Cryptography (ECDSA) and the Quantum Problem

ECDSA is the algorithm used in Bitcoin to derive public keys from a private key. Specifically, Bitcoin utilizes the secp256k1 elliptic curve.

Breaking it down:

* *SEC*: Standards for Efficient Cryptography Group (SECG).
* *P*: Indicates an elliptic curve over a prime finite field, where points operate within a prime number-defined field.
* *256*: Refers to the key size (256 bits). The finite field restricts valid derivations to values below this prime limit.
* *k1*: Refers to the Koblitz curve type, known for its efficiency.

![](https://m.stacker.news/67466)

# How is secp256k1 used in Bitcoin?

The security of ECDSA is based on a problem called the discrete logarithm problem. The public key 
𝑃 is generated by multiplying the generator point G by the private key 𝑘:

*P = g * K*

* G is the generator point on the elliptic curve;

* k is the private key;

* P is the public key.

This operation is unidirectional; it is easy to calculate P from k, but infeasible to calculate 𝑘 from 
𝑃. The public key generated is compressed and later hashed (HASH160) to create a Bitcoin address.

There is no efficient algorithm on classical computers to calculate 𝑘 from 𝑃. However, with quantum computing, Shor's Algorithm solves the discrete logarithm problem in polynomial time instead of exponential time, as it happens with classical computing.

When we say that Shor's Algorithm solves the discrete logarithm problem in polynomial time, it means that the time required to break the private key grows polynomially with the size of the problem: the key size.

In other words, if the key size increases, the resolution time grows in a controlled manner and not exponentially, as happens with classical computers.

With Shor's Algorithm on a sufficiently powerful quantum computer, the time required would be reduced. This does not mean it would be instantaneous, but it would be orders of magnitude faster.

This means that a sufficiently powerful quantum computer could:

1. Capture the public key (exposed in transactions);
2. Calculate the corresponding private key;
3. Spend the funds linked to that key.

# SHA-256 and RIPEMD-160: Is Hashing Still Secure?

In addition to ECDSA, Bitcoin uses cryptographic hashing—SHA-256 and RIPEMD-160—to secure data like block chaining and public addresses (derived as HASH160 of the public key).

Unlike ECDSA, hash algorithms are not directly vulnerable to Shor’s Algorithm. Instead, they are susceptible to Grover’s Algorithm, which reduces the time needed to find a preimage (hash collision) from 2^𝑛 to 
2𝑛/2². For a 256-bit hash (SHA-256), this would require 2^128 operations, which remains extremely difficult even with quantum computing.

Thus, cryptographic hashing remains partially secure but will eventually need to evolve to be fully quantum-resistant.

# Bitcoin Address Types: An Overview

Now that we understand the cryptography currently used in Bitcoin, we can move on to understanding public addresses and where they are vulnerable to quantum computing.

Bitcoin addresses represent payment destinations on the network, derived from public keys through cryptographic operations. Over time, different address types have emerged, bringing improvements in security, efficiency, and privacy.

Here is a list of them:

## 1. P2PK - Pay-to-Public-Key
* Format: The full public key is stored directly in the ScriptPubKey.

![](https://m.stacker.news/67469)

* Usage: One of the first formats used in Bitcoin.

* Security: Lower, as the public key is visible at the time of transaction creation (not just when spent).

* Problem: The public key is immediately exposed upon receipt, making these addresses vulnerable to quantum attacks.


## 2. P2PKH - Pay-to-Public-Key-Hash (Legacy)
* Format: Uses the HASH160 (RIPEMD-160 + SHA-256) of the public key.

* Usage: It is the most widely used legacy address format. Addresses begin with the prefix "1".

* Security: While the funds remain unspent, only the hash of the public key is visible. The full public key is protected and only revealed at the time of spending.

![](https://m.stacker.news/67470)


## 3. P2SH - Pay-to-Script-Hash (SegWit)

* Format: Stores the hash of a script (redeem script) instead of the public key.

* Usage: Allows for more complex scripts, like MultiSig. Addresses begin with the prefix "3".

* Security: The redeem script is revealed only at the time of spending, as part of the ScriptSig. While funds remain unspent, only the hash of the redeem script (HASH160) is visible on the blockchain. The public key is revealed only if the redeem script directly contains it, such as in P2PK or MultiSig scripts.


## 4. P2WPKH - Pay-to-Witness-Public-Key-Hash (Native SegWit)
* Format: Introduced by SegWit, it uses the public key hash in the ScriptPubKey.

* Usage: Reduces transaction costs and prevents malleability. Addresses start with "bc1".

* Security: Similar to P2PKH, the hash of the public key is stored in the ScriptPubKey. The full public key is revealed in the witness when the funds are spent.

![](https://m.stacker.news/67471)

## 5. P2WSH - Pay-to-Witness-Script-Hash (Native SegWit)
* Format: Stores the script hash in the ScriptPubKey, the SegWit version of P2SH.

* Usage: Ideal for complex scripts using SegWit.

* Security: The script and the public keys involved are revealed only at the time of spending, within the witness script inside the witness.

![](https://m.stacker.news/67472)


## 6. P2TR - Pay-to-Taproot (SegWit v1)
* Format: Introduced in Taproot, it uses the X-only public key directly in the ScriptPubKey.

* Usage: More efficient and private, with support for complex spending conditions.

* Security: The X-only public key is visible in the ScriptPubKey but hides the use of internal scripts. The Schnorr signature is revealed in the witness at the time of spending. The X-only public key is directly exposed, but internal scripts appear only if used.

![](https://m.stacker.news/67473)


## The Role of Exposed Public Keys

Problem: Once the public key is exposed, it can be captured and processed by a quantum computer in a timely manner.

## SegWit and the Post-Quantum Problem: Partial Protection, but Not a Complete Solution

Before SegWit, the public key was exposed at **transaction creation** (in the output). This meant that an attacker with a quantum computer could attempt to break the public key **before it was spent**.  

With **SegWit (P2WPKH)**, the ScriptPubKey (output) contains only the **public key hash (HASH160)**. The full public key is revealed only in the **witness** when the transaction is spent.  

**Why is this important?** While the public key remains unexposed, it is protected by a hash, theoretically resistant to quantum attacks under the current model.  

## The Moment of Vulnerability: The Mempool

Despite partial protection, the problem persists during **transaction spending**:  

- When sending a SegWit transaction:  
   - The **public key** appears in the witness and becomes visible.  
   - The transaction enters the **mempool** as unconfirmed.  

- In the mempool, the public key is exposed:  
  - An attacker with a **quantum computer** could capture the public key and derive the private key.  
  - This could allow the attacker to **steal funds** before the transaction is confirmed in a block.  

## Future Possible Solutions

To fully address the post-quantum problem, Bitcoin would need to adopt quantum-resistant cryptography, such as lattice-based cryptography or hash-based signatures, which could potentially replace ECDSA.

*Note:* I don’t fully understand classical computing, let alone quantum.

# Conclusion

SegWit marked significant progress by delaying the exposure of public keys until spending, complicating quantum-based attacks. However, it doesn’t fully solve the problem since the public key is exposed in the **witness** once the transaction is broadcast and becomes visible in the **mempool**.  

In a scenario where a sufficiently powerful quantum computer is operational, the risks are clear:  

1. **Targeted attacks**: Public keys exposed in the witness could be broken before transaction confirmation.  
2. **Legacy addresses**: Funds in P2PK addresses remain highly vulnerable.  

The complete solution involves implementing **quantum-resistant algorithms**, like lattice-based or hash-based cryptography. Although these technologies are still under study, the **post-quantum Bitcoin debate** must be prioritized to prepare the network before the threat becomes a reality.  

In addition to Bitcoin, various systems that rely on cryptography—such as traditional banks, messaging apps, and online services—would also be affected by quantum computing.

However, most of these systems can adopt quantum-resistant algorithms more quickly and centrally, as they do not rely on majority consensus.

Updates in these systems can be implemented via security patches or software updates. In contrast, Bitcoin, due to its decentralized nature and the need for network-wide consensus, requires a much longer and more careful process of development, testing, and implementation.

In addition to traditional systems, many machine-to-machine communication protocols also rely heavily on cryptography to ensure security and privacy. Examples include TLS/SSL (used in HTTPS), IPsec for VPNs, and SSH for secure remote access.

These protocols use public key algorithms such as RSA, ECDSA, and Diffie-Hellman for encryption and secure key exchange. While fundamental to the security of the internet and private networks, transitioning to quantum-resistant algorithms in these protocols would be faster compared to Bitcoin.

This is because these systems are updated centrally or through standardization bodies like the IETF, enabling a more agile migration to new cryptographic versions.

# Developments: What Would Happen to Mining?

## What if a Quantum Computer Mined Blocks Too Quickly?

A recurring concern is the idea that a quantum computer could dominate the mining process, breaking the SHA-256 used in Proof-of-Work and validating blocks much faster than traditional miners.

Let’s clarify:

1. **Difficulty Adjustment**  
Bitcoin has a **difficulty adjustment mechanism** that recalibrates mining difficulty every **2016 blocks** (~2 weeks). If blocks are mined too quickly due to a quantum computer's power, the difficulty would increase exponentially, restoring normality.  

2. **Computational Scalability Problem**  
Even if a quantum computer mines faster initially, nodes still validate blocks under consensus rules. Increased difficulty would exponentially raise **energy costs**, limiting the quantum computer’s capabilities.  

3. **Hashrate and Quantum Power**  
A quantum computer with superior hashrate could theoretically launch a **51% attack**. However, hashrate alone isn’t sufficient; the network must still accept blocks, with difficulty adjustments acting as a limiting factor.


## The Real Risk of Quantum Hashrate
If quantum computing achieves extreme capacity and surpasses the combined hashrate of traditional miners, there could be a temporary risk of mining dominance.  

However, as Bitcoin consensus is governed by **majority rule** and validation by full nodes, the network could adapt preemptively by implementing **post-quantum hashes** and alternative algorithms.


**Translated from:** https://morata.substack.com/p/bitcointico-como-o-mundo-pos-quantico

How the Post-Quantum World Critically Threatens Bitcoin

![](https://m.stacker.news/66766)

###  We are thrilled to announce the launch of Voltz Tip Bot – a easy-to-use Lightning Network Telegram Bot designed to facilitate tipping sats right within your Telegram groups

- **🔗Bot Link: https://t.me/voltztip_bot**

# What is the Voltz Tip Bot?

The Voltz Tip Bot allows Telegram users to send and receive satoshis via the Lightning Network. It's a community-driven, custodial wallet, leveraging the LNbits infrastructure of Voltz Wallet to send tips between Telegram users.

## Key Features:

### 1. Create Lightning Wallets Instantly 🪙

- Use /start to generate a Lightning wallet and check your balance. No KYC, no friction.

### 2. Send Tips in Groups 💸

- Tip anyone in your group by replying with /tip <amount>. Want to reward great contributions? It's just a command away.

![](https://m.stacker.news/66767)

### 3. Receive Payments ⚡

- Generate invoices with /receive <amount> and share the QR code or invoice to receive sats instantly.

![](https://m.stacker.news/66769)

### 4. Pay Lightning Invoices 🔗

- Settle invoices or pay Lightning Addresses with /pay <invoice> or /pay <lnaddress> <amount>.

![](https://m.stacker.news/66770)

### 5. LN Address Creation 📫

- Create your very own Lightning Address (username@lnvoltz.com) using /lnaddress to receive payments easily.

![](https://m.stacker.news/66771)

### 6. Rankings and Engagement 🏆

- Use /ranking_tip to view the top tippers and receivers in your Telegram group. Who contributes the most sats? Let’s find out!

![](https://m.stacker.news/66772)



# Get Started Now 🚀

#### 1. Add the bot to your group or chat;
#### 2. Type /start in private to generate your wallet;
#### 3. Fund your wallet with /receive command;
#### 4. Start tipping, receiving payments, and boosting your community engagement with Bitcoin.



- **🔗Bot Link: https://t.me/voltztip_bot**

⚡ **Voltz Tip Bot: Making the Lightning Network accessible, interactive, and fun!**

**Got questions or feedback?** *Join us at **[Voltz Wallet Channel](https://t.me/voltz_wallet)**.*


⚡ Introducing the Voltz Tip Bot – A Seamless Way to Share Sats on Telegram! ⚡

Stacker Saloon

saloon

Sorry guys, i was very busy, but it was resolved

bitcoin_beginners

The Taproot soft fork was one of the most significant updates to the Bitcoin protocol since SegWit (Segregated Witness) in 2017.

Activated on November 14, 2021, the Taproot update brought important improvements to the privacy of certain Bitcoin transaction models.

Before Taproot, complex transactions with multiple conditions, such as smart contracts (e.g., Lightning channels) or multisig wallets, were visible on the blockchain, allowing anyone to identify that a transaction followed a specific pattern.

Taproot introduced a new type of transaction signature called Schnorr Signatures, which offers advantages in signature aggregation over the ECDSA (Elliptic Curve Digital Signature Algorithm) scheme.

With ECDSA, each signature needs to be recorded individually on the blockchain, increasing the size and cost of the transaction.

With Schnorr Signatures, these multiple signatures can be combined into a single compact signature, reducing the transaction size.

This also makes multi-party transactions, known as multi-signature transactions, indistinguishable from simple transactions.

With Taproot, these transactions are grouped, and unless a secondary condition of the contract is used, the result looks almost identical to a simple transaction, significantly improving privacy.

The Schnorr signature aggregation also contributes to network efficiency, as the smaller transaction sizes take up less space in blocks, reducing costs for users.

Moreover, the way scripts are processed on the network has become more efficient, making smart contracts and complex transactions more feasible on Bitcoin.

Taproot also introduced the concept of MAST (Merkelized Abstract Syntax Tree), which allows only a specific part of a contract to be revealed when necessary.

Instead of disclosing all the details of a smart contract on the blockchain, only what is essential for the execution of a specific contract condition is exposed.

**Did you know that three BIPs were activated in the Taproot soft fork?**
* BIP 340: Introduced Schnorr signatures;

* BIP 341: Taproot, a new P2TR (Pay-to-Taproot) output. It’s a combination of P2PK (Pay-to-Public-Key) and P2SH (Pay-to-Script-Hash) functionalities;

* BIP 342: Tapscript, an enhancement to Bitcoin’s scripting language that allows integration of the new P2TR outputs.

For Noderunners like myself, I strongly recommend using P2TR addresses to open Lightning channels.

For routers, this means saving on on-chain fees, and for those seeking more privacy, using P2TR addresses for channels means not announcing the channel opening on the blockchain.

Understand that to achieve better privacy, you shouldn’t open a public channel, as the opening transaction can be seen through explorers like Mempool, Amboss, 1ML, etc.

If you want privacy, open private channels, so the transaction doesn’t appear in explorers. An example of this can be seen here:

![](https://m.stacker.news/59407)
![](https://m.stacker.news/59406)

**But not everything is perfect, and everything has its trade-offs:**

P2TR addresses expose the public key directly on the blockchain, which could be considered a slight reduction in security compared to P2WPKH (Pay-to-Witness-Public-Key-Hash) addresses used in SegWit.

* **SegWit (P2WPKH):** Only the public key hash is revealed until the transaction is spent. This means the public key itself remains hidden until the time of spending, which provides an extra layer of protection against potential reverse cryptography attacks that may emerge in the future.

* **Taproot (P2TR):** The full public key is revealed as soon as the transaction is made. While Schnorr signatures used in Taproot are secure and efficient, exposing the public key from the start could be considered a theoretical risk in the long term, should new vulnerabilities in cryptography be discovered.

However, it’s worth noting that:

* The current security of P2TR addresses is still considered excellent, and the risk of public key exposure is more theoretical than practical at this time.

* The efficiency and privacy offered by Taproot, especially in complex transactions and Lightning channels, outweigh this slight disadvantage for most cases.

Bitcoin Soft Fork: TAPROOT🍠

Did you know that on February 7, 2106, Bitcoin will face one of the greatest challenges in its history if no changes are made? We're talking about the Year 2106 Problem, a bug that could halt the network if not addressed!

## What is this bug?

It's not just Bitcoin that's counting down to one of the biggest bugs in history. The Year 2106 Problem affects many systems, all of which rely on how they store time.

Many Unix/Linux-based systems, such as servers, internet equipment, telecommunications, and smartphones, use a 32-bit counter to track time, and these systems may fail or produce corrupted data after 2106.

## How does this affect Bitcoin?

The problem is related to the timestamp used in Bitcoin's blockchain blocks. This field in the header of each block stores time as a 32-bit number in seconds since January 1, 1970.

This value will hit its maximum possible limit in 2106. After that, the system will no longer be able to correctly record new blocks because the counter will "overflow."

The Bitcoin block headers contain critical information such as the block version, the hash of the previous block, the Merkle Root, and the time. If the time field stops working, miners will no longer be able to find valid blocks, and the blockchain will freeze.

## Why does this happen?

The timestamp uses an unsigned 32-bit counter to record the seconds, and in February 2106, this counter will hit its maximum value of FFFF FFFF (4,294,967,295 seconds). After that, it will attempt to "reset to zero," which is not allowed by the consensus rules.

## How can this be fixed?

A hard fork will likely be needed to increase the size of the time field. The most accepted theoretical proposal would be to modify the timestamp size in Bitcoin blocks, changing it from uint32_t to int64_t (64 bits).

This would give the system much more time before facing any second-counting problems—approximately 292 billion years using a 64-bit format.

This change would require a modification to Bitcoin's consensus rules. The current protocol would need to be updated to recognize and validate blocks with 64-bit timestamps.

The main reason this would require a hard fork is that old nodes would not be compatible with this new block structure. They would reject blocks with 64-bit timestamps, leading to a network split if those nodes aren't updated.

But don't worry, we have over 80 years to debate and find the most appropriate solution, and the community is already aware of the issue. As we've proven so far, Bitcoin is resilient!

🚨 The "End of Blockchain Bug" That Will Stop Bitcoin! ☠️😱 🚨

lightning

Autofee for Inbound Fees - LND

> Yes, I'm doing a general automation in my node so that I don't have to do literally anything else. I'll soon release it on github when it's in a more stable version.

I implemented the inbound fee adjustment in my autofee yesterday, we'll see what impact it had on the node in a while.

The logic consists of taking the **total outbound cost** of the channel, whether it's a **sink** or **router**, and this cost is obtained by the amount I **paid to fill** with rebalances, added to the amount of **routed in** of this channel and taking the **weighted average**.

Once this calculation is done, I subtract this cost value from the **new outbound fee rate** that the automation will make and thus obtain my **projected profit margin**.

So the next step is to apply a **negative inbound fee** (discount) following the channel's behavior:

- **For Sinks:** Apply a 25% discount on my projected margin

- **For Routers:** Apply a 50% discount on my projected margin

What do you think?

![](https://m.stacker.news/58938)

LND version 0.18.3 Introduces the lncli command for Blinded Paths

I will try it with my environment and soon I will tell you how my experience was

tutorials

BR⚡LN BOLT | Portuguese Tutorial for New Noderunners

We love it but we decided to modify for brazilian community 

And we also provide support in the BRLN community: https://br-ln.com/

LINK: https://brln.gitbook.io/brln-bolt

This tutorial aims to assist the beginner Node Runner in an independent installation of Bitcoin Core (bitcoind) and Lightning Network Daemon (LND).

It was developed by applying the practical experiences of BR⚡LN members based on the English version of Minibolt: https://v2.minibolt.info/lightning/lightning/lightning-client

The New Nobility Will Run Their Own Nodes

Decentralization is the essence of Bitcoin and the Lightning Network. While Bitcoin offers a censorship-resistant, peer-to-peer form of money, its true potential is unlocked when users take control of their own infrastructure. However, even with user-friendly tools like Umbrel and similar node software, many ordinary people still find it challenging to install and configure their own Bitcoin or Lightning nodes. The process often involves navigating technical barriers that can feel overwhelming, especially for those unfamiliar with the nuances of managing a decentralized financial system.

#### Why running your own node matters

Running a Bitcoin or Lightning node is a critical step for anyone who values sovereignty, privacy, and security in their financial transactions. It removes the need to rely on third parties, giving users complete control over their funds and how they interact with the Bitcoin network. But while the idea of running your own node sounds empowering, the reality is that most solutions, despite marketing themselves as user-friendly, still require a level of technical knowledge that can be daunting. What may seem like minor details in the configuration process can quickly turn into significant roadblocks, making the idea of achieving full financial sovereignty seem out of reach for many.

A recent case highlights these challenges. A client was struggling to set up his own Lightning node and integrate various tools for public access. After several unsuccessful attempts, he sought specialized help. Through targeted assistance, he was able to configure everything properly, integrating the LNBits wallet system and using Cloudflare Tunnel to make his node services accessible to the public. The moment of satisfaction, seeing the Lightning node fully operational, highlights how expert guidance can make all the difference in achieving true decentralization.

#### Owning your financial infrastructure

Running your own node is more than just a technical endeavor, it’s a declaration of independence and personal sovereignty. With a fully functional node, you can not only participate directly in the Bitcoin and Lightning networks but also integrate with advanced tools like LNbits and even ecash mints. These tools allow for enhanced management of your funds, enabling you to become a custodian for others, should you choose to. This level of control turns you into a provider of financial services, offering custody and liquidity to others while maintaining the highest standards of privacy and security for yourself.

By stepping into this role, you ascend to the new nobility of the decentralized financial world, no longer subject to the whims of centralized authorities or institutions. In a decentralized environment, you don't need to curry favor with banks or governments to manage your wealth. Instead, you stand as an equal among peers in a global financial system that’s open, transparent, and free from gatekeepers. Without needing to be in the king’s favor, you become your own bank.

#### The road ahead: challenges and opportunities

While the technical barriers are real, the tools and support available for setting up Bitcoin and Lightning nodes are improving rapidly. Communities are growing, and more resources are being dedicated to simplifying the process. For those willing to learn, the rewards are immense: financial sovereignty, complete privacy, and the ability to engage in a system that operates outside the control of traditional financial institutions. Running a node is not just about contributing to the network, it's about taking an active role in shaping the future of money.

As more people embrace this technology, the vision of a decentralized financial ecosystem, where anyone can be their own bank, comes closer to reality. And with every new node that goes live, the Bitcoin and Lightning networks become stronger, more resilient, and more capable of sustaining the future of decentralized finance.

How to Install Regolancer on Your LND Node

#### Install the best circular-route rebalancing tool for the Lightning Network


If you already have Go installed, you can skip to step 2. To check if it's installed:

```
go version
```

If it returns the version, it means Go is installed and configured.

- Note: Versions of Go higher than the one used in this tutorial may not work with Regolancer.


## 1. Install Go

If you don’t have Go installed on your machine, follow these instructions:

1. Go to the official Go website: https://golang.org/dl/

2. Download the appropriate Go version for your system (usually amd64).

![](https://m.stacker.news/56471)

3. Install Go following the instructions provided on the website. On Linux, for example, you can follow the commands below to install Go (assuming version 1.23.2; adjust the version if necessary):

```
wget https://go.dev/dl/go1.22.4.linux-amd64.tar.gz 

sudo tar -C /usr/local -xzf go1.22.4.linux-amd64.tar.gz 

export PATH=$PATH:/usr/local/go/bin
```

4. Check if Go was installed correctly by running:
```
go version
```
This should return the Go version installed:
![](https://m.stacker.news/56472)

5. To ensure Go is set up correctly and the binary is accessible from anywhere, add the ~/go/bin path to your PATH. Add the following line to your ~/.bashrc file (or ~/.zshrc depending on your shell):
```
sudo nano ~/.bashrc

# Add after the last line:

export PATH=$PATH:$HOME/go/bin
```

6. After adding this line, update the terminal:
```
source ~/.bashrc
```

## 2. Install Regolancer

1. Now that Go is installed, you can install Regolancer using the go install command. This command will download the source code of Regolancer and compile it for your machine. Run the following command in the terminal:
```
go install github.com/rkfg/regolancer@latest
```
This will download, compile, and install the regolancer binary in the ~/go/bin/regolancer directory.

2. Check if Regolancer was installed correctly by running the following command to see its help options:
```
regolancer --help
```
This should display the command options of Regolancer, confirming the installation:

```
Usage:
  regolancer [OPTIONS]

Application Options:
--------------------
Config:
  -f, --config                 config file path

Node Connection:
  -c, --connect                connect to lnd using host:port
  -t, --tlscert                path to tls.cert to connect
      --macaroon-dir           path to the macaroon directory
      --macaroon-filename      macaroon filename
  -n, --network                bitcoin network to use

Common:
      --pfrom                  channels with less than this inbound liquidity percentage will be considered as source channels
      --pto                    channels with less than this outbound liquidity percentage will be considered as target channels
  -p, --perc                   use this value as both pfrom and pto from above
  -a, --amount                 amount to rebalance
      --rel-amount-to          calculate amount as the target channel capacity fraction (for example, 0.2 means you want to achieve at most 20% target channel local balance)
      --rel-amount-from        calculate amount as the source channel capacity fraction (for example, 0.2 means you want to achieve at most 20% source channel remote balance)
  -b, --probe-steps            if the payment fails at the last hop try to probe lower amount using this many steps
      --allow-rapid-rebalance  if a rebalance succeeds the route will be used for further rebalances until criteria for channels is not satifsied
      --min-amount             if probing is enabled this will be the minimum amount to try
  -i, --exclude-channel-in     (DEPRECATED) don't use this channel as incoming (can be specified multiple times)
  -o, --exclude-channel-out    (DEPRECATED) don't use this channel as outgoing (can be specified multiple times)
      --exclude-from           don't use this node or channel as source (can be specified multiple times)
      --exclude-to             don't use this node or channel as target (can be specified multiple times)
  -e, --exclude-channel        (DEPRECATED) don't use this channel at all (can be specified multiple times)
  -d, --exclude-node           (DEPRECATED) don't use this node for routing (can be specified multiple times)
      --exclude                don't use this node or your channel for routing (can be specified multiple times)
      --exclude-channel-age    don't use channels opened less than this number of blocks ago
      --to                     try only this channel or node as target (should satisfy other constraints too; can be specified multiple times)
      --from                   try only this channel or node as source (should satisfy other constraints too; can be specified multiple times)
      --fail-tolerance         a payment that differs from the prior attempt by this ppm will be cancelled
      --allow-unbalance-from   (DEPRECATED) let the source channel go below 50% local liquidity, use if you want to drain a channel; you should also set --pfrom to >50
      --allow-unbalance-to     (DEPRECATED) let the target channel go above 50% local liquidity, use if you want to refill a channel; you should also set --pto to >50
  -r, --econ-ratio             economical ratio for fee limit calculation as a multiple of target channel fee (for example, 0.5 means you want to pay at max half the fee you might earn for routing out of the target channel)
      --econ-ratio-max-ppm     limits the max fee ppm for a rebalance when using econ ratio
  -F, --fee-limit-ppm          don't consider the target channel fee and use this max fee ppm instead (can rebalance at a loss, be careful)
  -l, --lost-profit            also consider the source channel fee when looking for profitable routes so that route_fee < target_fee * econ_ratio - source_fee

Node Cache:
      --node-cache-filename    save and load other nodes information to this file, improves cold start performance
      --node-cache-lifetime    nodes with last update older than this time (in minutes) will be removed from cache after loading it
      --node-cache-info        show red and cyan 'x' characters in routes to indicate node cache misses and hits respectively

Timeouts:
      --timeout-rebalance      max rebalance session time in minutes
      --timeout-attempt        max attempt time in minutes
      --timeout-info           max general info query time (local channels, node id etc.) in seconds
      --timeout-route          max channel selection and route query time in seconds

Others:
  -s, --stat                   save successful rebalance information to the specified CSV file
  -v, --version                show program version and exit
      --info                   show rebalance information
  -h, --help                   Show this help message
```

## 3. Configuring the config.json File

1. Create a configuration file for Regolancer, typically named config.json. This file contains the parameters needed for Regolancer to know which channels to rebalance and the fee/route options.
```
sudo mkdir ~/regolancer

sudo nano ~/regolancer/config.json
```

2. Copy and paste the following configuration:
```
{
    "macaroon_dir": "/data/lnd/data/chain/bitcoin/mainnet/",
    "macaroon_filename": "admin.macaroon",
    "network": "mainnet",
    "tlscert": "/data/lnd/tls.cert",
    "econ_ratio": 0.80,
    "amount": 201000,
    "min_amount": 5000,
    "probe_steps": 15,
    "allow-rapid-rebalance": true,
    "pfrom": 90,
    "pto": 30,
    "stat": "rebalances.csv",
    "lost_profit": true,
    "exclude_from": [],
    "to": [],
    "timeout_rebalance": 900,
    "timeout_attempt": 60,
    "timeout_info": 30,
    "timeout_route": 180
}
```
* **macaroon_dir:** Directory where the macaroon file is located, needed for authentication with the lnd daemon.
* **macaroon_filename:** Name of the macaroon file, typically admin.macaroon.
* **network:** Network your node is running on, set to mainnet.
* **tlscert:** Path to the TLS certificate used for secure communication between Regolancer and lnd.
* **econ_ratio:** Economic ratio for fee calculation. 0.80 means rebalancing will be attempted if the cost is up to 80% of the outbound channel fee.
* **amount:** Default amount for rebalancing (201,000 sats).
* **min_amount:** Minimum amount to rebalance (5,000 sats).
* **probe_steps:** Number of steps for probing routes (15 steps).
* **allow-rapid-rebalance:** Enables fast rebalancing without additional time limits.
* **pfrom:** Inbound liquidity percentage allowed from a source channel for rebalancing (90%).
* **pto:** Outbound liquidity minimum required in a target channel for rebalancing (30%).
* **stat:** File where rebalance statistics will be saved (rebalances.csv).
* **lost_profit:** Whether to calculate lost profit from failed rebalances (set to true).
* **timeout_rebalance:** Max time in seconds for the entire rebalance session (900 seconds).
* **timeout_attempt:** Max time in seconds for each attempt (60 seconds).
* **timeout_info:** Max time in seconds to gather node information (30 seconds).
* **timeout_route:** Max time in seconds to calculate the rebalance route (180 seconds).

3. Running Regolancer:
With the configuration ready, you can run Regolancer using the config file you created. Replace /path/to/your/config.json with the full path to your configuration file.
```
regolancer --config /path/to/your/config.json

# example:
regolancer --config /home/admin/regolancer/config.json
```

4. Using Node Cache (optional):
This option allows Regolancer to store node information for faster queries on future runs
```
regolancer --config /path/to/your/config.json --node-cache-filename /path/to/cache.dat
```

5. Set Additional Parameters (optional):
```
regolancer --config /path/to/your/config.json --node-cache-lifetime 720

# Cache valid for 12 hours
```

## 4. BONUS: Regolancer-Controller By [BRLN](https://br-ln.com/)

The regolancer-controller is a tool developed to complement Regolancer, automating and managing the control of channel rebalancing in the Lightning Network. Its main goal is to provide additional control and monitoring, making the process more efficient and scalable, especially in complex operations with multiple channels and nodes.

**Key Features of Regolancer-Controller:**

**1. Rebalancing Automation:** Automatically configures and executes channel rebalancing.
**2. Monitoring and Logs:** Provides real-time monitoring and detailed logs.
**3. Scheduled Execution:** Allows scheduled rebalances.
**4. Flexible Configurations:** Various configurable parameters.

Access the repository on GitHub to see how the regolancer-controller can simplify your liquidity management:

👉 Check out the regolancer-controller [here](https://github.com/jvxis/regolancer-controller)


## 5. Running the Controller as a Service

#### 1. Create the Service File
1. First, create the systemd service file:
```
sudo nano /etc/systemd/system/regolancer-controller.service
```

2. Paste the following content into the file:
```
[Unit]
Description=Regolancer Controller
After=lnd.service

[Service]
ExecStart=/usr/bin/python3 /path/to/regolancer-controller/regolancer-controler.py
WorkingDirectory=/path/to/regolancer-controller/
Restart=always
User=<user>
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
```

* Replace /path/to/regolancer-controller/ with the correct path to the regolancer-controller.py script.
* Replace <user> with the user who should run the service.
* Save and close the file (Ctrl + O to save, Ctrl + X to exit).

#### 2.  Reload Systemd Services

1. After creating the file, reload the systemd services so the new service is recognized:
```
sudo systemctl daemon-reload
```

#### 3. Start and Enable the Service

1. To start the service:
```
sudo systemctl start regolancer-controller.service
```

2. To enable the service at boot:
```
sudo systemctl enable regolancer-controller.service
```

#### 4. Check Service Status
1. To check if the service is running correctly:
```
sudo systemctl status regolancer-controller.service
```

#### 5.  View Service Logs
1. To check the service logs for troubleshooting:
```
sudo journalctl -fu regolancer-controller
```
2. To view logs from the beginning:
```
sudo journalctl -xeu regolancer-controller
```
