Rusty Russell

बड़े प्रोजेक्ट अक्सर चुपचाप शुरू होते हैं। Blockstream के 9 जून 2026 के स्मरण लेख में Russell के 26 मई 2015 के पहले कमिट का ज़िक्र है: चैनल खोलने का संदेश बनाने वाला छोटा साधन। कमिट कोड के इतिहास में दर्ज किया गया बदलाव होता है। वही शुरुआती प्रयोग Core Lightning में विकसित हुआ। Russell ने प्रोग्राम, परीक्षण और दूसरे डेवलपरों के मार्गदर्शन में योगदान दिया। लेख उनके ग्यारह वर्षों बाद जाने का भी वर्णन करता है। यह भविष्य के सभी ओपन-सोर्स योगदान समाप्त होने की घोषणा नहीं है, न ही पुरानी नेतृत्व भूमिका पूरे नेटवर्क पर स्थायी अधिकार बनती है। [1]

मान लीजिए एक कैफ़े और उसका ग्राहक अलग प्रोग्राम इस्तेमाल करते हैं। भुगतान के लिए दोनों का एक ही प्रदाता चुनना ज़रूरी नहीं होना चाहिए। उन्हें संदेशों और उनके अर्थ के साझा नियम चाहिए। BOLT विनिर्देश Lightning में इसी संचार का वर्णन करते हैं। Russell ने उनके सामूहिक विकास की प्रक्रिया का नेतृत्व किया और अलग कार्यान्वयनों के साथ काम कर पाने की क्षमता को बढ़ावा दिया। सार्वजनिक रिपॉज़िटरी प्रस्ताव और टिप्पणियाँ स्वीकार करती है। फिर भी कोई प्रमुख योगदानकर्ता अकेले सभी नोडों पर बदलाव नहीं थोप सकता; नियम वास्तविक सॉफ़्टवेयर और उसके उपयोग में उतरने चाहिए। [1] [2]

दो प्रोग्राम एक ही अनुच्छेद को अलग तरह समझ सकते हैं। Russell का lnprototest Python में बने सहायक साधन देता है, जिनसे परिदृश्य लिखकर प्रोटोकॉल संदेशों पर प्रतिक्रिया जाँची जा सकती है। README, यानी प्रोजेक्ट का परिचय देने वाला दस्तावेज़, नकली रनर और वास्तविक कार्यान्वयन के विरुद्ध परीक्षण में अंतर करता है। अनुकरण परीक्षण तैयार करने में उपयोगी है, पर उसकी सफलता अपने आप वास्तविक नोड का व्यवहार साबित नहीं करती। यह जानना ज़रूरी है कि चला क्या और किन स्थितियों को जाँचा गया। सफल परिदृश्यों का समूह भी हर संभव दोष का पूरा ऑडिट नहीं है। [3]

BOLT 12 के तहत कैफ़े दोबारा इस्तेमाल होने वाला प्रस्ताव प्रकाशित कर सकता है, जैसे QR कोड। ग्राहक का वॉलेट उससे invoice_request भेजकर एक खास इनवॉइस लेता है—उस भुगतान के विवरण वाला भुगतान अनुरोध। पैसे उसके बाद भेजे जाते हैं। प्रस्ताव बार-बार इस्तेमाल हो सकता है, जबकि ग्राहकों को अलग इनवॉइस मिलते हैं। इसका अर्थ यह नहीं कि पहले इस्तेमाल हो चुके एक इनवॉइस को हर खरीद पर नया अनुरोध मान लें। प्रस्ताव, माँग और इनवॉइस को अलग रखना भुगतान आसान बनाता है और अलग लेनदेन आपस में नहीं मिलते। [4]

Core Lightning में यह अंतर साफ दिखता है। fetchinvoice कमांड प्रस्ताव जारी करने वाले से संपर्क करके इनवॉइस लेता है। changes फ़ील्ड प्रस्ताव से अंतर बता सकता है, जैसे रकम या विवरण में बदलाव। सफल उत्तर मिलने पर पैसा नहीं भेजा जाता। यह कैफ़े का बिल मिलने जैसा है: पहले जाँचें कि किस चीज़ के कितने पैसे देने हैं। वॉलेट को मिले हुए नियमों को समझकर भुगतान अलग से शुरू करना पड़ता है। अनुरोध प्राप्त करने का काम पूरा होना, भुगतान पूरा होना नहीं है। [5]

pay के दस्तावेज़ complete, pending और failed में अंतर करते हैं: पूरा, लंबित और असफल। लंबित होना भुगतान सफल होने का प्रमाण नहीं है। amount_msat प्राप्तकर्ता को मिली रकम है, जबकि amount_sent_msat शुल्क सहित भेजा गया कुल है। msat का अर्थ millisatoshi, यानी satoshi का हज़ारवाँ भाग है। इसलिए ग्राहक कैफ़े को मिली रकम से शुल्क जितना अधिक खर्च कर सकता है। दस्तावेज़ अब pay को अप्रचलित हो रहा इंटरफ़ेस बताते हैं और xpay की ओर बदलाव समझाते हैं। यहाँ अवस्थाएँ और रकम समझाई जा रही हैं, किसी संस्करण की स्थापना नहीं; परिणाम उस प्रोग्राम के अनुसार पढ़ें जो वास्तव में उपयोग में है। [6]

कैफ़े पैसा लौटाए तो पुराना भुगतान उलटा नहीं चलता। BOLT 12 विपरीत दिशा का प्रवाह भी बताता है: व्यापारी भेजी जाने वाली रकम घोषित करता है, ग्राहक इनवॉइस देता है और व्यापारी invoice_node_id जाँचता है—उस नोड का पहचानकर्ता जिसे भुगतान करना है। फिर ग्राहक को नया भुगतान जाता है। इससे मूल हस्तांतरण रद्द नहीं होता और न ही अपने आप रिफंड का अधिकार बनता है। प्रोटोकॉल उसे करने का तरीका देता है; वजह और शर्तों पर पक्षों को अलग से सहमति बनानी होती है। [4]

विवाद में यह समझना उपयोगी है कि प्रमाण वास्तव में क्या बताता है। BOLT 12 समझाता है कि preimage, भुगतान अनुरोध के हैश से मेल खाने वाला गुप्त मान, इनवॉइस चुकाए जाने को साबित कर सकता है। लेकिन सार्वजनिक होने के बाद कोई दूसरा व्यक्ति भी उसे दिखा सकता है; वह अकेला नहीं बताता कि पैसा किसने भेजा। अनुरोध में शामिल कुंजी यह साबित करने में मदद कर सकती है कि इनवॉइस किसने माँगा, पर इससे उस व्यक्ति की आधिकारिक पहचान अपने आप सत्यापित नहीं होती। चुकाया हुआ इनवॉइस, कुंजी पर नियंत्रण और ग्राहक की पहचान अलग बातें हैं। [4]