The Lightning Network FAQ

[garlonicon]

The Mk node fails. And then the confirmation does not go further.

The confirmation have to go further, in other case the payment is considered incomplete. If stopping in the middle would be possible, then Alice sending coins to Daniel through Bob and Charlie could be convinced that coins reached Daniel, where in fact they reached Charlie. But because the recipient holds some information necessary to confirm the whole payment, it is impossible to stop in the middle without reaching the recipient of the message. And when that property is true in both directions, then the whole message is passed between Alice and Daniel or it fails and all nodes know it failed, because they didn't receive all pieces before the timeout.

Edit: you probably asked about https://lightning.network/lightning-network-paper.pdf point "8.1 Decrementing Timelocks" in LN whitepaper version 0.5.9.2.

In the event a party outright disconnects, the counterparty will be responsible for broadcasting the current Commitment Transaction state in the channel to the blockchain.  Only the failed non-responsive channel state gets closed out on the blockchain, all other channels should continue to update their Commitment Transactions via novation inside the channel.

[PrimeNumber7]

What would happen if the lightning node you chose, lost its multi-sig key after you deposited your coins?

You always have your channel closing transaction after depositing coins. And that means if someone is not cooperating, it does not matter if that node lost the keys or if is simply offline, you can always close the channel and then open another one with someone else.

I obviously know the answer, I just want to ensure that it can't happen in my future deposits.

Every time you deposit something, the closing transaction is constructed and signed upfront, in this way you are always protected when another party stops cooperating.

I would point out that you really do not "deposit" any coin to a lighting node.

You open a channel with another lightning node, and as long as both of you have the relivant keys, the state of the channel can change provided both of you are in agreement. If the node that you opened a channel with losses access to its keys, it will be unable to ever update the channel state, and you will eventually need to close the channel.

However if your node losses access to the relivant keys, your channel partner will need to eventually close the channel. If you have also lost the keys to the address the closing transaction will be sent to, you will have lost access to that coin, as would happen in any other case in which you lose access to your keys.

[DaveF]

So we all know this, but let me say it because I just did it.
Do not work on your Lightning Node OR ANY CRYPTO THINGS THAT INVOLVE REAL MONEY when you are distracted / busy / tired.

I have had several things I wanted to do including getting my c-lightning node back up and updating a few other things.

It was a busy couple of weeks and finally, today I figured it's the 4th of July, the office is closed, I can go in and take care of Dave's stuff.

Yeah, well. I was up late last night, got up early today and really should have just stayed around the house and relaxed.
But, I took care of a bunch of stuff around the house, did a bunch of "beginning of the month paperwork and bills" and then went to the office, skipped lunch and began moving hardware before I did the software updates. Which I screwed up...big time...because I was tired and hungry.

I managed to get the node back up and broadcast the close channels.
And, no I did not do a backup because why bother for some minor hardware work, I'll do it before I do the software upgrade.

Stupid....stupid....stupid.

I know better. Never touch hardware without doing a complete backup. But I was hungry and tired and wanted to get it done and get home and watch the fireworks.

-Dave

[Rath_]

Edit: you probably asked about https://lightning.network/lightning-network-paper.pdf point "8.1 Decrementing Timelocks" in LN whitepaper version 0.5.9.2.

In the event a party outright disconnects, the counterparty will be responsible for broadcasting the current Commitment Transaction state in the channel to the blockchain.  Only the failed non-responsive channel state gets closed out on the blockchain, all other channels should continue to update their Commitment Transactions via novation inside the channel.

By the way, it is not cost-effective at all times. Assuming that it is a one-time thing, I would rather eat the loss than pay extra for an uncooperative channel close. Apparently, c-lightning will be taking that into account soon.

Also, if anyone is wondering how to open multiple channels in a single transaction (c-lightning), here's a command that I used a few moments ago.

lightning-cli multifundchannel -k destinations='[{"id": "03cde60a6323f7122d5178255766e38114b4722ede08f7c9e0c5df9b912cc201d6", "amount": 5000000}, {"id": "037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba", "amount" :1000000}]' feerate=1000perkb minchannels=2

I managed to get the node back up and broadcast the close channels.

Weren't you going to move your c-lightning node and keep it running?

[DaveF]

Weren't you going to move your c-lightning node and keep it running?

Yes I was going to keep both running a lnd based node in a box and a c-lightning regular build, both VMs. The machine I put them I thought had 16GB of ram so I could run 2 VMs and still have plenty to spare. But it only had 8 so I was running both with just 3GB of RAM. So I was just going to shut it down, pull out the 2 4GB sticks and put in 2 16GB sticks. Also add a 2nd 2 TB  so I could mirror the drive. Had issues and going back to tired / hungry instead of going though stuff slowly I decided to just to a bunch of things at once. (Flash BIOS / different ram / pull 2nd drive) Things went downhill from there. Nothing of which should have caused the issues, but both VMs became unstable.

And the last backup I had done was last week when I moved them to the new box. So no help there. Will wipe everything and start again.

-Dave

[ndalliard]

awesome faq, was a pleasure to read

Is Lightning Network centralized? Is it more centralized than Bitcoin? Does it make Bitcoin more centralized?

This topic has been brought up many times. The Lightning Network is a second layer scaling solution which has no impact on the Bitcoin network. It works independently and no one is forced to use it.

the wording here is a little bit off imo. i guess you are not talking about the lightning technology used on another network than bitcoin. that means the lightning network it is clearly dependent on the bitcoin network and also i would say, that both networks have an impact on each other. i agree with the last part, that no one is force to use neither networks (some say people in el salvador are now force to use it, but that is another topic)

only read the first post for now, sorry if this already came up, will catch up soon

[Wind_FURY]

awesome faq, was a pleasure to read

Is Lightning Network centralized? Is it more centralized than Bitcoin? Does it make Bitcoin more centralized?

This topic has been brought up many times. The Lightning Network is a second layer scaling solution which has no impact on the Bitcoin network. It works independently and no one is forced to use it.

the wording here is a little bit off imo. i guess you are not talking about the lightning technology used on another network than bitcoin.

You guessed right, ser. Those altcoin “Lightning Networks” are their developers implementing it for themselves, probably truly as a computer science experiment/test, but to some of them, probably just for riding the bandwagon.

that means the lightning network it is clearly dependent on the bitcoin network and also i would say, that both networks have an impact on each other. i agree with the last part, that no one is force to use neither networks (some say people in el salvador are now force to use it, but that is another topic)

Lightning is an “off-chain” layer and doesn’t impact the Bitcoin blockchain/the base layer.

[ndalliard]

that means the lightning network it is clearly dependent on the bitcoin network and also i would say, that both networks have an impact on each other. i agree with the last part, that no one is force to use neither networks (some say people in el salvador are now force to use it, but that is another topic)

Lightning is an “off-chain” layer and doesn’t impact the Bitcoin blockchain/the base layer.

just because it is called "off-chain" doesn't mean it doesn't impact bitcoin the base layer, if you think about it, you have to do at least two transactions for every channel (okay maybe one if you count channels you will "never" close), but my point is: it impacts the base layer, cause lightning needs a base layer and using it means that there is an impact / influence, whatever you want to call it - or are we takling about two different things here?

[Rath_]

the wording here is a little bit off imo. i guess you are not talking about the lightning technology used on another network than bitcoin. that means the lightning network it is clearly dependent on the bitcoin network and also i would say, that both networks have an impact on each other. i agree with the last part, that no one is force to use neither networks (some say people in el salvador are now force to use it, but that is another topic)

I get your point. I should mention that there is a possible risk of flooding the network if a large number of channels is closed at once. Uncooperative channel close results in 2 on-chain transactions, so that's how someone could do even more damage.

A few moments ago, I answered ndalliard's question about timelocks in the commitment transactions. I ended up explaining in detail how uncooperative channel close is performed. Some of you might find it interesting.

is the period of that timelock every time a new commitment is broadcastet updated? so it is a moving timeframe? and that timeframe will be set in stone with the opening transaction on the base layer, is that correct?

I might have phrased that slightly wrong, so let me explain it in more detail. If you are closing a channel uncooperatively, there are actually two on-chain transactions involved instead of just one.

First of all, the timelock is decided before the channel is established. By default, most nodes force the other peer to wait 144 blocks (~1 day). The maximum acceptable value by default is 2016 blocks (~2 weeks). I configured my node to create channels with their_to_self_delay = 432 blocks (~3 days), so if someone decides to close the channel opened to my node uncooperatively, they will have to wait 432 blocks (after the commitment transaction has been included in a block) before they can spend the output belonging to them. Those timelocks are relative which means that you do not have to sign a new commitment transaction whenever a new block is mined. New commitment transactions are signed periodically because their fees need to match the current state of the mempool. There is no point in paying 60 sat/vbyte when 1 sat/vbyte transactions are getting confirmed in just a few minutes. It also applies the other way around.

The first transaction is the commitment transaction. Let's say there's node A(lice) and node B(ob), and node A broadcasts the commitment transaction. That commitment transaction includes two outputs:

- output #0: 3 BTC (spendable by node B's private key) - reflecting node B balance
- output #1: 6 BTC (RSMC) - reflecting node A balance

There is one more important detail before we go any further. Whenever a new commitment transaction is signed, both parties exchange revocation keys for the previous commitment transaction so that they can both be sure that the other party is very unlikely to broadcast an old state of the channel.

RSMC is short for Revocable Sequence Maturing Contract. Such an output contains a relative timelock. This means that you can't spend this output until a certain amount of blocks have been mined since the transaction which includes that output was mined.

Let's say node B didn't change the default value of 144 blocks and the commitment transaction has been confirmed. There are two possible scenarios.

1) Node A attempts to cheat and broadcast an old commitment transaction. Node B has 144 blocks to spend the RSMC output using his and node A's revocation key which he got while they were working on a new commitment transaction.

2) Node A broadcasts the latest commitment transaction. In such a case, node B never got node A's revocation key for that commitment transaction, so he cannot spend that RSMC. Node A can broadcast another transaction spending that output after 144 blocks have been mined.

I know it sounds complicated. I am working on a thread which will explain it in a more understandable way.

[ndalliard]

the wording here is a little bit off imo. i guess you are not talking about the lightning technology used on another network than bitcoin. that means the lightning network it is clearly dependent on the bitcoin network and also i would say, that both networks have an impact on each other. i agree with the last part, that no one is force to use neither networks (some say people in el salvador are now force to use it, but that is another topic)

I get your point. I should mention that there is a possible risk of flooding the network if a large number of channels is closed at once. Uncooperative channel close results in 2 on-chain transactions, so that's how someone could do even more damage.

yes i think changing that would be a good idea - lightning is intertwined with bitcoin

[Wind_FURY]

that means the lightning network it is clearly dependent on the bitcoin network and also i would say, that both networks have an impact on each other. i agree with the last part, that no one is force to use neither networks (some say people in el salvador are now force to use it, but that is another topic)

Lightning is an “off-chain” layer and doesn’t impact the Bitcoin blockchain/the base layer.

just because it is called "off-chain" doesn't mean it doesn't impact bitcoin the base layer, if you think about it, you have to do at least two transactions for every channel (okay maybe one if you count channels you will "never" close), but my point is: it impacts the base layer, cause lightning needs a base layer and using it means that there is an impact / influence, whatever you want to call it - or are we takling about two different things here?

In that regard, then yes, it does have an “impact”, but I believe “impact” might be too powerful of a term to use. When you posted “impact”, I thought you believed that Lightning would truly have a strong influence on the consensus layer.

[ABCbits]

Is Lightning Network centralized? Is it more centralized than Bitcoin? Does it make Bitcoin more centralized?

This topic has been brought up many times. The Lightning Network is a second layer scaling solution which has no impact on the Bitcoin network. It works independently and no one is forced to use it.

the wording here is a little bit off imo. i guess you are not talking about the lightning technology used on another network than bitcoin.

You guessed right, ser. Those altcoin “Lightning Networks” are their developers implementing it for themselves, probably truly as a computer science experiment/test, but to some of them, probably just for riding the bandwagon.

Don't forget there are actual usage such as atomic swap (cryptocurrency exchange).

When you posted “impact”, I thought you believed that Lightning would truly have a strong influence on the consensus layer.

Although it's not strong, few Bitcoin soft fork (such as SegWit which fix transaction malleability and CSV which used on LN's HTLC) benefit LN development.

[Rath_]

I am pleased to announce that I and ndalliard are (probably) the first bitcointalk members to open a dual-funded channel

We both compiled the latest master branch of c-lightning and added "experimental-dual-fund" to our config files. ndalliard was the founder, so I had to configure the funder policy plugin which is not documented well, yet. My funder policy currently looks as follows.

Code:

lightning-cli funderupdate
{
   "summary": "fixed (750000sat)",
   "policy": "fixed",
   "policy_mod": 750000,
   "min_their_funding": "500000000msat",
   "max_their_funding": "4294967295000msat",
   "per_channel_min": "500000000msat",
   "per_channel_max": "4294967295000msat",
   "reserve_tank": "0msat",
   "fuzz_percent": 0,
   "fund_probability": 100
}

In short, my node contributes 750k satoshis to every incoming channel (as long as I have enough funds in the wallet and the founder supports dual-funding) if that channel is bigger than 500k satoshis. I will keep my contribution at zero for most of the time. If someone running c-lightning wants to open a channel with me, let me know in advance so that I can change it back and help you with setting-up dual-funding. It might become easier in the upcoming v0.10.1 update.

[ndalliard]

I am pleased to announce that I and ndalliard are (probably) the first bitcointalk members to open a dual-funded channel

it was basically:

1. adding a string to the config
2. restarting the node
3. entering two commands (now that i think about it, maybe the first command wouldn't be necessary if my node would be "older"/ better connected)

so easy - everyone can do it? probably not, but the experience was pleasant. now comes the harder part on my end. i want to understand what i did there. i did it this time without understand because we wanted to use the nearly empty mempool to save some precious sats

[Carlton Banks]

I am pleased to announce that I and ndalliard are (probably) the first bitcointalk members to open a dual-funded channel

but onrampsincomingliquiditycustodialwalletchannelbalancinghubslightningbankcentral ization

I am pleased to announce that I and ndalliard are (probably) the first bitcointalk members to open a dual-funded channel

no, waaait a second. That means you created a balanced channel as the transaction to open it, and that this kind of channel could be the default for a node manager searching for channel partners...

[Rath_]

3. entering two commands (now that i think about it, maybe the first command wouldn't be necessary if my node would be "older"/ better connected)

Just for clarify, the first command was lightning-cli connect and the other one lightning-cli fundchannel. You cannot fund a channel unless you manually connect to the person you want to open a channel with.

By the way, if both peers support dual-funding, they can also use RBF to bump the fee of the opening transaction.

but onrampsincomingliquiditycustodialwalletchannelbalancinghubslightningbankcentral ization

Thanks, you made my day!

[ndalliard]

3. entering two commands (now that i think about it, maybe the first command wouldn't be necessary if my node would be "older"/ better connected)

Just for clarify, the first command was lightning-cli connect and the other one lightning-cli fundchannel. You cannot fund a channel unless you manually connect to the person you want to open a channel with.

i read about "auto-connection in the manpage. i guess you could get away with only the lightning-cli fundchannel command:

DESCRIPTION
       The fundchannel RPC command opens a payment channel with a peer by
       committing a funding transaction to the blockchain as defined in BOLT
       #2.  If not already connected, fundchannel will automatically attempt
       to connect if C-lightning knows a way to contact the node (either from
       normal gossip, or from a previous connect call).  This auto-connection
       can fail if C-lightning does not know how to contact the target node;
       see lightning-connect(7).  Once the transaction is confirmed, normal
       channel operations may begin. Readiness is indicated by listpeers
       reporting a state of CHANNELD_NORMAL for the channel.

[darkv0rt3x]

3. entering two commands (now that i think about it, maybe the first command wouldn't be necessary if my node would be "older"/ better connected)

Just for clarify, the first command was lightning-cli connect and the other one lightning-cli fundchannel. You cannot fund a channel unless you manually connect to the person you want to open a channel with.

i read about "auto-connection in the manpage. i guess you could get away with only the lightning-cli fundchannel command:

DESCRIPTION
       The fundchannel RPC command opens a payment channel with a peer by
       committing a funding transaction to the blockchain as defined in BOLT
       #2.  If not already connected, fundchannel will automatically attempt
       to connect if C-lightning knows a way to contact the node (either from
       normal gossip, or from a previous connect call).  This auto-connection
       can fail if C-lightning does not know how to contact the target node;
       see lightning-connect(7).  Once the transaction is confirmed, normal
       channel operations may begin. Readiness is indicated by listpeers
       reporting a state of CHANNELD_NORMAL for the channel.

Yeah, I was also talking about that with _Rath. I think I have used fundchannel in the past without using connect before!
Another dual-funded channel here!

[ndalliard]

Yeah, I was also talking about that with _Rath. I think I have used fundchannel in the past without using connect before!
Another dual-funded channel here!

nice one - do you run by any chance behind tor and could try to connect to my node?

Code:

lightning-cli connect 025b5150c66f3ea41367829f6e4639c772fe4c7939b71933802233493e6e972a8e

that would be really helpful

ps: another reason for our own lightning network subforum - i need a support thread 

[Rath_]

nice one - do you run by any chance behind tor and could try to connect to my node?

Code:

lightning-cli connect 025b5150c66f3ea41367829f6e4639c772fe4c7939b71933802233493e6e972a8e

Yesterday, I asked darkv0rt3x to try connecting to your node and it worked.

Another dual-funded channel here!

As you can all see, it's not that difficult. Who will be the third bitcointalk member to open a dual-funded channel with me?

If any of you were thinking about setting up a Lightning node, now might be the right time. Transaction fees have been extremely low for the past few days.