Working in a small team of routing nodes, we successfully ran a test of the attack with real funds and demonstrated the “griefing” attack described by Joost Jager. The attack is called a grief attack since it is not a theft of funds, but it causes a victim’s Lightning funds to be frozen: a major upset. What we found is that griefing is a serious threat to large “wumbo” channels expecting to earn a yield on their bitcoin, only to have their funds frozen for a period of time. 

[paywall price=”100″]

This is mostly a grief attack: no loss of funds, but the victim may be forced to pay for an expensive channel force close. This is a known vulnerability on mainnet Lightning and it needs to be understood and prioritized, especially at this early market stage of Bitcoin’s Lightning Network.

Thanks to Clark Burkhardt and Phillip Sheppard for their willingness to participate in this test and to Jager for his tireless work to bring attention and priority to this vulnerability. Jager played the role of the attacker for our demonstration, while Burkhardt and Sheppard joined me as connected victim routing nodes.

How The Attack Works

The attacker saturates one (or several) channel(s) with Hashed Time Locked Contracts (HTLCs) that don’t resolve as a finalized payment. These are a special breed of HTLCs known as HODL invoices. Only 483 of these unresolved HTLCs are required to overwhelm a channel per direction. Once those HTLCs are in the channel, any transactions using that same channel direction are impossible, including a transaction to cooperatively close that channel.

In theory, an attacker could contact the victim (perhaps via a keysend message or in an “onion blob”) and demand a ransom be paid to halt the attack. Once the ransom is paid, the attacker could remove the unresolved payments, ending the attack. The attack can be sustained indefinitely, halting all routing and payment activity in that channel. This freezes the funds in the Lightning channel.

Both directions of payments can be stalled in a channel by using 483 HTLCs in each direction, both inbound and outbound.

Why Would An Attacker Do Something Like This?

The first motive that comes to mind is to demand a ransom. This attack causes pain for the victim and paying a ransom may be attractive to a victim, even without assurance that the attack would stop. Contacting the victim might be risky for an attacker, but a ransom payment might not be the only reason someone would do this.

A secondary incentive for launching a griefing attack would be to disrupt routing competition. Jamming a competitor’s route could create more demand for a route owned by an attacker.

As a benchmark, consider that Lightning Labs’ Loop node has an ongoing demand for liquidity for which it will sometimes pay a 2,500 parts per million of the payment (ppm) (0.25 percent) fee rate. In my experience, they would normally exhaust 16 million sats worth of liquidity in about two weeks (5.2 percent annual percentage rate), but that is with competition present. 

If an attacker could disable any competing route with lower fee rates, Loop may be willing to pay a higher fee rate (since the supply of liquidity is now reduced). Let’s say Loop would pay 3,000 ppm (0.3 percent), as well as use that liquidity more quickly since no other channels are functioning. Loop might use that liquidity in half the time, say one week. The attacker would more than double their usual yield to 15.6 percent APR in this example. The only cost to the attacker is the cost of running a script on an existing channel and the psychological cost of doing something immoral/damaging to the Lightning Network. With a single attacker channel, a malicious actor could jam about nine channels (see Jager’s tweets about this).

What Would The Victim Of This Attack Experience?

The victim of this attack wouldn’t really know that this attack was happening unless they had some special alerts set for pending HTLCs. For Thunderhub users (a highly recommended tool), the home screen will show a chart of pending HTLCs as well as a warning stating that channels can only hold 483 pending HTLCs.

In practice, my node quickly became unreliable and experienced several app crashes, including Thunderhub, which was the only app to notify me of the problem. Then, thanks to my “Balance of Satoshis” Telegram bot, I got a channel closing notification. The channel under attack force-closed itself! That was not supposed to be part of the experiment. (For more technical information on the involuntary force close, see below for additional force-close data.)

What Can The Victim Do To Stop A Griefing Attack?

Once an attack starts, a victim essentially can’t do anything to stop it. The only alternatives available to halt an ongoing attack would be to force-close the channel being attacked, which means that the terrorists win. 

To add insult to injury, force-closing the channel will push the unresolved payments to the on-chain transaction data, triggering secondary on-chain transactions for the initiator of the force close. At 50 sats/vbyte and 483 on-chain transactions, that’s easily a 1 million sat price tag to force close a single channel under attack (a $368 channel close fee at today’s prices). The multiple on-chain transactions only occur if the output is above the minimum payment “dust” limit. (See this example on testnet.)

How To Prevent A Griefing Attack

Jager has been working on a proof-of-concept program to help isolate and fight attackers. He’s calling his program “Circuitbreaker.” The Circuitbreaker works at a network level, which unfortunately means that everyone has to participate for it to be effective.

Beyond that, this issue needs prioritization and attention from dedicated engineers/developers to find better solutions. There have also been some good discussions on modifying the protocol in the Bitcoin Optech newsletter (issue #122 or #126).

This attack can be executed today. It is a miracle that it hasn’t already been used maliciously. It’s a reflection of the incentives for those using Lightning today so that it can become an open, universal payment network. Please share this post as you see fit to encourage and inspire more work to fix this problem before it causes real harm.

Additional Technical Information About The Involuntary Force-Close

Here are the logs from my node running LND 0.11 at the moment that the above mentioned involuntary force-close occured:

2020-11-26 21:24:47.374 [ERR] HSWC: ChannelLink(657759:561:0): failing link: ChannelPoint (c37bec006b18df172698a84739ca47128935e0a8666fecd1a843e49b01db207c:0): received error from peer: chan_id=7c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc3, err=rejected commitment: commit_height=455, invalid_commit_sig=3044022076fd65191eb6305b723fa6012be378413b6326e2786c38db58b4c02e1f3999d202207605ca31de8b4c5b1d9cd20dc1581dfa2383e0b4e06c8ad4f718ab5c434d8cf5, commit_tx=02000000017c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc300000000008a792e8002210d0000000000002200201031cf10a1efef261edd3d0a1a6a953b27bc25bd7150bb2b07afdc69805e02157213000000000000160014de650929042bef58b71783ae1a44834a902a8f2d542ca720, sig_hash=4e0fb804c74376020e4c44a60969b9206eb0aaa9a89b76017d60f23ad5cf63e5 with error: remote error

The logs show an “invalid_commit_sig” which is a known issue in LND. Supposedly, this can happen upon reconnecting and isn’t a direct result of the channel jamming. The volume of pending HTLCs unfortunately makes it more likely to happen. Jager helped explain the process as channel jamming –> endless payment loop (bug) –> node down –> reconnect –> invalid commit sig (bug) –> channel force-close.

The “endless” loop bug is a known bug that occurs when the HTLC limit is reached and an additional HTLC is sent. Instead of ending in a payment failure, LND will continue to attempt the payment in a loop. To help with this bug, see LND issue #4656.

[/paywall]

The post Good Griefing: A Lingering Vulnerability On Lightning Network That Still Needs Fixing appeared first on SatBase.org.

[paywall price=”500″]

Lightning channels allow near-instant settlement of bitcoin transactions, which is a valuable service, especially to retailers and exchanges. Similar to how retailers will pay credit card fees to provide convenience to their customers, retailers will buy lightning channels that provide rapid settlement for their bitcoin patrons. The pricing is very different though: Credit Card companies will often charge 2-4% fees, while Lightning Liquidity is market-driven and currently less than 0.2% fees.

Offer Markovich, an enterprising developer from Israel, assembled the Lightning Liquidity Bot (@LightningLiquidityBot) as a way to create an open market for liquidity. The bot is based in Telegram and is an attractive alternative to Lightning Lab’s Pool service.

How to use @LightningLiquidityBot:

This bot lists paid requests for liquidity on the lightning network. Using @LightningLiquidityBot bot is a lightweight and friendly way to get exposure to lightning liquidity buys/sales.

The bot supports node filtering based on a node’s betweenness centrality measure. It ranks each node as A,B,C,D, or E, where A is best. Use @ln_name_server_bot to check a node’s ratings.

How to sell liquidity using the bot:

1. Make sure that you have keysend enabled. In your LND.conf file, make sure that it contains the line accept-keysend=true so you can receive your payments.
2. Start a DM conversation with @LightningLiquidityBot and use the command /signals to list the current requests for liquidity.
3. Zoom to a specific request using the command /signal .
4. If you find an attractive offer listed, add the node as a peer. Make sure you are able to add them as a peer before you proceed!
5. Use the command /accept to accept the offer.
6. Open a channel to the peer and keep the channel open to receive payments via keysend over the order duration. If the channel is closed prematurely, the order will be relisted automatically with the bot. Payments will occur weekly once the earnings are >1000 sats.

How to buy liquidity using the bot:

1. Start a DM conversation with @LightningLiquidityBot.
2. Use the following command to request inbound liquidity:
   /invite <pubkey> <total amount requested> <days> <min chan size> <max chan size> <node centrality rating A-D> <payment offered for channel>

Example: (10M capacity for 30 days, 1M minimum, 3.5 maximum, minimum C rating, and 10K total reward)
/invite 0349382bd894403988032f446cd2ad58a311685260885f50b483807ff356caf108 10000000 30 1000000 3500000 C 10000

3. Pay the generated invoice to list your order with the bot.

This bot was created by @offerm so please reach out for help or troubleshooting.

Costs

For those selling liquidity, costs are limited to channel open costs, which can be minimized by using smart mempool techniques ( Satbase.org/the-mempool-and-lightning ) or by using batched channel opens ( Satbase.org/bos-open ).

For those buying liquidity, there is a flat 5000 sat listing fee in addition to the payment made to the liquidity provider.

The post Lightning Liquidity Bot: a way to buy/sell liquidity within Telegram appeared first on SatBase.org.

The upside: The world is in dire need of stimulus and every central bank in the world is printing currency like mad to keep their economies working. The current system is incapable of distributing money to where it is needed fast enough in a borderless fashion. A central bank digital currency or a global digital currency would fix that issue as well as improving financial inclusion and automating financial services or taxation.

The downside: governments will not allow illegal transactions to occur, meaning every transaction will be surveilled. Your financial behavior will be actively managed through economic incentives without the usual intermediaries i.e. national or regional banks. You will not be able to vote on such a system, just as you are not able to vote for members of the federal reserve or leaders of the IMF. There is no mechanism for a global democratic process nor are there incentives for such a vote. A CBDC allows the potential for fine-grained control of every economic participant with potentially zero checks or balances on that power. That includes individualized interest rates (including positive and negative rates) and sets the stage for corruption by a powerful few.

There are two systems that I’m aware of that are immune to a move to CBDCs. Physical Gold and Bitcoin. Gold has been a store of value for millennia, but it can be seized forcibly and gold is not capable of resolving the global digital payment system needs. Bitcoin is an already functioning and reliable financial network that has no centralized leader that controls it. It is controlled by consensus through the use of computing power and energy on a global scale. It cannot be stopped.

The post Central Bank Digital Currencies appeared first on SatBase.org.

[paywall price=”100″]

Want to create your own? A subgenre chat I can link to? Here’s what goes into it:

Meet your helper bots

There are two bots involved in this chat: @scdlbot and @LNtxbot. The first bot creates an .mp3 file from any YouTube, Soundcloud, or Bandcamp link and posts it in the chat, assembled by @gpchelkin and based off this repo . The second is a bot that keeps track of your tips. In more geeky terms, it’s a full-featured custodial bitcoin lightning wallet with text-based commands and a QR code reader.

Setting up the SoundCloud Download bot (@scdlbot) is as simple as adding the bot to the chat. Then, you can use the “/settings” command to set your preferences with the pretty interface gpchelkin created.

Setting up the Lightning Network Transaction bot involves a couple more steps.

1. Add @LNtxbot to the chat.
2. Make @LNtxbot an admin of the chat. (This lets commands be shorter e.g. “/tip 100” instead of “/tip@lntxbot 100”.) Navigate to the Group Description > Edit icon > Administrators > Add Admin.
3. In the chat, make the bot “spammy” so that it reads out that you successfully tipped someone for a great track. Use the command “/toggle@lntxbot spammy” to turn on/off bot text responses when a payment is made in the group chat.
4. Take a moment to revel in the fact that you have enabled commerce to occur in yet another part of the internet. Not only that, the commerce here happens in a place with great music.

If you’re starting up a new genre chat, send me a link (@Jestopher) so we can link to each other as true lightning networking professionals.

Getting Your Finances in Order

How are you going to start tipping people without some internet money already? If you have no experience with lightning or bitcoin, download Strike app just as you would Venmo or Cash App. The only main difference is that Strike can turn dollars (soon other fiat, too) into bitcoin on-the-fly as you make a payment.

We’re not talking large amounts here! Just put $5 in Strike so you can pay to @lntxbot. After all, LNtxbot is a custodial lightning wallet, which means dear @fiatjaf can shut down the bot and you’d lose access to your funds. Your keys, your coins!

To add a balance to @LNtxbot, create an invoice in a PM with the bot by typing “/invoice <sats> [description]”. The bot will create an invoice payable with Strike or another lightning wallet.

[/paywall]

The post Lightning Deep Cuts appeared first on SatBase.org.

[paywall price=”1337″]

[Just a quick note: by using this technique, you don't need to leave any on-chain balance on your lightning node; you can keep your non-lightning funds safely behind the protection of your hardware wallet's security instead of an internet-connected hot wallet that isn't producing any routing income. ]

WHY DO BATCH CHANNEL OPENS

One of the primary costs of running a lightning node is on chain transaction fees. By batching together channel opens, you can reduce costs massively. As an example, check out BOS developer Alex Bosworth’s incredible batched channel open deploying 2.69 BTC of liquidity in 13 channels on the lightning network in a measly 669 vbytes transaction. That’s a 1338 sat fee overall or a 0.00049% chain fee.

Using the bos open command may be one of the highest value bitcoin transactions that you will ever do and there is a ten minute time limit. So, take your time understanding the steps before launching into this power-user tool with high value channels.

Setting Up Electrum (4.0.2) for BOS

Let’s get Electrum ready so your can execute your batched channel open smoothly (and quickly).

1. Go to Tools > Preferences.
   
   
2. Under the Transactions tab, Activate Advanced preview. This will allow you to copy the signed transaction into BOS later.
   
3. Open the Pay to many dialog in Electrum.

Running like a BOS

First, install Balance of Satoshis or use this guide if you’re running a Raspiblitz.

Get to the command line interface and switch to the bos user (sudo su - bos on Raspiblitz).

Then, run the following command with the node public keys that you want to open channels to, followed by the amount flag and the capacity that you would like that channel to have. You can enter several public keys and their respective amounts at this stage. BOS will prepare bitcoin addresses to pay to in the following step.

STOP – READ AHEAD BEFORE ENTERING THIS COMMAND – you will be starting a ten minute timer for yourself, so best be familiar with the next steps before starting. If at any point, you want to stop the timer and start over, press enter in the command line interface (don’t use Ctrl-C here).

bos open <node pubkey 1> --amount <channel size in sats 1> <node pubkey 2> --amount <channel size in sats 2> ...

The output of this command will be an instruction to pay several bitcoin addresses that will resolve to the channels that you’ll be opening. DO NOT BROADCAST THIS TRANSACTION YOURSELF. Only BOS should be broadcasting this transaction.

Use electrum’s pay to many function to copy/paste the output from bos open to electrum using the format already provided as part of BOS that matches with electrum’s format.

Sign the transaction in electrum with appropriate chain fee rate (DON’T SELF BROADCAST) (next block fee rate is best). Then, copy the signed raw transaction into BOS where BOS will broadcast the transaction for you.

When you see the transaction ID shown in BOS, you can check on the status of your transaction using a personal or public block explorer.

If you mess up

Either you didn’t set a high enough chain fee or your transaction didn’t broadcast. Whatever you do, DON’T TRY TO BUMP THE FEE USING ELECTRUM. If you’re absolutely desperate and the transaction hasn’t yet confirmed, you can double spend the coins that you used for the channel opens with a higher fee by using Electrum’s coin control features. You can also use ‘Enter’ to cancel the procedure; Don’t use Ctrl-C.

If nothing else, this link may be helpful. Or, consider joining the Balance of Satoshis chat on Telegram for additional assistance.

[/paywall]

_{Want to support more content like this? Please consider donating to satbase.org so this can become a full-time endeavor. I’m still working on getting btcpay set up, but you can navigate to the contact us page and send a lightning keysend payment if you are so inclined. Thank you.}

Donate with

The post Balance Of Satoshis: Batch Open Channels appeared first on SatBase.org.

[paywall price=”200″]

Lightning channels carry risk

The hashtag that’s unquestionably associated with the Lightning Network is #reckless. While base layer Bitcoin is a slow-moving bedrock that places caution and consensus before all else, the LN is a fast-paced, amorphous network of relationships that are inherently volatile. There are fundamental differences when dealing in lightning compared to base layer bitcoin. The departures from certainty in Bitcoin can be priced as risk on the Lightning Network.

While hardly anyone has actually lost funds in stuck channels in lightning, users still have to contend with the fact that their precious bitcoin is being stored on a device that is continuously connected to the internet. Being internet-connected means that the attack surface for hacks is much larger. This isn’t meant to scare you, it’s intended to help you price your risk as you provide a valuable service to your peers.

Channels provide a valuable service

You’re not putting your money on the internet just because it’s popular! By starting up a lightning node, you’re committing time and funds towards a valuable service to the Bitcoin Network. Not only are you saving on transaction fees for purchases, but you are also enabling near-instant financial settlement, improvements to network privacy, enhancements to fungibility, efficient use of the blockchain, and yield on bitcoin. In exchange for the risks that you face and the services that you provide, you should feel comfortable setting a routing fee that acknowledges the risks you face and the market for your services.

Liquidity is the scale of contribution

The most common pattern that I’ve observed about new entrants to lightning is that they are afraid to lose funds and then decide to only make small channels ($10-50 range). What’s the market for a channel that size? Mostly, the market is you and only you at that scale.

A good practice would be to forecast what the average transaction size would be across a given $10 sized channel. If the average transaction size is $1, you can get ten $1 transactions before needing to rebalance. Great! This is a great size if the only expected transactions would be true micropayments. However, this completely misses the concept of the Network part of LN. You are not opening a channel to only one node; you are merging two networks: All of your channel peers can now send funds to all of their peers through your new channel.

Note: Pollofeed.com would be a great channel partner for a $10 sized channel because the average transaction size is <$1, especially if you aren't interested in what other channels pollofeed.com has and you just really love feeding chickens. 

How useful is a $10 channel to your combined communities? Is the average payment of your entire community going to be less than $10? Can you afford to spend the time to rebalance that channel to continue to provide a service to your community? The answer is most likely that a small channel will only provide for a couple of your own micropayments, but not provide any service to the greater lightning community nor provide a source of yield on your bitcoin.

If you choose to open a larger channel, suddenly larger payments will be able to travel through your node, yielding you routing fees, and providing additional network services to your community with less rebalancing maintenance. Once you’re comfortable with the protocol and understand what you’re doing, start with larger channels as they provide greater benefit and yield. In short, GO BIG OR GO HOME.

Let’s talk numbers

Okay, brass tacks. Set the fee so that if the channel liquidity moves from the start (usually all local) to either extreme (probably all remote), it will pay for the chain fees that it took to set up this system. Chain fees include both opening the channel and closing the channel. The routing preference for LND is not based on the cheapest route, IT IS BASED ON THE LIKELIHOOD OF ROUTING SUCCESS. So, don’t worry about charging a lot; worry about not charging enough.

Okay say your channel is 1 million satoshis. In order to pay for the chain fee of say ~200 sats and a channel close fee of the same amount, you’ll need to set your base fee to a number greater than zero (doesn’t really matter) and your rate fee to (200 sats open + 200 sats close)/ 1M capacity = 400 ppm. PPM is parts per million, which is parts fee per million sats routed. You can already see with this thinking that you want bigger channels, so the chain fees don’t negate your routing activity income. If you went with a 2M sat channel, you’d only need to charge half that rate to break even.

To save on additional chain fees, you can use batch open tools as part of Balance of Satoshis (BOS), the secret weapon of routing nodes. You can use bos open with an external wallet to open channels and save an immense amount on fees. The bos open tool would be perfect if you use electrum’s pay to many feature to pay directly from your cold storage electrum wallet to your lightning node. That way, you don’t have to keep spare funds on your hot wallet node that aren’t being fully capitalized in a productive channel.

[/paywall]

Did you like what you read? Send a tip to support more great lightning content.

bc1qmpdtxqnnvpqf55kd3rz3r8kr3grkz7hjvdgjyp

The post Setting Routing Fees appeared first on SatBase.org.

[paywall price=”100″]

Reading the Mempool

Just to keep an eye on the mempool, I really like to use Johoe’s Bitcoin Mempool Statistics (why not tip them a few sats?). Johoe’s has been around for a while, but I really like the colorful display and the really useful tooltip information as you hover the mouse over the dynamic chart.

The really important information for us is the third chart, the mempool size in MB. That chart tells us the MB size of the transactions that are paying a higher fee than us. If we assume that the next block will be full, it should be close to 1MB of transactions (SegWit makes this slightly larger than 1MB, but let’s take the conservative approach here and assume smaller blocks).

If you hover the mouse (or tap at a certain point on mobile), you should see a little donut indicator showing where you’re examining on the graph. I’ve highlighted that region with a purple arrow since the green donut is a little hard to see. A tooltip will also show that at the highlighted point in the mempool, there is 1.039 MB of transactions above the 40 sat/vByte level. That means that there’s about zero chance that we’re going to get our 40 sat/vByte transaction in the next block.

On the other hand, look at how many times that the mempool has completely cleared out in the past few hours. I will enjoy these times while they last. I don’t need to open my channel in the next block, so I’m comfortable choosing a lower fee to get my transaction confirmed.

I went with a 2 sat/byte transaction to deposit to my lightning node since I have a wallet that supports Replace-By-Fee (RBF). RBF allows me to “bump” the fee with a subsequent transaction that increases the reward for miners to include my transaction in a block.

Forecasting the Mempool

Watching the mempool is great if you like to see how the mempool has performed in the past and if there are any recurring patterns. One pattern that I’ve noticed is that the mempool typically is a lot lighter on the weekends, meaning we can do our channel opens then and save a bit on chain fees. There are often greater forces at play in Bitcoin, specifically energy costs, miners, bitcoin price, and the block difficulty which gives us a way to predict how the mempool might look in the near future (2-3 week outlook).

If we’re looking at a bunch of different metrics for bitcoin at once, look no further than Clark Moody’s Dashboard.

I’m going to assume that you’re already familiar with what bitcoin mining is generally, but the part we’re interested in is the Difficulty Adjustment. It’s maybe the most beautiful part of the Bitcoin protocol and it has the biggest effect on the mempool in the short term.

Bitcoin miners are always trying to solve a similar math problem to get the block reward. They have to solve the math problems by brute force, which means that the time it takes to solve a problem (to mine a block) is a random variable. The difficulty of the math problem is determined by the last 2016 blocks and how long it took to mine those blocks, on average. If the blocks were solved faster than 10 minutes, the difficulty increases. If the blocks came in slower than every 10 minutes, the difficulty decreases. In general, the difficulty “retargets” every 2016 blocks.

From the snippet above, we can see that we’re 1,049 blocks away from the upcoming difficulty retarget. The estimated difficulty change is estimated to increase by 8.6%. That’s a huge change! That means that blocks will get solved slower and unconfirmed transactions are going to start piling up, which means higher transaction fees in the future.

(As a quick aside, this is when I bump up the fee on the still unconfirmed 2 sat/vbyte transaction I tried to send earlier. I set it to 5 sats/vbyte. Fingers crossed.)

The thing to know about the mining industry is that it takes a lot more effort to build and deploy a new miner than it does to shut a miner off. For us, that means that if there’s a downward difficulty adjustment coming up, we could see some less efficient miners quickly come back online, making blocks come in faster. And if there’s an upward difficulty adjustment coming up, some less efficient miners might get turned off, which means that blocks will come in even slower than every 10 minutes. So, I’m going to be a lot more eager than I otherwise would be to get this transaction confirmed. The next few weeks might be a very difficult time to get a low fee transaction confirmed.

With all that information, best of luck out there and may the sats be with you!

[/paywall]

_{Did you like what you read? If so, send a tip to support more educational lightning content and share this post with your friends.}

The post The Mempool and Lightning appeared first on SatBase.org.

What makes a good lightning channel?

• Connectivity
• Capacity
• Uptime/Availability

How can I find people looking for new channels?

Start by joining the best telegram channel for this purpose: https://t.me/LNBalancedChannels

*Warning*: Be ready to pay the entry fee lightning invoice within 15 minutes. If you don’t make it in time, send me a keysend message with your @ username and I’ll give you another shot.

Opening A Balanced Channel:

Here are the instructions to give to the trusted peer after the trusting peer completes the details:

1.) add me as a peer
<node id>@<IP address >:9735
2.) Send me an on-chain receive address (can be your node) in a PM so I can fund my end.
3.) Send funds to your on-chain lightning wallet (if not already there) to fund your end.
3.) Navigate to the command line interface
4.) Let’s discuss channel size and proofread the subsequent command:
5.) Construct the following in a single command:
lncli openchannel <node id> –local_amt <total channel capacity> –push_amt <amount to send on lightning> –sat_per_byte <chain fee rate>
6.) Double check together that all user-entered data is appropriate before entering the command.

Don’t know who to open a channel to?

• Announce to the group that you’re looking to open a channel.
• Specify how many sats you’re willing to contribute to the channel.
• Request a willing peer’s pubkey so you can check on 1ml.com whether they will be an appropriate peer for you.

Helpful bots:

Note – Please use commands to the bots in a DM, and not in the group chat to keep the chat less cluttered.

@ln_name_server_bot
-Purpose: matches telegram user names to the pubkey of their node.
-Commands: / claim (adds your node to the list), / list (lists all telegram users and their associated pubkeys)
-Questions? Ask @offerm

@lightningwatchbot
-Purpose: notifies you if/when your node is down, continues to notify you if you node is down for an extended period.
-Commands: Open a DM to lightningwatchbot and enter / start. It will walk you through.
-Questions? Ask in the Support chat – https://t.me/lightningwatch

@lntxbot
-Purpose: A fully functional custodial Lightning Wallet for telegram.
-Commands: Open a DM to lntxbot and enter / start. It has too many features to list.
-Tip: To pay any invoice in telegram, forward the invoice or QR to your chat with the bot.
-Questions? Join https://t.me/lntxbot_dev and get ready to pay the entry invoice.

Additional Tools:

Balance of Satoshis (BOS): a power-user command line tool that specializes in finding the cheapest circular rebalances, creates your own telegram bot using BotFather, and many many other features.
Questions? Join Balance of Satoshis Chat – https://t.me/balanceofsatoshis.

Thunderhub: A Beautiful GUI for gathering stats from your node, viewing channel balanced-ness, and new features with frequent updates.
Questions? Join Thunderhub Chat – https://t.me/thunderhub.

The post Choosing a Channel Peer appeared first on SatBase.org.