Just-in-Time (JIT) Channels คือ technique ใน Lightning Network ที่ช่วยแก้ปัญหา inbound liquidity
ปัญหาที่ JIT แก้:
ปกติถ้าจะรับเงินผ่าน Lightning ต้องมี channel ที่มี inbound liquidity พร้อมอยู่ก่อน ซึ่งต้องล็อก BTC ไว้ล่วงหน้า ทำให้ไม่เป็นมิตรกับ new users
JIT แก้ยังไง:
เมื่อมีการส่งเงินมาหา user ที่ยังไม่มี channel LSP (Lightning Service Provider) จะ:
1. ตรวจจับ payment ที่กำลังจะมาถึง
2. เปิด channel ใหม่แบบ on-chain แบบ real-time
3. ส่ง payment ผ่าน channel ใหม่นั้นทันที
ทั้งหมดเกิดในช่วงเวลาที่ payment กำลัง route มา ก่อนที่มันจะ timeout
ทำไมสำคัญ:
ทำให้ user รับ Bitcoin ผ่าน Lightning ได้ครั้งแรกโดยไม่ต้องเปิด channel เองหรือรอ on-chain confirmation ล่วงหน้า — ลดแรงเสียดทานสำหรับ new users มาก
Trade-off:
LSP ต้องแบกต้นทุน on-chain transaction fee ทุกครั้งที่เปิด channel ใหม่ จึงมักคิด fee จาก payment แรกของ user เพื่อชดเชย
Core Lightning v25.12 เพิ่ง implement เป็น experimental feature ซึ่งเป็น stepping stone สำคัญสู่ Lightning ที่ใช้งานได้จริงโดยไม่ต้องมี technical knowledge ครับ
Time Lock (CLTV Delta)
Routing node ต้องตั้ง CLTV delta ให้พอกับ:
∙ เวลาที่ LSP ต้องการ broadcast on-chain tx
∙ รอ confirmation อย่างน้อย 1 block (หรือมากกว่าถ้า conservative)
∙ ส่ง payment ต่อผ่าน channel ใหม่
ถ้า CLTV delta สั้นเกินไป → payment timeout ก่อน channel พร้อม ถ้ายาวเกินไป → capital ถูกล็อกนาน ไม่คุ้ม
Rate Limiting (JIT per day/month)
จำเป็นมาก เพราะไม่มี limit = attack surface ที่ชัดเจน
Griefing attack: ส่ง payment หลอกๆ เพื่อบังคับให้ LSP เปิด channel ใหม่ซ้ำๆ จ่าย on-chain fee ทุกครั้ง โดยไม่ได้รับเงินจริง
สิ่งที่ต้องพิจารณา:
∙ limit per destination node
∙ limit per source node หรือ SCID
∙ cooldown period ระหว่าง JIT channels
∙ minimum payment size ก่อน trigger JIT (กันฝุ่น)
∙ fee ที่คิดจาก first payment ต้อง cover worst-case on-chain fee
ความซับซ้อนที่น่าสนใจ
ถ้า node อยู่ตรงกลาง routing path มันจะไม่รู้ว่า payment นี้จะ succeed หรือเปล่า ก่อนที่มันจะต้องตัดสินใจเปิด channel แล้ว นี่คือเหตุผลที่ทำให้ implementation ยาก และยังเป็น experimental อยู่
คุณสนใจจะ implement routing node เองอยู่ไหมครับ?
ปัญหาที่ JIT แก้:
ปกติถ้าจะรับเงินผ่าน Lightning ต้องมี channel ที่มี inbound liquidity พร้อมอยู่ก่อน ซึ่งต้องล็อก BTC ไว้ล่วงหน้า ทำให้ไม่เป็นมิตรกับ new users
JIT แก้ยังไง:
เมื่อมีการส่งเงินมาหา user ที่ยังไม่มี channel LSP (Lightning Service Provider) จะ:
1. ตรวจจับ payment ที่กำลังจะมาถึง
2. เปิด channel ใหม่แบบ on-chain แบบ real-time
3. ส่ง payment ผ่าน channel ใหม่นั้นทันที
ทั้งหมดเกิดในช่วงเวลาที่ payment กำลัง route มา ก่อนที่มันจะ timeout
ทำไมสำคัญ:
ทำให้ user รับ Bitcoin ผ่าน Lightning ได้ครั้งแรกโดยไม่ต้องเปิด channel เองหรือรอ on-chain confirmation ล่วงหน้า — ลดแรงเสียดทานสำหรับ new users มาก
Trade-off:
LSP ต้องแบกต้นทุน on-chain transaction fee ทุกครั้งที่เปิด channel ใหม่ จึงมักคิด fee จาก payment แรกของ user เพื่อชดเชย
Core Lightning v25.12 เพิ่ง implement เป็น experimental feature ซึ่งเป็น stepping stone สำคัญสู่ Lightning ที่ใช้งานได้จริงโดยไม่ต้องมี technical knowledge ครับ
Time Lock (CLTV Delta)
Routing node ต้องตั้ง CLTV delta ให้พอกับ:
∙ เวลาที่ LSP ต้องการ broadcast on-chain tx
∙ รอ confirmation อย่างน้อย 1 block (หรือมากกว่าถ้า conservative)
∙ ส่ง payment ต่อผ่าน channel ใหม่
ถ้า CLTV delta สั้นเกินไป → payment timeout ก่อน channel พร้อม ถ้ายาวเกินไป → capital ถูกล็อกนาน ไม่คุ้ม
Rate Limiting (JIT per day/month)
จำเป็นมาก เพราะไม่มี limit = attack surface ที่ชัดเจน
Griefing attack: ส่ง payment หลอกๆ เพื่อบังคับให้ LSP เปิด channel ใหม่ซ้ำๆ จ่าย on-chain fee ทุกครั้ง โดยไม่ได้รับเงินจริง
สิ่งที่ต้องพิจารณา:
∙ limit per destination node
∙ limit per source node หรือ SCID
∙ cooldown period ระหว่าง JIT channels
∙ minimum payment size ก่อน trigger JIT (กันฝุ่น)
∙ fee ที่คิดจาก first payment ต้อง cover worst-case on-chain fee
ความซับซ้อนที่น่าสนใจ
ถ้า node อยู่ตรงกลาง routing path มันจะไม่รู้ว่า payment นี้จะ succeed หรือเปล่า ก่อนที่มันจะต้องตัดสินใจเปิด channel แล้ว นี่คือเหตุผลที่ทำให้ implementation ยาก และยังเป็น experimental อยู่
คุณสนใจจะ implement routing node เองอยู่ไหมครับ?