Topic: The Lightning Network FAQ - page 26. (Read 33287 times)

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.


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


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).


Sounds good.


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.

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?

What's an unsettled payment?

What's HTLC-timeout transaction?

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?

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.

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?

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.

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://bitcointalksearch.org/topic/m.58210913

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


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.


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.

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. 

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

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.

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

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.
 

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.

Tried, got this

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

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?

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

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?

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

I still barely try to understand how LN works, so If I'm wrong I hope someone corrects it.

It is simply because a brand new node needs to discover and establish a peer connection. I'm sure that your node gets those URIs from the DNS seed server, the node is trying to establish to any peer that the DNS server returned. I think why the connection get failed is because the DNS server is still keeping an inactive node.

Reference: BOLT #10: DNS Bootstrap and Assisted Node Location


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

Here is my URI:

Why would it do that? It doesn't do this only with clearnet, but on onion URIs too. Check the log above;

Yes. As I said, Raspibolt.

I restarted it.

Would it show you something in your log? If that's so, give me your URI.

Edit: Just saw your signature. Tried to connect. Here's the output:

You can try to connect to mine if you want.