you say the commitment then has erics payment_hash(facepalm.. ill explain later issues with this) [...]
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 with his secret
That's why I asked you to check one of my previous posts. There is no point in explaining it again, so I am going to quote myself instead.
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.
For some reason, you refuse to accept the existence of these scripts.
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.
There is no other way to pass the "onion_routing_packet" other than via "update_add_htlc". Any other way wouldn't be specification compliant.
HTLC is actually about the revocation part initially(punishment) in regard to routed or in channel direct payments(partner is destination). though in direct payments becasue your trying to pay bob anyway as the destination there is less need for HTLC
but a HTLC main objective is you 'hope' to prevent partner sending an old commitment. by having a time locked contract with revoke conditions
HTLCs have nothing to do with revocation. Revocations and punishments are handled through timelocks in locking scripts. For example:
OP_IF
# Penalty transaction
<revocationpubkey>
OP_ELSE
`to_self_delay`
OP_CHECKSEQUENCEVERIFY
OP_DROP
<local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG
If Alice broadcasts her commitment transaction, she needs to wait for 'to_self_delay' blocks (144 blocks by default) since her transaction has been mined before she can spend this output.