Lightning Network में route आम तौर पर sender बनाता है। वह public gossip graph, recipient द्वारा दिए गए data और अपने परिणामों से destination तक path का अनुमान लगाता है; हर hop का amount, fee और CLTV पीछे से गणना करता है, instructions को onion packet में रखता है और failure पर दूसरा path आजमाता है। Public graph मौजूदा balance split नहीं दिखाता, इसलिए routing अधूरी और तेजी से बदलती जानकारी पर probabilistic decision है।
Routing payer से शुरू होता है: उसका wallet या node payee तक candidate path चुनता और हर intermediary को अगला channel बताता है। Recipient identity, features और कभी route hints या blinded paths देता है; public हिस्सा सामान्यतः sender निकालता है।
BOLT #7 channel announcements और directional channel updates फैलाता है जिनमें base fee, proportional fee, CLTV delta, minimum, maximum और availability होते हैं। ये advertised policy और topology बताते हैं, peer के online होने या वर्तमान liquidity का प्रमाण नहीं।
Public gossip channel के दोनों पक्षों का balance split नहीं बताता। Router known local liquidity, capacity, पुराने successes और failures, penalties और implementation scoring जोड़ता है। सैद्धांतिक रूप से सबसे सस्ता path सबसे सफल हो, जरूरी नहीं।
Amounts और expiries payee से payer की ओर पीछे बनाए जाते हैं। हर hop का incoming amount अगले hop और अपनी fee को cover करता है और incoming CLTV अपने delta से outgoing CLTV से बड़ा होता है; अधिक hops total fee और timelock margin बढ़ाते हैं।
BOLT #4 onion routing उपयोग करता है: payer हर hop के अलग encrypted payload वाला Sphinx packet बनाता है। Intermediary केवल adjacent peers और अपनी instruction जानता है, पूरा path, length या position नहीं; traffic analysis और collusion फिर भी privacy घटा सकते हैं।
Temporary channel failure, insufficient fee, गलत CLTV या unknown next peer payer को सीमित failure signal लौटाते हैं। Implementation candidate को penalize, route recalculation और retry कर सकता है; एक result channel का स्थायी वर्णन नहीं।
हर hop को HTLC स्वीकार करना और reserves, pending HTLC तथा htlc_minimum_msat और htlc_maximum_msat limits के बाद सही दिशा में liquidity रखना जरूरी है। High aggregate capacity एक unbalanced channel bottleneck नहीं हटाती।
Invoice basic MPP support करे तो payer total_msat को कई paths में बाँट सकता है और recipient उन्हें एक set की तरह settle करता है। MPP distributed liquidity उपयोग करता है, पर HTLC, attempts और fees बढ़ाता और directional capacity नहीं बनाता।
BOLT 11 route hints अंतिम private hops दिखा सकते हैं; BOLT 12 और route blinding introduction point से encrypted tail देते हैं। Payer को फिर भी पहले known point तक viable route और aggregate fee तथा CLTV conditions चाहिए।
Implementation और version, amount, maximum fee व CLTV, attempt count, used paths, completion time और exact failure reason दर्ज करें। एक ही node pair को पास के समय में तुलना करें: success खास payment और network state का गुण है, permanent global score नहीं। स्रोत: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Lightning Network, HTLC, Lightning तरलता, Payment Channel, Bitcoin, Inbound Liquidity. इस प्रविष्टि का उल्लेख यहाँ भी है HTLC, Lightning तरलता, BOLT 12, Inbound Liquidity.