The Lightning Network FAQ

[DaveF]

I restarted it.

There, I'm able to connect to the node.

Code:

$ lncli --rpcserver localhost:20009 connect 0370c1f28b315806fa9e7fc2616715a5052401fcbeff89e83d3810f1f9683b9a37@3thm3rotf4bhgppcfsyh7ihcdzany7ozew7kyxnjw5ozfq6mxn3afuad.onion:9735
{

}
$ lncli listpeers
{
            "pub_key": "0370c1f28b315806fa9e7fc2616715a5052401fcbeff89e83d3810f1f9683b9a37",
            "address": "3thm3rotf4bhgppcfsyh7ihcdzany7ozew7kyxnjw5ozfq6mxn3afuad.onion:9735",

Here is my URI:

Code:

02edda84bcaae1b32da8de236329e4c9572a00ec99e56f9f7f72811b1cfa2025e4@zrqoqad3aeqzzma5ce7pyc5fftmvem2qsleeay36gujnim5scuuixeqd.onion:9735

As could I. Good advice on the restart, I didn't even think of it. Sometimes the simple things work best.
@BlackHatCoiner di you want me (or any of us) to open a channels or are you still working on it? If you do any preference on amount?

-Dave

[1714227868]

1714227868

[1714227868]

1714227868

[1714227868]

1714227868

[BlackHatCoiner]

@BlackHatCoiner di you want me (or any of us) to open a channels or are you still working on it?

I want to open a channel, but it still says that I haven't synced with the chain. Anyway, you have to give me a lninvoice, right?

[DaveF]

@BlackHatCoiner di you want me (or any of us) to open a channels or are you still working on it?

I want to open a channel, but it still says that I haven't synced with the chain. Anyway, you have to give me a lninvoice, right?

No, if you have funds in your attached BTC wallet all I have to do is open a channel on my side and your node should just go and open it.
The that's why I asked if you wanted me to because:
1) I don't know if you have funds in there or if you do how much
and / or
2) If you wanted to do something else with the funds.

Lets say you have .0005 (~$30) sitting in there to test something this week then me opening a channel for .00041 (~$25) means you have to then close it before you do something else.

-Dave

[BlackHatCoiner]

I had deposited 500,000 sats few days ago. So, open it if you want. Do I have to give any permissions or you can just do it by having my URI?

[DaveF]

I had deposited 500,000 sats few days ago. So, open it if you want. Do I have to give any permissions or you can just do it by having my URI?

Tried, got this

received funding error from 0370c1f28b315806fa9e7fc2616715a5052401fcbeff89e83d3810f1f9683b9a37: chan_id=3355a3cbcc67496593849c6e487cec54c9ef6037ef304cddf18c2460411bb8fc, err=Synchronizing blockchain

So something may not be right on your side. As far as connecting a peer should not happen when your node is out of sync or at least thinks it's out of sync.
Just did a test one of my nodes was off since mid week and when I restarted it and tried to connect it failed.

Going to back off here since I really have no idea and don't want to give you bad / wrong advice.
You can always hop off to github and ask them.

-Dave

[BlackHatCoiner]

Setting aside the connection of my node, I want to clear up some things first.

I'm trying to understand the technical background of the penalty mechanism and need some answers to continue my study further. First off, I'll write what I've understood so far. The juicy part of the lightning network is this IMO. How can you discourage someone from publishing an older state of the channel. Lightning must have been an enlightenment for whoever thought of it. I'll take Bob and Alice as my examples.

Let's say the channel starts with Alice having 10 coins and Bob nothing. (Commitment transaction #0)

Alice wants to send 2 coins to Bob. Once she signs the transfer, she has to assure Bob she'll not cheat him in the future. Thus, she provides an evidence that the previous transaction is revoked. So, she has to sign the following:

1) If Bob somehow provides a signature from Alice's revocation key, he can seize all of her coins. Otherwise, Alice can take the 10 coins if she broadcasts the transaction, in which she spends her coins and reveals her revocation key, acquires 432 confirmations.

2) Bob gets 2 coins.

They both exchange signed commitments and revocation keys as they transact. First, Alice sends the above to Bob and Bob agrees. If Bob wants to send 1 coin back, Alice needs to make sure he'll not publish the previous state. So, she tells him to provide her the new commitment transaction signed, so that she gives him the revocation key of the previous state. (The one that if Bob tried to cheat her, she could sign a transaction with and take her 2 coins back)


Am I wrong until here? I'm sure I've said something that's not true.

[Icygreen]

I've opened a channel using Umbrel's GUI and attempted to close it with the same however the funds have not returned to my wallet and the channel status shows closing since Sept 27.  Not sure what to do?  Here it is in Thunderhub.
 

[DaveF]

No txid. I'll post in the thread you've recommended, thanks.

The TXID is in the image you posted. If you look at it on an explorer is it confirmed or is it just sitting in limbo?
If you don't want to give it out for privacy reasons that's fine, but its an important data-point to check.

You just want to start by making sure that something did not go wrong and the transaction was never broadcast.
From the been there done that department.

-Dave

[Icygreen]

No txid. I'll post in the thread you've recommended, thanks.

The TXID is in the image you posted. If you look at it on an explorer is it confirmed or is it just sitting in limbo?
If you don't want to give it out for privacy reasons that's fine, but its an important data-point to check.

You just want to start by making sure that something did not go wrong and the transaction was never broadcast.
From the been there done that department.

-Dave

Sorry, thought you'd meant the closing transaction.  Yes, that one's confirmed in block 700,550. I'm ok posting the details regarding this.

Code:

e884d01dcf0c31ffcfbf6e0dcfb8fd35c199a2ec5219bd0a0dee962636d2eeed

[DaveF]

No txid. I'll post in the thread you've recommended, thanks.

The TXID is in the image you posted. If you look at it on an explorer is it confirmed or is it just sitting in limbo?
If you don't want to give it out for privacy reasons that's fine, but its an important data-point to check.

You just want to start by making sure that something did not go wrong and the transaction was never broadcast.
From the been there done that department.

-Dave

Sorry, thought you'd meant the closing transaction.  Yes, that one's confirmed in block 700,550. I'm ok posting the details regarding this.

Code:

e884d01dcf0c31ffcfbf6e0dcfb8fd35c199a2ec5219bd0a0dee962636d2eeed

Yeah, just trying to follow step by step. In theory it's 100% impossible for your node to open a channel and show it open without a valid TX.
In reality, it's still a bit more beta at times so if you spend time on the lnd github you can see some really oddball things crop up now and then.

I am on mobile at the moment, was there ever any routing through this channel?

Have you restarted LND? That actually fixed BlackHatCoiners unrelated problem above, but you never know.

-Dave

[Icygreen]

I don't believe this channel has routed any transactions. Couldn't find a way to reboot lightning independently so I've rebooted the Umbrel, not sure if this is the same. Also tried reloading the channel backup. No changes. 

[Rath_]

Am I wrong until here? I'm sure I've said something that's not true.

I explained an uncooperative channel close in this post. I think that you should read it before reading my reply further.

Otherwise, Alice can take the 10 coins if she broadcasts the transaction, in which she spends her coins and reveals her revocation key, acquires 432 confirmations.

An uncooperative channel close always involves at least two transactions. The first one is the commitment transaction and the other one spends the RSMC output. There might be more transactions; two for each in-flight HTLC.

Things get a little bit complicated when we are talking about unsettled payments. Bob asks Alice to sign a commitment transaction with the following outputs:

- a standard output; 8 BTC to Alice's address
- HTLC; 2 BTC that can be spent on the following conditions: Bob can spend this output using the payment preimage and HTLC signatures (HTLC-success transaction); Otherwise Alice can spend this output using revocations keys or HTLC-timeout transaction.

Note that this is what Bob's commitment transaction looks like. Alice's transaction looks like this:

- RSMC; 8 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Alice can spend these coins; otherwise Bob can use his and Alice's revocation key to unlock this output.
- HTLC; 2 BTC that can be spent on the following conditions: Bob can spend this output using the payment preimage and HTLC signatures (HTLC-success transaction) or using the revocation keys; otherwise Alice can spend it through the HTLC-timeout transaction.

Note: The HTLC-timeout transaction contains an absolute timelock (cltv_expiry) to give the other party time to claim the funds with the payment sercet. The outputs of HTLC-success and HTLC-timeout transactions contain another locking script with the same relative timelock as the RSMC output (to_self_delay).

Once all of the in-flight payments are settled, the final commitment transactions look like this:

Bob's commitment transaction:

- a standard output; 8 BTC to Alice's address
- RSMC; 2 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Bob can spend these coins; otherwise Alice can use hers and Bob's revocation key to unlock this output.

Alice's commitment transaction:

- a standard output; 2 BTC to Bob's address
- RSMC; 8 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Alice can spend these coins; otherwise Bob can use his and Alice's revocation key to unlock this output.

If Bob wants to send 1 coin back, Alice needs to make sure he'll not publish the previous state. So, she tells him to provide her the new commitment transaction signed, so that she gives him the revocation key of the previous state. (The one that if Bob tried to cheat her, she could sign a transaction with and take her 2 coins back)

Alice constructs a new commitment transaction and asks Bob to sign it. Bob signs Alice's commitment transaction. Then, Bob creates his own version of the latest commitment transaction and asks Alice to sign it and revoke her previous commitment transaction. Once Alice signs Bob's transaction, he can safely hand her over his revocation key for the previous transaction.

[Shymaa-Arafat]

Since u r like the official post about lightning, may I ask about the law regulations if one of the two is required to freeze his/her money for some time?
I mean do they use experts and allow him/her to spend the UTXO (say into another one to be freezed) before the time lock ends and the other party use the revocation key to spend it?
I wrote a post asking, but don't know where it has gone

Aha
It was moved to legal
https://bitcointalk.org/index.php?topic=5366309.msg58210913#msg58210913

[Rath_]

I mean do they use experts and allow him/her to spend the UTXO (say into another one to be freezed) before the time lock ends and the other party use the revocation key to spend it?

You seem to be slightly confused about how the Lightning Network works. Timelocks that are used in commitment transactions are relative (except for the HTLC outputs which also contain an absolute timelock but that's a rare case) which means that they are safe to use for an indefinite amount of time. Despite that, commitment transactions are resigned periodically, even if there isn't any activity in the channel, to update the on-chain fees based on the current mempool state.

Revocation keys can be used only if the other party publishes an old commitment transaction which had been revoked. If the latest commitment transaction is published, the transaction immediately refunds the other party their coins and the person who published the transaction has to wait a specific amount of time (144 blocks by default) before they can spend their output to themself in another transaction. Commitment transactions should not be used if both parties are online and willing to cooperate. They can agree to close the channel at any time without any delay.

I will take a look at your thread later today.

[Shymaa-Arafat]

Do u mean lock time is usually 144 block~= 1 day, so it's a very rare situation that someone participate in a channel and just happen to get a court order against him in that exact same day before he/she spends the coins?

[BlackHatCoiner]

- RSMC; 8 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Alice can spend these coins; otherwise Bob can use his and Alice's revocation key to unlock this output.

What's the relation between Bob's revocation key and Alice's revocation key? You say that Bob can rip Alice off if he somehow gain access to her revocation key. What did Alice sign when she gave the signed commitment transaction to Bob? I think that's the hard part to understand. Is there some sort of public-key cryptography involved in the ack_and_revoke?

Bob shouldn't publish the first transaction in which he owns the entire 10 BTC, because Alice knows that commitment transaction's revocation key and can gain the RSMC output before the HTLC spending receives 144 confirmations?

Things get a little bit complicated when we are talking about unsettled payments.

What's an unsettled payment?

Otherwise Alice can spend this output using revocations keys or HTLC-timeout transaction.

What's HTLC-timeout transaction?

Note: The HTLC-timeout transaction contains an absolute timelock (cltv_expiry) to give the other party time to claim the funds with the payment sercet. The outputs of HTLC-success and HTLC-timeout transactions contain another locking script with the same relative timelock as the RSMC output (to_self_delay).

So, to simplify; there are two ways to timelock. One is to sign after which block a transaction is considered valid and the other a specific amount of blocks that need to be mined after it's included in a block for its outputs to be spendable.

Is that correct?

- RSMC; 2 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Bob can spend these coins; otherwise Alice can use hers and Bob's revocation key to unlock this output.

In case I've forgotten to mention it above, assuming Bob tries to cheat Alice:  What's the relation between his and hers revocation keys so that if one of them has both, they can unlock the output?


Sorry if I've been tiring in this thread. I just have this symptom where I HAVE to understand every detail of the system that I'm using. You've used some terms that are unknown to me, but, hopefully, they won't be.

[Rath_]

Bob shouldn't publish the first transaction in which he owns the entire 10 BTC, because Alice knows that commitment transaction's revocation key and can gain the RSMC output before the HTLC spending receives 144 confirmations?

It's actually Alice who owned 10 BTC at the beginning but you get the idea. The first commitment transaction contains only one (RSMC) output. If Alice published it and it got confirmed, Bob could safely publish a penalty transaction within 144 blocks. I am not sure why you mentioned the HTLC here.

What's an unsettled payment?

An unsettled payment is an HTLC which still hasn't been claimed using a payment preimage.

What's HTLC-timeout transaction?

HTLC-timeout transaction is a transaction which allows the person who offered the HTLC to claim it back once the absolute timelock expires. We need HTLC-success/HTLC-timeout transactions to handle the dispute if something goes wrong while a payment is being routed (see "Broken channel" section of this article).

So, to simplify; there are two ways to timelock. One is to sign after which block a transaction is considered valid and the other a specific amount of blocks that need to be mined after it's included in a block for its outputs to be spendable.

Sounds good.

Sorry if I've been tiring in this thread. I just have this symptom where I HAVE to understand every detail of the system that I'm using. You've used some terms that are unknown to me, but, hopefully, they won't be.

No worries. Feel free to ask more questions or let me know if something is still not clear. It's a little bit late here so I will answer the question about revocation keys tomorrow.

[BlackHatCoiner]

If Alice published it and it got confirmed, Bob could safely publish a penalty transaction within 144 blocks.

But, it wouldn't be (acknowledged and) revoked. How would Bob have gained access to the very first commitment transaction's revocation key? Don't they both publish penalties only if the transaction they're publishing is not the newest commitment transaction (that hasn't been revoked yet)?

I am not sure why you mentioned the HTLC here.

Because I've probably confused its meaning. Isn't HTLC a hashed timelock contract? Doesn't that mean that it's an “agreement”? A condition where both exchange commitment transactions?

No worries. Feel free to ask more questions or let me know if something is still not clear. It's a little bit late here so I will answer the question about revocation keys tomorrow.

I think the way revocation keys work is the only serious thing left for me. I'm reading the lnbook of Andreas Antonopoulos, Olaoluwa Osuntokun and Rene Pickhardt, which is perfect for newbies in this field like me. 

I haven't fully acknowledged the way they work so I said why not asking my questions here?

[Rath_]

Sorry for a late reply. I have been slightly busy lately.

What's the relation between Bob's revocation key and Alice's revocation key? [...] Is there some sort of public-key cryptography involved in the ack_and_revoke?

This explanation should help you understand it. Here you can find the formulas which are used to calculate revocation public and private keys

revoke_and_ack message looks like this:

Code: (https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#completing-the-transition-to-the-updated-state-revoke_and_ack)

    type: 133 (revoke_and_ack)
    data:
        [channel_id:channel_id]
        [32*byte:per_commitment_secret]
        [point:next_per_commitment_point]

Your node must provide per_commitment_secret associated with the next_per_commitment_point which you sent previously in either funding_locked or revoke_and ack message.

Because I've probably confused its meaning. Isn't HTLC a hashed timelock contract? Doesn't that mean that it's an “agreement”? A condition where both exchange commitment transactions?

An HTLC is basically an additional output of a commitment transaction with a specific locking script. If an HTLC is below the dust limit then it is added to the transaction fee (only when the payment has not been settled yet). There is no real incentive for the other party to cheat in this particular case. If you are not comfortable with that, you can always refuse to route payments below the dust limit.

I am still not sure why you mentioned it. If Alice broadcast the first commitment transaction (the one which refunds her 10 BTC), Bob could simply publish a penalty transaction because Alice revealed the secret needed to derive the revocation key for her outdated commitment.

It wouldn't make sense for Bob to broadcast the second commitment transaction if Alice broadcast the first one because: A) It would be rejected by most nodes due to double-spend B) It would probably be more expensive

But, it wouldn't be (acknowledged and) revoked. How would Bob have gained access to the very first commitment transaction's revocation key? Don't they both publish penalties only if the transaction they're publishing is not the newest commitment transaction (that hasn't been revoked yet)?

You're right. I assumed that they managed to sign the second commitment transaction successfully. If we assume that they failed to sign it, there is no need to worry about that HTLC. If Alice refuses to revoke her previous commitment and sign Bob's new transaction, Bob should not reveal the payment preimage needed to claim that HTLC.

[cygan]

wanted to share with everyone here another interesting article about the lightning network, which was published today by the Kraken exchange

The Lightning Network is a scalability solution built on top of #Bitcoin.

Read our article to learn about:
Benefits of the Lightning Network
History of the network
How Lightning Network works

https://www.kraken.com/learn/lightning-network