入門
Payment Hash 支付哈希
了解閃電網路支付的核心機制：支付哈希與原像，以及它們如何實現安全的跨通道支付。
8 分鐘
什麼是支付哈希？
支付哈希（Payment Hash）是閃電網路支付的核心識別符。 它是一個 256 位的哈希值，由接收者生成，用於鎖定支付。 只有知道對應原像（Preimage）的人才能領取這筆支付。
核心原理： Payment Hash = SHA256(Preimage)。 接收者保密原像，公開哈希值。支付成功時揭露原像。
哈希與原像
Payment Hash Generation Receiver (Bob): 1. Generate random 32-byte preimage preimage = random_bytes(32) Example: 0x1234567890abcdef... (32 bytes) 2. Calculate SHA256 hash payment_hash = SHA256(preimage) Example: 0xabcdef1234567890... (32 bytes) 3. Keep preimage secret, publish hash • Preimage: Only Bob knows • Hash: Included in invoice, sent to Alice Sender (Alice): 1. Receives invoice containing payment_hash 2. Cannot reverse hash to get preimage (one-way function) 3. Uses payment_hash to build HTLC 4. Sends payment
支付流程
Payment Flow Using Payment Hash
Alice ----------------------------------------> Bob
Carol (intermediate node)
Step 1: Bob Creates Invoice
Bob generates:
preimage = 0x11223344... (secret)
payment_hash = SHA256(preimage) = 0xaabbccdd...
Invoice content:
lnbc10u1p... (contains payment_hash)
| Invoice sent to Alice
v
Step 2: Alice Sends Payment
Alice -> Carol:
HTLC: If you can provide preimage of H, I'll give you 10,000 sats
H = 0xaabbccdd...
Carol -> Bob:
HTLC: If you can provide preimage of H, I'll give you 9,990 sats
H = 0xaabbccdd... (same hash)
| Bob knows the preimage
v
Step 3: Bob Claims Payment
Bob -> Carol:
Reveals preimage = 0x11223344...
Carol verifies: SHA256(0x11223344...) = 0xaabbccdd... OK
Carol pays Bob
Carol -> Alice:
Reveals preimage = 0x11223344... (same preimage)
Alice verifies: SHA256(0x11223344...) = 0xaabbccdd... OK
Alice pays Carol 安全特性
原子性
所有 HTLC 使用相同的 payment_hash，原像揭露後所有通道同時結算， 確保支付要麼全部成功，要麼全部失敗。
不可偽造
SHA256 的抗碰撞性確保無法偽造有效的原像。 只有接收者（生成原像的人）才能領取支付。
支付證明
原像作為支付證明。發送者收到原像就證明接收者已收到款項， 這在商業場景中非常重要。
隱私性
中間節點只看到哈希值，無法得知支付的具體內容或目的。 原像只在最後揭露。
發票中的支付哈希
BOLT 11 Invoice Structure lnbc10u1pj9... Decoded: • Amount: 10 microbitcoin (1,000 satoshis) • Timestamp: 1234567890 • payment_hash: 0xabcdef1234567890abcdef1234567890 abcdef1234567890abcdef1234567890 • Description: Coffee payment • Expiry time: 3600 seconds • Signature: ... payment_secret (BOLT 11 Extension): Problem: Intermediate nodes can probe if payment reaches destination Solution: payment_secret • Another 32-byte random value • Passed to final receiver via onion routing • Receiver verifies payment_secret • Intermediate nodes cannot obtain this value
原像的用途
Multiple Uses of Preimage 1. Proof of Payment • Sender saves preimage as receipt • Can prove payment was received • Used for dispute resolution 2. Conditional Payments (Hold Invoices) • Receiver delays revealing preimage • Waits for certain conditions to be met • Implements escrow-style payments 3. Atomic Swaps • Cross-chain atomic swaps use same mechanism • Ensures both transactions complete simultaneously • Submarine Swaps based on this principle 4. Cryptographic Commitments • Preimage can encode arbitrary data • Revealing preimage = revealing commitment • Enables various smart contract functions Example: Using Preimage as Key Scenario: Payment unlocks digital content 1. Merchant encrypts content with preimage encrypted = AES(content, preimage) 2. Sends encrypted content to buyer 3. Buyer pays invoice 4. After payment succeeds, buyer obtains preimage content = AES_decrypt(encrypted, preimage)
Keysend 與自生成原像
Keysend (Spontaneous Payment) Traditional payment: Receiver generates preimage Keysend: Sender generates preimage Flow: 1. Alice generates preimage 2. Alice calculates payment_hash = SHA256(preimage) 3. Alice builds HTLC chain 4. Alice encrypts and passes preimage to Bob via onion 5. Bob obtains preimage from onion 6. Bob uses preimage to claim payment TLV Passing Preimage: Onion payload contains: keysend_preimage (TLV type 5482373484) -> 32 bytes preimage Advantages: • No invoice needed • Suitable for tips, donations • Supports streaming payments Disadvantages: • No amount verification • Receiver may not expect it • No payment description
重要提示： 原像應該只使用一次。重複使用同一個原像可能導致支付被重複領取或產生隱私問題。 每筆支付都應該生成新的原像。
相關資源
下一步： 了解 時間鎖 如何保護支付安全。
已複製連結