Quote from: Rath_ on Today at 08:56:37 PM

Quote from: franky1 on Today at 08:18:26 PM

a LNmillisat payment HTLC has units of measure in msat and also uses Erics payment hash for all users (ABCD)

That's correct.

we are agreed. one step forward for you.. finally

Quote from: Rath_ on Today at 08:56:37 PM

Quote from: franky1 on Today at 08:18:26 PM

a commitment HTLC(different) uses only the pubkeys of the channel partners and is measured in sats

A commitment transaction with HTLC outputs uses the public keys of the channel partners, their HTLC public keys and the hash of the payment secret. See the second half of this post again.

we are agreed. two steps forward for you.. finally
but kind of weird how you say the exact same thing as what i said.. but then ask me to check something..
and when i go check. you are referring back to commitments and not the payments..
deduct half a step
rath_you are 1.5 steps forward. but looks like you are beginning to step back again

Quote from: Rath_ on Today at 08:56:37 PM

Quote from: franky1 on Today at 08:18:26 PM

a commitment is an inchannel management thing that occurs after the out of channel payment of routing packets

The specs literally say that one should not forward an HTLC unless one can enforce the contract on-chain.

oh and here you go again. talking about step 4 of the commitment and ignoring the steps 123 of the payment..
deduct 1 whole step

your only one step forward.

Quote from: Rath_ on Today at 08:56:37 PM

Quote from: franky1 on Today at 08:18:26 PM

bolts2 (the thing your addicted to) uses examples of old old protocol where its describing examples of 'hub' payments (where channel partner is the destination)

It's exactly the opposite. Direct payments could work just fine without HTLCs. The main purpose of HTLCs is to enable payment routing.

HTLC is about the revocation part initially(punishment) in regard to in channel direct payments(partner is destination). you know the 'hope' to prevent sending an old commitment paradox.
i wont deduct a step yet, as this is a new argument from you. ill just treat is as naive jump to conclusion before checking.
just try to look into it abit and not just repeat it because you said it before

Quote from: Rath_ on Today at 08:56:37 PM

Quote from: franky1 on Today at 08:18:26 PM

otherwise if alice is trying to pay Eric. if it was alice commiting to bob first. bob could then broadcast his win he never asked for.. and because its the latest commitment(in your scenario fantasy). bob cant be revoked. and so bob gets the win. eric doesnt get paid and alice is out of money.

franky1, come on. You seem to completely ignore the fact that TWO commitment transactions are signed for each Lightning payment. The first transaction is supposed to prevent the situation you described from happening. The transaction contains additional (HTLC) outputs with locking scripts which I described in the other half of this post.

Bob has no real reason to broadcast his commitment transaction with HTLC outputs unless Carol claims his HTLC and Alice stops cooperating, and refuses to sign another commitment transaction without the HTLC output.

The second commitment transaction is signed once Bob sends "update_fulfill_htlc", which includes the payment preimage, to Alice. It's the transaction you have been talking about all the time.

i know you want to concentrate and saturate this topic with endless post just talking about the commitment and ignoring the millsat payments.. yea your game is obvious. and getting boring..

your post you refer to is ignoring the LN payments that involve the payment_hash provided by eric and used throughout the route.
instead you want to only discuss the commitments of channel management
..
here is the thing..
when alice gets payment_hash from eric.
alice has not even told bob how much needs to be routed. because alice might use zoe, yvonne xena.. instead
so how does bob know, well alice chooses to try a route via bob, carol, diana,eric by sending an LNpayment (onion packet msat with erics payment_hash(htlc)) though that path.

alice does not use this (payment)htlc to put into a commitment with bob, because the output is erics key and eric knows the secret, if it were put in, and it was broadcast, eric would see the confirmed utxo to his key and he can then spend that utxo

the commitment is a separate HTLC using the alice bob pubkeys (not the eric payment_hash)

i know you want to use bolt 2 because its example is pretending bob is the destination.
where micropayments are not needed.

but things have moved on.. try reading bolt4 and learn about the other things . like micropayments using the onion packets

it seems you are too eager to pretend that the 'payment' is put into commitment and act as if there is no msat format htlc..
and that story of yours is getting boring