130 / 736CSV

CSV

खास कॉइन की पुष्टि से शुरू होने वाला इंतज़ार

कभी आप किसी तय तारीख तक नहीं, बल्कि कॉइन को चेन में कुछ समय बिताने तक रोकना चाहते हैं। CSV ऐसा अंतराल लागू करने में मदद करता है। गिनती न वॉलेट बनाने से शुरू होती है, न भुगतान पर हस्ताक्षर करने से।

CSV, Bitcoin Script के OP_CHECKSEQUENCEVERIFY का संक्षिप्त नाम है। BIP 68 के साथ यह सापेक्ष ताला लगाता है: खर्च का खास रास्ता तभी खुलता है जब पुष्टि किए गए आउटपुट की उम्र पर्याप्त हो। आउटपुट यानी मिली रकम और उसे खर्च करने की शर्तें। इंतज़ार अपने आप हस्ताक्षर की जगह नहीं लेता और पैसा नहीं भेजता।

अन्ना और पीटर साथ रखे कॉइन आपसी सहमति से खर्च कर सकते हैं। वे एक रिकवरी रास्ता भी चाहते हैं जिसे अन्ना अकेले इस्तेमाल कर सकें, लेकिन संबंधित आउटपुट की पुष्टि से कुछ समय इंतज़ार करने के बाद ही। CSV इस शर्त को लागू करने में मदद करता है। CLTV तय ऊँचाई या समय चुनता है, जबकि यहाँ सीमा पूरे इतिहास का पहले से तय एक बिंदु नहीं है। वह खास कॉइन पर निर्भर है। वॉलेट बनाना, हस्ताक्षर तैयार करना या अपुष्ट लेनदेन का बहुत देर इंतज़ार करना इस शुरुआती बिंदु की जगह नहीं लेता। वॉलेट बिटकॉइन पाने और भेजने वाला ऐप या उपकरण है। [1] [2] [8]

ब्लॉक लेनदेन का एक समूह है, जो साझा इतिहास में जोड़ा जाता है। ब्लॉक की ऊँचाई चेन में उसका स्थान बताती है। मान लीजिए आउटपुट की पुष्टि ऊँचाई 900000 पर हुई और ज़रूरी देरी 10 ब्लॉक है। इस ताले के अनुसार सबसे पहला खर्च वाला ब्लॉक 900010 हो सकता है। केवल 9 ब्लॉक का अंतराल काफी नहीं। इससे मिनटों की सटीक संख्या का वादा नहीं होता, क्योंकि ब्लॉक बराबर अंतराल पर नहीं आते। पर्याप्त उम्र हो जाना भुगतान की पुष्टि भी नहीं है। लेनदेन बाकी सभी तरह से वैध होना चाहिए और किसी माइनर को उसे सचमुच ब्लॉक में रखना होगा। [2] [4] [9]

देरी को 512 सेकंड के चरणों में भी लिखा जा सकता है। तब कोड 2 का अर्थ 1024 सेकंड है। लेकिन तुलना दो कंप्यूटर घड़ियों की नहीं होती। शुरुआत उस ब्लॉक से पहले वाले ब्लॉक का Median Time Past है जिसने आउटपुट की पुष्टि की; दूसरा सिरा संभावित ब्लॉक से पहले वाले ब्लॉक का Median Time Past है। यह हाल के अधिकतम 11 ब्लॉक के टाइमस्टैम्प क्रम में रखने पर बीच का मान है। दोनों मध्यिका मानों का अंतर ज़रूरी देरी तक पहुँचना चाहिए। यह स्थानीय समय का सटीक अलार्म नहीं है। [2] [4] [7]

वॉलेट एक भुगतान में पहले मिली कई रकम जोड़ सकता है। हर लेनदेन इनपुट पहले मिले आउटपुट को संदर्भित करता है, जिसकी उम्र चेन में उसकी पुष्टि से गिनी जाती है। nSequence फ़ील्ड खुद इनपुट में होता है। यही फ़ील्ड सापेक्ष इंतज़ार की जानकारी रखता है। केवल कुछ पैसे पर्याप्त पुराने हों तो काम नहीं चलता: लेनदेन पर लागू सभी ताले पूरे होने चाहिए। चेन का पुनर्गठन पुष्टि की जगह भी बदल सकता है। इसलिए पहले खर्च के योग्य होना कॉइन की ऐसी विशेषता नहीं जो कभी बदल न सके। पुनर्गठन में नेटवर्क चेन की दूसरी वैध शाखा अपनाता है, जिससे पुराने ब्लॉक इतिहास का एक हिस्सा बदल जाता है। [2] [4] [9]

Full Node जुड़े हुए परीक्षणों के ज़रिए नियम खुद जाँचता है। BIP 112 का CSV स्क्रिप्ट आर्ग्युमेंट की तुलना उस आउटपुट को खर्च करने वाले इनपुट के nSequence से करता है। वह खुद उम्र नहीं गिनता; लेनदेन जाँचते समय BIP 68 यह काम करता है। बंद करने वाले फ़्लैग के बिना सामान्य आर्ग्युमेंट के लिए लेनदेन का संस्करण कम से कम 2 होना चाहिए और nSequence का बिट 31 बंद होना चाहिए। बिट अंक वाले फ़ील्ड के अंदर छोटा स्विच है। ऋणात्मक आर्ग्युमेंट, पुराना संस्करण या असंगत nSequence जाँच को असफल कर देता है। [1] [2] [3]

बिट 22 तय करता है कि देरी कैसे पढ़ी जाए। वह बंद हो तो इकाई ब्लॉक है, चालू हो तो 512 सेकंड के चरण हैं। स्क्रिप्ट आर्ग्युमेंट और nSequence का प्रकार एक होना चाहिए। इसे मापों की तुलना समझें: एक तरफ किलोमीटर और दूसरी तरफ घंटे हों तो बड़ा नंबर होना काफी नहीं। यहाँ फर्क ब्लॉक की संख्या और समय के अंतराल के बीच है। [1] [2] [3]

निचले 16 बिट देरी की लंबाई रखते हैं। मास्क 0x0000ffff अंक वाले फ़ील्ड के इसी हिस्से को चुनता है। CSV इस हिस्से और देरी के प्रकार की तुलना करता है; कोई भी बड़ा nSequence अपने आप लंबा इंतज़ार नहीं है। संबंधित बिट चुनने के बाद स्क्रिप्ट की माँग इनपुट के मान से अधिक नहीं हो सकती। वॉलेट बनाने वालों के लिए यह अहम तकनीकी सीमा है। आम उपयोगकर्ता को पूरा तरीका समझे बिना इसे हाथ से नहीं बदलना चाहिए। [1] [2] [3]

शून्य देरी इंतज़ार नहीं जोड़ती, लेकिन सामान्य CSV की बाकी जाँचें लागू रहती हैं। दूसरी स्थिति तब है जब स्क्रिप्ट के गैर-ऋणात्मक आर्ग्युमेंट में ही बिट 31 चालू हो। तब CSV, NOP की तरह काम करता है, यानी सापेक्ष ताले पर असर न डालने वाला निर्देश। ऐसा आर्ग्युमेंट इंतज़ार लागू नहीं करता। इसे इनपुट के nSequence में उसी फ़्लैग से अलग समझना चाहिए: सामान्य आर्ग्युमेंट के साथ इनपुट का वह फ़्लैग बंद होना चाहिए। [1] [3]

अगर अन्ना के रिकवरी रास्ते में उनके हस्ताक्षर चाहिए, तो देरी खत्म होने पर भी उन्हें वे देने होंगे। निजी कुंजी एक गुप्त संख्यात्मक मान है, जिससे ऐसा हस्ताक्षर बनाया जाता है। खोई निजी कुंजी वापस नहीं आती और दूसरी शाखा पहले खर्च की अनुमति दे सकती है। स्क्रिप्ट चलाते समय CSV आर्ग्युमेंट को स्टैक पर रहने देता है, जो डेटा एक के ऊपर एक रखने का कार्यक्षेत्र है। इसलिए अक्सर उसके बाद OP_DROP उसे हटाता है। वह डेटा हटा देना किसी को पैसे लेने का अधिकार नहीं देता। अधिकार हस्ताक्षर और चुने रास्ते की बाकी शर्तों से तय होता है। [1] [3] [5]

BIP 112 ने OP_NOP3 की जगह CSV शुरू किया, साथ में BIP 68 और BIP 113 भी आए। यह सक्रिय सुविधा है, केवल योजना नहीं। इसका इस्तेमाल Lightning Network के भुगतान चैनलों में भी होता है, जहाँ देरी दूसरी पार्टी को प्रतिक्रिया का समय दे सकती है; वह प्रतिक्रिया खुद नहीं कराती। इंतज़ार के बाद भी लेनदेन प्रसारित करना और पुष्टि पाना ज़रूरी है। शुल्क, उपलब्ध डेटा और चेन की स्थिति मायने रखते हैं। जाँच के विवरण Bitcoin Core v29.0 और दिए गए विनिर्देशों में हैं। [1] [2] [6]

पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें CLTV, Opcode, Timelock, Bitcoin Script, Bitcoin, Full Node. इस प्रविष्टि का उल्लेख यहाँ भी है पुष्टि, Timelock, HTLC, Opcode.

DOC · 001BIP 112 — OP_CHECKSEQUENCEVERIFYविनिर्देश DOC · 002BIP 68 — Relative lock-timeविनिर्देश DOC · 003Bitcoin Core v29.0 — Script interpreterदस्तावेज़ DOC · 004Bitcoin Core v29.0 — Transaction sequence locksदस्तावेज़ DOC · 005Bitcoin Developer Reference — Transactionsदस्तावेज़ DOC · 006Bitcoin Core 0.12.1 — BIP 68/112/113 release notesदस्तावेज़ DOC · 007BIP 113 — Median time-past lock-time calculationsविनिर्देश DOC · 008BIP 65 — OP_CHECKLOCKTIMEVERIFYविनिर्देश DOC · 009Bitcoin Developer Guide — Block Chainदस्तावेज़
समीक्षा की गई: स्रोत पहले · यह निवेश सलाह नहीं है