วิธีทำงาน

Lightning invoice แบบ BOLT 11 คือคำขอชำระเงินที่กะทัดรัดและ self-contained มันรวมทุกอย่างที่ผู้จ่ายต้องใช้ — จำนวน payment hash ของผู้รับ คำอธิบาย (optional) เครือข่าย และเวลาหมดอายุ — encode เป็น Bech32 string เดียว decoder นี้ unpack string นั้นในเบราว์เซอร์ของคุณโดยใช้ logic การ parse เดียวกับกระเป๋า Lightning ไม่มีการจ่ายเงินเริ่มต้น และไม่มีข้อมูลถูกส่งไปเซิร์ฟเวอร์ใดๆ

โครงสร้าง BOLT 11

ทุก invoice BOLT 11 เริ่มด้วย human-readable part (HRP) ตามด้วยตัวคั่น 1 และส่วนข้อมูลที่ encode ด้วย Bech32 HRP บ่งบอกเครือข่ายและจำนวน:

lnbc — Bitcoin mainnet
lntb — Bitcoin testnet
lnbcrt — Bitcoin regtest (local development)

หลังจาก prefix ของเครือข่ายมี field จำนวน (optional) จำนวนแสดงเป็น Bitcoin พร้อม suffix ตัวคูณ: m (milli, 0.001 BTC), u (micro, 0.000001 BTC), n (nano, 0.000000001 BTC), หรือ p (pico, 0.000000000001 BTC) ภายใน จำนวนเก็บเป็น millisatoshi — 1/1000 ของ satoshi — ซึ่งเป็นเหตุผลที่ Lightning route การจ่ายเงินด้วยความแม่นยำต่ำกว่า satoshi ได้ แม้ base-layer blockchain จะบันทึกเฉพาะ satoshi เต็ม

ถ้าไม่มีจำนวนใน invoice ผู้จ่ายส่งได้จำนวนไหนก็ได้ เรียก “zero-amount invoice” และบางครั้งใช้สำหรับ tip jar หรือ pay-what-you-want

ส่วนข้อมูล

หลังจากตัวคั่น Bech32 invoice มี field ที่ tag ต่อเนื่อง:

Payment hash (tag p): SHA-256 hash 32 bytes ของ payment preimage ผู้รับถือ preimage และเปิดเผยเมื่อการจ่ายเงินมาถึง ทำหน้าที่เป็นหลักฐาน cryptographic ของการจ่ายเงิน เป็น field ที่สำคัญที่สุด — ระบุการจ่ายเงินเอกลักษณ์และป้องกัน double-spending
Description (tag d): string UTF-8 สั้นที่อธิบายวัตถุประสงค์ของการจ่ายเงิน กระเป๋าแสดงให้ผู้จ่ายเห็นก่อนยืนยัน อีกทางเลือก description hash (tag h) ใช้สำหรับคำอธิบายยาวได้ — encode เฉพาะ hash ใน invoice เอง
Expiry (tag x): กี่วินาทีหลังจาก timestamp สร้าง invoice ที่ invoice ยังใช้ได้ default ถ้าไม่ใส่คือ 3600 วินาที (1 ชั่วโมง) ตาม BOLT 11 specification หลังหมดอายุ โหนดผู้รับอาจปฏิเสธรับการจ่ายเงิน
Timestamp: Unix timestamp ที่สร้าง invoice encode ในส่วนข้อมูล รวมกับ field expiry ได้เวลาหมดอายุสัมบูรณ์
Routing hints (tag r): private channel hints (optional) ที่ช่วยผู้จ่ายหา route ไปผู้รับแม้โหนดผู้รับไม่มี public channel

ส่วนข้อมูลทั้งหมดลงนามด้วย private key ของโหนดผู้รับ decoder verify signature นี้เป็นส่วนหนึ่งของการ parse — invoice ที่ signature invalid ถูกปฏิเสธ

ความละเอียดของจำนวน

หนึ่งในคุณสมบัติโดดเด่นที่สุดของ Lightning คือความละเอียดระดับ millisatoshi ในขณะที่ Bitcoin base layer ไม่สามารถ settle จำนวนเล็กกว่า satoshi เดียว การบัญชีภายในของ Lightning ใช้ millisatoshi (msat) ตลอด นั่นหมายความว่าโหนด Lightning forward การจ่ายเงิน เช่น 1 msat ได้ — เท่ากับหนึ่งในพันของ satoshi ซึ่งที่ราคาปัจจุบันเป็นเศษเสี้ยวเล็กของเซ็นต์ routing fee ก็แสดงเป็น millisatoshi ดังนั้นโหนดคิดค่าธรรมเนียม 0.1% ของการจ่ายเงิน 1 sat เป็นค่าธรรมเนียมได้แม้ค่าธรรมเนียมนั้นจะน้อยกว่า satoshi เดียว

decoder แสดงจำนวนทั้งเป็น satoshi (ปัดลงจาก millisatoshi) และเป็น BTC คุณตรวจจำนวน invoice ได้เร็วโดยไม่ต้องคำนวณในหัว

semantic ของการหมดอายุ

Lightning invoice จำกัดเวลาเพราะมีเหตุผล โหนด Lightning ของผู้รับต้องเก็บ payment preimage ใน memory พร้อมปล่อยเมื่อการจ่ายเงินมาถึง ถ้า invoice ไม่หมดอายุ โหนดจะสะสมการผูกมัดการจ่ายเงินค้างไม่จำกัด default มาตรฐาน 3600 วินาที (1 ชั่วโมง) ให้ผู้จ่ายเวลาเพียงพอในการ action โดยไม่ภาระผู้รับไม่จำกัด บางบริการออก invoice สั้นกว่า (60-300 วินาที) สำหรับ scenario จุดขาย decoder แสดงเวลาเหลือเป็นนาทีเพื่อให้คุณดูได้ว่า invoice ยัง actionable ไหม

FAQ

ทำไม LNURL ของผม decode ไม่ได้?

LNURL เป็น protocol ต่างกัน LNURL คือ HTTPS URL ที่ encode แบบ Bech32 ที่กระเป๋าคุณดึงเพื่อรับ invoice BOLT 11 URL เองไม่ใช่ invoice — เป็นตัวชี้ไปที่ที่หา invoice ได้ Lightning address ในรูป user@domain.com คือ LNURL-pay แบบย่อ ทั้ง 2 รูปแบบ decode ที่นี่ไม่ได้ เฉพาะ invoice BOLT 11 ที่ครบรูปแบบขึ้นต้นด้วย lnbc (หรือ lntb/lnbcrt สำหรับเครือข่ายทดสอบ) เท่านั้นที่รองรับ

prefix “s” ใน string invoice บางอันหมายถึงอะไร?

s ที่คุณอาจเห็นบางครั้งใน string invoice เป็นส่วนของการ encode tagged field ภายในข้อมูล Bech32 ไม่ใช่ส่วนของ human-readable prefix human-readable prefix เริ่มด้วย ln เสมอ ถ้าเห็นอะไรแบบ lnbc10u1p… นั่นคือ invoice 10 microBTC บน mainnet ตัวอักษรหลังตัวคั่นเป็นข้อมูล Bech32 ล้วนและไม่ควรอ่านออกโดยตรง

ทำไม expiry default คือ 3600 วินาที?

BOLT 11 specification (แต่งโดย Rusty Russell ตอนแรก) เลือก 3600 วินาทีเป็น default เพราะยาวพอที่การจ่ายเงินส่วนใหญ่จะสำเร็จหรือล้มเหลวในหน้าต่างนั้น แต่สั้นพอที่โหนดผู้รับไม่ภาระด้วยการผูกมัดเก่าไม่จำกัด กระเป๋าและผู้ให้บริการชำระเงินตั้ง expiry สั้นหรือยาวกว่าได้ แต่ 3600 เป็นสิ่งที่ spec กำหนดเมื่อไม่มี field expiry

ใช้อันนี้จ่าย invoice ได้ไหม?

ไม่ได้ นี่คือ decoder อ่านอย่างเดียว ตรวจโครงสร้าง invoice และดึง field ที่ encode จ่าย Lightning invoice จริงต้องใช้กระเป๋าที่รองรับ Lightning เช่น Phoenix, Breez, Mutiny หรือโหนด self-hosted ที่รัน LND หรือ Core Lightning

payment hash เหมือน payment preimage ไหม?

ไม่เหมือน payment hash คือ SHA-256 hash ของ payment preimage ผู้รับเก็บ preimage ไว้ลับ เมื่อการจ่ายเงินมาถึงตาม route ผู้รับปล่อย preimage และแต่ละ hop ใน route ใช้มัน settle HTLC ขาออก payment hash คือสิ่งที่ปรากฏใน invoice และสิ่งที่ผู้จ่ายและโหนดกลางเห็นได้ preimage เปิดเผยเฉพาะตอน settlement และทำหน้าที่เป็นใบเสร็จที่ปลอมไม่ได้