"What is the best way to manage Lightning channels?"
"I understand that, to be an effective Lightning node, one must curate channels that the node has in place."
"What is the best way to select nodes to open channels to?"
"I heard about balancing channels, so that they are not uni-directional."
"But I have been unable to find good instructions on how to do that."
"What techniques are available to balance Lightning channels?"
This is a really good question.
Rebalancing channels, how to open channels, and how to connect your node. These are challenges.
If you are node operator.. I am a node operator. I run a Lightning node. It has been running continuously...
for over 10 months on the mainnet Lightning Network.
Before that, I was running a Lightning node on the Lightning testnet for a year,
so I have quite a bit of experience with maintaining and managing nodes, finding ways to connect [properly].
At the moment, my Lightning node is routing approximately one hundred payments per day.
There is forwarding activity, which means the channels are being utilized.
You (as an operator) can see the channels being utilized in both directions.
[If you are not an operator], you can't easily see this, but if you use the 'listchannels' command on lnd,
or the equivalent command with other node software, you will see that every channel has two balances.
Not one. It has a local balance and a remote balance.
In Lightning channels, you are moving chunks of money, or balances, back and forth.
A balance accumulates on either side.
One of the best ways I have been able to describe this: [imagine you are] in a bar with two dishes of peanuts.
Convenience food they provide in bars for free, when you buy a drink-
Wait, it is not free, because I bought a drink. Okay, I may need to reconsider my bar example.
[Anyway], you will have two dishes full of peanuts, right? Think of one dish as being your local balance,
the other dish being the remote balance, and between them is the channel.
When you open a channel to another node, if you start the channel, then you fund it.
Your side is full of peanuts, the other side is empty. For example, you have a local balance of 500,000 satoshis.
And a remote balance of zero. To send the payments, you will take peanuts from this side of the channel...
and move them to the [other] side of the channel.
That means someone can send you a payment back, because there is a pile of peanuts on the other side.
If someone wants to send a payment to you over that channel, they can move these back to your side.
The moment you make a payment, you create balance on the other side.
That is the hard way of creating [a remote] balance, which allows your node to receive payments...
or to do forwarding / routing.
A better way would be, if people on the outside opened a channel to your node and funded their end.
Basically, expecting people to "lock up" some of their money in a channel towards your node.
Why would they do that? If they consider your node to be well-connected, funded,
and managed with high availability.
When I decide which node to connect to, I am looking for nodes that are well connected to the outside world,
nodes which have been [running] for months without interruption, high balances and capacity.
That means they can route out from themselves, so I will be able to use them as hops to reach other nodes.
I am looking for nodes that are well connected, with enough channels to other well connected nodes.
There are websites where you can type in the public key of your node...
and it will tell you which ones to connect to in order to maximize your connectivity in the network.
For example, it will give you a list of public keys of nodes that will give you two hops access...
to 880 other nodes.
The second-best option will give you two hops access to 600 nodes. The third best will give you... and so on.
It will give you a long list of nodes. Theoretically, you could scroll through that and connect...
outgoing channels to them.
There are also nodes that will connect back to you.
Again, there are various websites with information about that. There are also nodes where you can buy...
incoming channel capacity.
You need to connect to them, send a few satoshis, and they will open a channel back to you.
That way, you have balance on both sides.
Rebalancing is the process of making sure that the balances on either side of various channels...
allow your node to be useful to other nodes for forwarding, which can earn you fees.
Your node will have the ability to both make and receive payments.
To maintain that balance, there are a number of different techniques you can use and there is ongoing research.
I will just give you a few quick examples.
One technique is to open new channels. You can close channels that are not effective or being used efficiently,
or that are connected to nodes which are not useful.
In that case, you will pay on-chain fees. You will need to decide if that is worth doing,
opening and closing channels to rebalance things.
One interesting technique that [will] exist is called splicing, where you can use a single transaction...
to both close an existing channel and open a new one.
This technique has not been implemented fully yet.
So the transaction to close a channel by spending in the 2-of-2 multi-sig used for channel funding...
can move that balance from the channel you just closed to a new 2-of-2 multi-sig,
which is the funding transaction for a new channel.
Rather than one transaction to close and [another transaction] to open another channel,
you can use [the inputs in] a single transaction to close one channel, and the outputs open another.
There will be other [ways], with splice-ins and splice-outs, which I will perhaps talk about in a second.
Rebalancing is something we are still developing techniques for.
As a node [operator], you need to think carefully about how you will manage your nodes.
Make sure your node is up [and running], has good capacity, and is well-connected to other nodes.
That will make it more likely that other people open channels to you.
I know that from experience. Even before my node [was labeled] "aantonop.
Obviously, that makes a difference in how many people open channels to you.
Although, now that I've said [what my node is], more people will put "aantonop" in their [node labels].
Damn it! Anyhow, just kidding.
Even though it is a well-known node now, it was under an alias and no one knew who was running it.
People were connecting to it just because it was connected and well-managed.
That is how you maintain balance.
Finally, keep in mind that there are some automatic tools [for channel management].
Lnd has a tool called autopilot, which will automatically open channels to various nodes...
to maintain a minimum balance.
You can set minimum and maximum balances for opening channels.
As a quick follow-up: Yes, you do need to [set up] port forwarding or UPnP incoming NAT on your router...
in order to allow incoming channel connections to your node, and be better connected to the network.
[AUDIENCE] I wanted to ask about your views and thoughts on the Lightning Network.
I recently mounted a full node myself and found it technically difficult. [ANDREAS] Yes.
[AUDIENCE] The user interface is not there yet. There are some custodial solutions, which are not ideal.
I just wanted to know your views and how it [will affect] the adoption of Bitcoin.
[ANDREAS] I am really excited about the Lightning Network. I have talked about it a lot.
I think it is a very interesting approach [to scaling], this idea of second-layer networks...
where you take advantage of the underlying security [of the blockchain] and then build something...
that can be faster and more scalable on top.
The interface is not there yet. How many people here have set up their own crypto node, of any kind?
This is a very tech heavy room. Okay, how many people don't know what 'ls' is?
There are the friends who you need to teach. 'ls' is the first command you learn, to install Linux.
That was just a silly joke. Don't worry, you don't need to know this. It is the techie's job to make it easier.
I will tell you a better story, which is [how I sent] my first email. It took [a long time].
First, I had to read about email. At the time, there were no email servers when I first accessed to the internet.
Email was very basic. I had to build a new type of email called SMTP, which is the protocol we use today.
First, I needed to download software called 'sendmail.' Then I compiled it from the source code.
That took two days of full-on geek work, to figure out all the library dependencies and some weird errors...
that the c-compiler was giving me.
This was all part of sending the email, by the way. At that time, this is what you needed to do.
Eventually, I managed to [figure it out]. Then I [wrote] my email and hit 'Send' on the command line.
"I sent my first email!" Great, and did they respond? No, it hasn't [arrived at its destination] yet. [Laughter]
It will three days to traverse the internet. It was almost like Pony Express. [imitates riding horse]
"We'll get your email to the other side! Ha-ha, faster!"
In total, it took six days to actually send the email to the other side.
The point is, that is how technology starts.
Today, installing a Lightning node [requires] an enormous amount of work.
That is part of the reason it is exciting and interesting to techies, but it will not work like that forever.
Already, I have three wallets on my phone with Lightning capabilities. But they make it a lot easier...
at the expense of some decentralization.
We are paying a bit of a price; that is okay for now. Gradually it will become easier and easier.
Eventually, everyone [will be able] to do it. Then we will have the opportunity to make some new applications.
But we need to be patient, these things take time. By the way, that first email [I sent] was in 1989.
Yes, I am that old. It was the first time I was on the internet. My mother sent her first email in 2009.
She used the new iPad I had given her and swiped like that.
Email, not Tinder! Come on. [Laughter] I wouldn't install that on my mom's iPad.
"In what scenarios would we use payment channels?"
"Can you please explain how payment channels help merchants?
Payment channels are one component of the Lightning Network.
Lightning is a network of routable payment channels connected together,
which allow you to pay someone [your node] is not connected to.
This is an important thing to understand.
If I want to pay someone over the Lightning Network, I don't need to open a payment channel to them.
I need a payment channel to someone with a channel to someone, who has a channel to someone, etc.
who has a payment channel to the merchant.
As long as your node is connected to five or six other nodes, and each of those is connected to five or six,
we take advantage of the network effect to create a variety of routes where nodes are reachable.
Then we have the ability to pay anyone on the network, without direct channels to each other.
That is the point of the Lightning Network. What is the advantage of using it?
You have instantaneous [confirmation], unlike the base layer, which takes [about] ten minutes to settle.
The Lightning Network [channels] are funded by a multi-sig [transaction] that has already confirmed.
Lightning [payments] are confirmed instantly. You can send very small payments for little or no fee.
You can send satoshis, not just hundreds of thousands of satoshis, but single satoshis.
There are certain scenarios where individuals or companies many set up payment channels...
directly to each other in order to manage a lot of flows between themselves.
For example, exchanges could set up a mesh network of payment channels between themselves...
in order to ensure that they can easily transfer from exchange to exchange without incurring on-chain fees.
Instead, they are [still] able to do it off-chain. That is one other use in the context of Lightning.
Or they could just set up direct payment channels without being part of the Lightning Network.
Think of it a bit like VPNs, as an overlay network for TCP/IP.
A payment channel is an overlay network for blockchains.
"Is there [a way to see] which addresses initiated [a payment channel]?"
"How would we identify a payment channel?"
A payment channel is funded from an on-chain transaction that stores money in a 2-of-2 multi-sig,
which will appear on the blockchain explorer as a pay-to-script (P2SH) address that starts with a '3.'
You can't identify these as specifically being payment channels until they are closed.
When they are closed, the script used to close them is easily identifiable as a Lightning payment channel,
because the script is rather unique.
Until it is spent, you can't see the script, as with any Bitcoin transaction.
You will only see the script or public key when it is spent. You see a '3' address, which is a pay-to-script hash.
You don't know what that is. It could be multi-signature, a SegWit address, or a Lightning payment channel.
You don't know. You know which addresses the money came from, but that doesn't tell you it is a channel.
In fact, we don't want people to identify and distinguish between SegWit, multi-sig, and payment channels,
because that breaks privacy.
If you can identify what kind of payment it is, you can start fingerprinting and statistical analysis,
clustering addresses together and identifying common elements of ownership.
The end goal for privacy in Bitcoin is to make every transaction look like a simple payment.
Taproot and Graftroot will hide it even more. But even now, until the channel is closed,
you can't identify it as being a channel.