xxxx
remember eric gives alice the payment_hash for the micropayment (millisat promise) with bob (not commitment)
bob uses the payment_hash to carol for his micropayment (millisat promise) with carol (not commitment)
carol uses the payment_hash to diana for her micropayment (millisat promise) with diana (not commitment)
diana uses the payment_hash to eric for her micropayment (millisat promise) with eric (not commitment)
eric then gives diana the payment_secret which she passes to carol who passes to bob who passes to alice
Alice offers Bob an HLTC ("update_add_htlc") and waits for "commitment_signed" which included signatures for the commitment, HTLC-success and HTLC-timeout transactions.
Forwarding HTLCs
Requirements
A node:
until an incoming HTLC has been irrevocably committed:
MUST NOT offer the corresponding outgoing HTLC (update_add_htlc) in response to that incoming HTLC.
Bob won't talk to Charlie unless he signs a new commitment transaction with Alice.
because if you really think there is no ABCDE millisat micropayment temporary promise using H and R. and you think H and R are only used by commitments and only commitments exist. then erics H is going to be in AB's commitment which if AB broadcast such a commitment. then eric can spend the utxo put into his H using his R
thats why LN payments are separate and another reason why they dont get broadcast. aswell as being in a format not understandable to bitcoin network. to prevent eric from scamming alice and bob.
Did you read the other half of my post? Eric also needs two valid HTLC signatures that can be produced only by Alice and Bob.
as for you saying in your post that you explained it already using your node logs
The logs also include commitment related messages.
2021-12-30T02:00:21.308Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating commit_sig signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
2021-12-30T02:00:21.310Z DEBUG hsmd: Client: Received message 20 from client
2021-12-30T02:00:21.310Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Creating HTLC signature [REDACTED] for tx [REDACTED] wscript [REDACTED]
2021-12-30T02:00:21.311Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-chan#85: HTLC in 403 SENT_ADD_REVOCATION->SENT_ADD_ACK_COMMIT
2021-12-30T02:00:21.365Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: Sending commit_sig with 1 htlc sigs
2021-12-30T02:00:21.366Z DEBUG 03562bdcf00fe0cf44e8a491a8c9b26f31c4e45c9a88cdfd6a2f0f2550a304c73e-channeld-chan#85: peer_out WIRE_COMMITMENT_SIGNED
you can tell because it says to add "amount=97653097msat" and we all know a "bitcoin commitment" does not handle msats. so whats being signed. is not a bitcoin commitment but a msat based LN payment
The receiving node routes down the value to whole satoshis before preparing and signing the commitment transaction. The sending node does the same for their version of the commitment transaction.
when talking about payments in LN.. dont confuse the matter by using bolt2 (channel management) and instead use reference from bolt11 (invoice payment)
bolt11 describes how a payment invoice should be encoded/decoded.