為什麼多跳 LN 付款從收款人端開始結算？
在 HTLC 中，在所有各方都將他們的資金鎖定在合約中之後，要求支付以相反的方式發生，從顯示相應支付雜湊的原像的接收者開始。
**如果它從發件人開始會有什麼問題？**接收方確認收到契約後，向發送方發送確認。發送者釋放原像，時間鎖在整個路徑中按遞增順序設置，由發送者發起的合約具有最少的鎖定時間。接收方是結算付款的最後一個節點。
作為參考，我添加了一張圖片，以便人們可以想像我想說的話。
在 HTLC 中，在所有各方都將他們的資金鎖定在合約中之後，要求支付以相反的方式發生，從顯示相應支付雜湊的原像的接收者開始。如果它是從發件人開始的，會有什麼問題？
首先，發送者在技術上沒有什麼可聲稱的，其次，接收者是唯一能夠首先揭示原像的人。
接收方確認收到契約後，向發送方發送確認。發件人發布原像
您的意思是接收者會將原像交給發送者嗎？這增加了更多的互動性（如果不使用閃電網路本身來傳輸資訊）並且還（部分？）放棄了支付證明。
我並沒有想太多，但它也可能會引發很多其他問題，這樣做的理由是什麼？
我想你已經自己回答了你的問題。如果所有節點都誠實和善意地行事，那麼您的流程就會奏效。但在那種情況下，我們不需要從一開始就設置 htlcs，但我們可以通過改變每個渠道的餘額來轉移資金。使用 htlcs 的全部意義在於使支付過程原子化並防止沿途的節點竊取資金。
除此之外，我沒有看到任何其他缺陷。
無關：
查看您最近在郵件列表上的文章（參見：https ://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002718.html ）我想知道“轉發第二個原像”的想法是否另外可以建構“釋放原像”的目前過程以防止惡意攻擊，因為發送者可以強制解決 htlc，以防有人停止該過程。但是按照我現在想像這樣一個解決方案的方式，它基本上會遇到與您在最初問題中已經描述的相同的問題。調查是否可以使用 PTLC（帶有採用者簽名和支付去核）來辨識 griefing 節點並使用這樣的過程可能會很有趣。