B does not update the A<>B 'commitment'. until after E promise is signed, which then pases to D, which then passes to C, which then passes to B
[...]
(A wont sign a commitment until it receives R(private key))
Alice finds various paths and needs to try them one by one to see if selected nodes have enough liquidity to forward her payment. There is no other way to do that other than to send "update_add_htlc" and sign a new commitment transaction.
Once both nodes have exchanged funding_locked (and optionally announcement_signatures), the channel can be used to make payments via Hashed Time Locked Contracts.
Changes are sent in batches: one or more update_ messages are sent before a commitment_signed message, as in the following diagram:
+-------+ +-------+
| |--(1)---- update_add_htlc ---->| |
| |--(2)---- update_add_htlc ---->| |
| |<-(3)---- update_add_htlc -----| |
| | | |
| |--(4)--- commitment_signed --->| |
| A |<-(5)---- revoke_and_ack ------| B |
| | | |
| |<-(6)--- commitment_signed ----| |
| |--(7)---- revoke_and_ack ----->| |
| | | |
| |--(8)--- commitment_signed --->| |
| |<-(9)---- revoke_and_ack ------| |
+-------+ +-------+
I have already proved that in
this post by showing you my node logs. If the selected node is unable to forward the payment due to no liquidity in the outgoing channel, it sends "update_fail_htlc".
Please, don't bring up "funding_locked" again. It is used only to signal that the funding transaction has reached enough confirmations for the channel to operate safely.
by the way, A,>B do not create a 'commitment' at 2 using H(erics public key) in a commitment. because A<>B know eric has the privatekey(R) and if A or B broadcast a commitment with H, eric can jump in and send funds to where he likes using R.
No, Eric can't do that. HTLC outputs in commitment transactions require not only the payment secret to be spent but also a valid HTLC signature.
When you open a channel, you share your htlc_basepoint, which is a compressed public key used only for HTLC payments in this particular channel. The other node shares their htlc_basepoint as well.
You can use htlc_basepoint and per_commitment_point to calculate local_htlcpubkey and remote_htlcpubkey.
Now, let's take a closer at locking scripts of HTLC outputs. Commitment transactions are asymmetrical which means that there are two possible scenarios:
1) (Offered) HTLC output in Alice's commitment transaction:
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_NOTIF
# To local node via HTLC-timeout transaction (timelocked).
OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node with preimage.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
If remote_htlcpubkey (Bob's HTLC pubkey) is on the stack then the provided secret (the payment preimage) is hashed and checked against the payment hash. Otherwise, this output can be spent via a HTLC-timeout transaction which is timelocked and signed by both parties beforehand.
Eric or any other intermediary node cannot spend this output as they cannot produce a valid signature for that public key.
2) (Received) HTLC output in Bob's commitment transaction:
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# To local node via HTLC-success transaction.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node after timeout.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
If remote_htlcpubkey (Alice's HTLC pubkey) is on the stack then the provided secret (the payment preimage) is hashed and checked against the payment hash and the output can be spent via a HTLC-success transaction.
Again, Eric or any other intermediary node cannot spend this output as they cannot produce valid signatures for these keys.
HTLC-timeout and HTLC-success transactions, which require both Alice's and Bob's HTLC signatures, consume HTLC outputs and create another locked output which is delayed so that the other party has enough time to broadcast a penalty transaction if necessary.