161 / 736CASHU

Cashu

ऐसी डिजिटल नकदी जिसका भुगतान एक खास जारीकर्ता पर निर्भर है

Cashu से डिजिटल नकदी एक साधारण संदेश में भी भेजी जा सकती है। लेकिन पाने वाले को यह समझना ज़रूरी है कि उसे किसने जारी किया, भुगतान कैसे स्वीकार करना है और उसे बिटकॉइन में कैसे बदलना है। अधिक निजी भुगतान का अर्थ ऑपरेटर पर भरोसे की ज़रूरत खत्म होना नहीं है।

Cashu e-cash का एक खुला प्रोटोकॉल है। इसमें mint कहलाने वाला जारीकर्ता डिजिटल टोकन बनाता है। ये अक्सर बिटकॉइन की राशि दर्शाते हैं; जमा या निकासी के लिए, उदाहरण के तौर पर, Lightning Network इस्तेमाल किया जा सकता है। धारक टोकन नियंत्रित करता है, mint की बिटकॉइन कुंजियाँ नहीं; इसलिए उसका सहयोग आगे भी ज़रूरी रहता है।

मान लीजिए अन्ना पेत्र को निजी संदेश में Cashu टोकन भेजती है। वह ब्लॉकचेन पर Bitcoin लेनदेन प्रसारित नहीं कर रही। वह ऐसा डेटा सौंप रही है जिसे पेत्र संबंधित mint के पास भुना सकता है। एक टोकन में एक या अधिक प्रमाण (Proof) हो सकते हैं। ये डेटा रिकॉर्ड हैं, जिनमें रकम, गुप्त मान और mint के हस्ताक्षर समेत अन्य जानकारी होती है। Cashu साझा प्रोटोकॉल है, साझा भंडार वाली एकमात्र सेवा नहीं। जारीकर्ता, मुद्रा की इकाई और हस्ताक्षर कुंजियों का समूह—तीनों मायने रखते हैं। sats में राशि का मतलब बिटकॉइन की छोटी इकाइयाँ हैं; दूसरी इकाई में वही संख्या कुछ और दर्शाएगी। एक mint के टोकन दूसरे में अपने आप स्वीकार नहीं होते। प्रारूप में रुचि रखने वालों के लिए: V4 संक्षिप्त CBOR बाइनरी एन्कोडिंग इस्तेमाल करता है और केवल एक mint के प्रमाण रखता है। [1] [2] [9]

अतिरिक्त खर्च-शर्तों के बिना सामान्य टोकन की एक प्रति अन्ना अपने पास रख सकती है। इसलिए पेत्र को swap चाहिए: उसका वॉलेट पुराने प्रमाण mint को देता है और नए प्रमाण पाता है, जिनके गुप्त मान अन्ना नहीं जानती। mint पुराने इनपुट अमान्य कर देता है। सफल विनिमय ही अन्ना को उसी प्रति को फिर खर्च करने से रोकता है। केवल स्थिति जाँचना पर्याप्त नहीं। UNSPENT का मतलब प्रसंस्करण या खर्च का रिकॉर्ड नहीं है; यह पेत्र के लिए आरक्षण नहीं है। PENDING का अर्थ प्रक्रिया जारी है और SPENT का अर्थ प्रमाण इस्तेमाल हो चुका है। इसलिए टोकन को भुगतान की रसीद समझकर सार्वजनिक न करें: इस्तेमाल योग्य प्रति पाने वाला व्यक्ति पहले उसे भुना सकता है। [3] [5]

Blind Signature, यानी ब्लाइंड हस्ताक्षर, टोकन जारी होने और बाद में इस्तेमाल होने के बीच संबंध छिपाने में मदद करता है। वॉलेट एक गुप्त मान बनाता है, उसका गणितीय रूप छिपाता है और mint से हस्ताक्षर माँगता है। फिर वह छिपाने वाला आवरण हटा देता है। बाद में प्रस्तुत टोकन को देखकर ही mint को पुराने जारीकरण अनुरोध की पहचान नहीं होनी चाहिए। लेकिन इससे सब कुछ नहीं छिपता: अलग मूल्यवर्गों की कुंजियाँ अलग होती हैं, इसलिए जारीकर्ता जानता है कि कौन-से मूल्यवर्ग जारी किए गए। तकनीकी विधि का नाम BDHKE है और यह secp256k1 वक्र इस्तेमाल करती है। भुगतान समझने के लिए वक्र के बिंदुओं की गणना ज़रूरी नहीं; ज़रूरी यह है कि यह गणित किस संबंध को सुरक्षित रखता है। [1]

वैकल्पिक विस्तार NUT-12 में DLEQ जोड़ा जाता है। यह गणितीय प्रमाण बताता है कि हस्ताक्षर में वही निजी कुंजी इस्तेमाल हुई जो mint की सार्वजनिक कुंजी से मेल खाती है। आवश्यक साथ का डेटा होने पर पेत्र mint से संपर्क किए बिना हस्ताक्षर जाँच सकता है। इससे यह नहीं पता चलता कि दूसरी प्रति खर्च हो चुकी है या नहीं, सेवा जवाब दे रही है या नहीं, अथवा बिटकॉइन भंडार पर्याप्त है या नहीं। DLEQ साथ होने पर विनिर्देश वॉलेट से उसका सत्यापन माँगता है। फिर भी हस्ताक्षर जाँच सफल swap की जगह नहीं लेती। Counterparty risk, यानी ऑपरेटर के अपना वादा पूरा न करने का जोखिम, बना रहता है। [7]

पेत्र नए टोकन लेने के बजाय Lightning Network के भुगतान अनुरोध का भुगतान करना चाह सकता है। यह विनिमय melt कहलाता है। वॉलेट पहले प्रस्ताव माँगता है: कितने टोकन, किस इकाई में, कब तक प्रस्ताव वैध है और क्या शुल्क के लिए अतिरिक्त आरक्षित राशि चाहिए। इनपुट शुल्क भी लग सकता है। इसके बाद प्रमाण सौंपे जाते हैं और mint बाहरी भुगतान करता है। HTTP 200 वेब अनुरोध सफलतापूर्वक संभाले जाने का संकेत है, भुगतान हो जाने का ज़रूरी नहीं। PENDING अभी भी “प्रक्रिया जारी है” बताता है, जबकि PAID सफलता बताता है। वॉलेट को अंतिम परिणाम और भुगतान विधि के अनुसार पुष्टि पर नज़र रखनी होती है। [4]

mint हस्ताक्षर कुंजियों का समूह बदल सकता है। active=false का अर्थ पुराने समूह से नए टोकन जारी नहीं होना है; केवल इससे पुराने प्रमाणों को इनपुट के रूप में स्वीकार करना बंद नहीं होता। वैकल्पिक final_expiry अलग है: इस अंतिम समय के बाद विनिर्देश mint को संबंधित भुगतान-वादा पूरा करने के लिए बाध्य नहीं करता। दोनों स्थितियों को न मिलाएँ। input_fee_ppk भी हर इनपुट का शुल्क है, भेजी जा रही राशि का साधारण प्रतिशत नहीं। इस्तेमाल किए गए सभी प्रमाणों की दरें जोड़कर योग को 1000 से भाग दिया जाता है, और उसके बाद ही शुल्क को अगली पूरी इकाई तक बढ़ाया जाता है। उदाहरण के लिए, sat इकाई वाले कुंजी-समूह में 3 इनपुट की दर 100 ppk प्रति इनपुट हो तो योग 300 है; भाग और ऊपर की ओर पूर्णांकन के बाद शुल्क 1 sat है। इसीलिए बराबर रकम के दो भुगतानों का खर्च अलग हो सकता है, यदि प्रमाणों की संख्या या कुंजी-समूह अलग हों। [2]

ब्लाइंड हस्ताक्षर भुगतान का समय, रकम या नेटवर्क कनेक्शन डेटा नहीं मिटाता। नए मूल्यवर्ग माँगने का तरीका भी जानकारी दे सकता है। NUT-03 माँगे गए मूल्यों को छोटे से बड़े क्रम में रखने की सलाह देता है, ताकि उनका क्रम भुगतान और बची रकम का बँटवारा अनावश्यक रूप से न बताए। भेजने वाला यदि सौंपे हुए टोकनों की स्थिति बार-बार पूछता है, तो उससे भी उसे पाने वाले से जोड़ना आसान हो सकता है। Cashu अधिक निजी धन-लेनदेन के साधन देता है; हर ऐप और हर परिस्थिति अपने आप सभी संबंध छिपा दे, ऐसा नहीं है। [3] [5]

पुनर्प्राप्ति की प्रक्रिया इस्तेमाल किए गए वॉलेट और mint के अनुरूप होनी चाहिए। NUT-13 बताता है कि seed, यानी शुरुआती गुप्त मान, कुंजी-समूह और काउंटर से टोकन के गुप्त मान तथा ब्लाइंडिंग कारक दोबारा कैसे निकाले जाते हैं। कुंजी-समूह संस्करण 01 में HMAC-SHA256 और पुराने 00 में BIP32 इस्तेमाल होता है। seed जिन हस्ताक्षरों को खुद नहीं बना सकता, वे mint से NUT-09 द्वारा मिलते हैं; फिर जाँचना पड़ता है कि क्या खर्च हो चुका है। इसलिए “मेरे पास Seed Phrase है, सब कुछ कहीं भी वापस पा लूँगा” पर्याप्त नहीं। वॉलेट पर निर्भर होने से पहले उसके बैकअप और बहाली की प्रक्रिया जाँचें तथा छोटी निकासी आज़माएँ। बैकअप गायब mint को जवाब देने के लिए मजबूर नहीं कर सकता और न उसका भंडार भर सकता है। [8] [6]

पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Fedimint, Chaumian eCash, Blind Signature, Lightning Network, Counterparty risk, Satoshi. इस प्रविष्टि का उल्लेख यहाँ भी है Chaumian eCash, Blind Signature, Fedimint, Fiduciary Media.

DOC · 001Cashu — NUT-00: Protocol and tokensविनिर्देश DOC · 002Cashu — NUT-02: Keysets and feesविनिर्देश DOC · 003Cashu — NUT-03: Swap tokensविनिर्देश DOC · 004Cashu — NUT-05: Melting tokensविनिर्देश DOC · 005Cashu — NUT-07: Token state checkविनिर्देश DOC · 006Cashu — NUT-09: Restore signaturesविनिर्देश DOC · 007Cashu — NUT-12: Offline signature validationविनिर्देश DOC · 008Cashu — NUT-13: Deterministic secretsविनिर्देश DOC · 009Cashu — Project introductionप्राथमिक स्रोत
समीक्षा की गई: स्रोत पहले · यह निवेश सलाह नहीं है