Bitcoin Core दूसरे नोड से ब्लॉक और लेनदेन लेकर चल रहे प्रोग्राम के नियमों के अनुसार जाँचता है। इसलिए सत्यापन के लिए केवल किसी बाहरी सेवा की बात मानना ज़रूरी नहीं रहता। नोड चलाना माइनिंग नहीं है और इससे BTC का इनाम नहीं मिलता।
पावेल किताबें बेचता है और बिटकॉइन में भुगतान लेता है। एक ग्राहक अपने फ़ोन पर भुगतान की रसीद दिखाती है, लेकिन पावेल जानना चाहता है कि भुगतान सच में आया है और किसी मान्य ब्लॉक में शामिल है या नहीं। वह सार्वजनिक ब्लॉक एक्सप्लोरर देख सकता है, या अपने नोड से जुड़े वॉलेट का इस्तेमाल कर सकता है। Bitcoin Core उस नोड को चलाने वाला प्रोग्राम है। यहाँ नोड का मतलब ऐसा कंप्यूटर है जिसका सॉफ़्टवेयर Bitcoin के नियम स्वतंत्र रूप से जाँचता है; ब्लॉक लेनदेन का वह समूह है जो साझा इतिहास में जोड़ा जाता है। डेटा दूसरों से आता है, पर उसकी वैधता प्रोग्राम खुद जाँचता है। पावेल एक उदाहरण है: मकसद किसी और की स्क्रीन पर भरोसा करने के बजाय अपना सत्यापन करना है। प्रोग्राम इंस्टॉल करने से वह माइनर नहीं बनता, उसे अपने आप BTC नहीं मिलते और वह दूसरों के भुगतान वापस नहीं कर सकता। परियोजना का सोर्स कोड MIT लाइसेंस के तहत खुला है, जिसकी शर्तों के अनुसार उसे पढ़ा, बदला और फिर वितरित किया जा सकता है। [1] [16]
दोनों काम आसानी से गड्डमड्ड हो जाते हैं, क्योंकि Bitcoin Core दोनों कर सकता है। नोड इतिहास और नए ब्लॉक जाँचता है। वॉलेट संबंधित धन का हिसाब रखता है, पते बनाता है और लेनदेन तैयार करता है। अगर वह निजी कुंजियाँ संभालता है, तो उनसे हस्ताक्षर भी कर सकता है। निजी कुंजी एक गोपनीय जानकारी है जिससे वॉलेट डिजिटल हस्ताक्षर बनाता है और संबंधित बिटकॉइन खर्च करने की अनुमति साबित करता है। कुंजी खुद दूसरे नोड को नहीं भेजी जाती। लेकिन Core बिना वॉलेट के भी चलता है। पावेल भुगतान के लिए कोई दूसरा संगत ऐप और जाँचे हुए डेटा के लिए अपना नोड इस्तेमाल कर सकता है; कुछ जोड़ने के तरीकों में अतिरिक्त सॉफ़्टवेयर चाहिए। केवल Core चालू करने से बाकी सभी वॉलेट अपने आप उसी नोड पर नहीं आ जाते। नाम समझने के लिए: bitcoin-qt चित्रात्मक इंटरफ़ेस देता है, bitcoind पृष्ठभूमि में चलता है और bitcoin-cli प्रोग्राम को कमांड भेजता है। [12] [17]
नए नोड को पहले पुराना इतिहास पूरा करना होता है। इसे Initial Block Download या IBD कहते हैं। सामान्य सिंक में वह ब्लॉक डाउनलोड करके उनके आपसी संबंध, माइनरों के काम और लेनदेन के नियम जाँचता है। इससे उसका chainstate बनता है: अभी तक खर्च न हुए लेनदेन आउटपुट, यानी UTXO का स्थानीय रिकॉर्ड। लेनदेन का आउटपुट एक रकम और उसे खर्च करने की शर्तें बताता है, जैसे ज़रूरी हस्ताक्षर। जब तक कोई अगला लेनदेन उसे खर्च नहीं करता, वह इस रिकॉर्ड में रहता है। यह लोगों के नाम और बैंक खातों की सूची नहीं है। गति कंप्यूटर, डिस्क और कनेक्शन पर निर्भर है, इसलिए धीमी शुरुआत अपने आप खराबी नहीं बताती। पावेल वर्तमान भुगतान जाँचने से पहले सिंक पूरा होने की पुष्टि करता है।
एक ज़रूरी बारीकी है: तय शर्तों में assumevalid बहुत पुराने इतिहास की स्क्रिप्ट, यानी खर्च की शर्तों की जाँच छोड़ सकता है; -assumevalid=0 यह शॉर्टकट बंद करता है। दूसरी सुविधा AssumeUTXO जाँचे गए स्थिति-स्नैपशॉट से शुरुआत करके पिछला इतिहास पृष्ठभूमि में संसाधित करने देती है। स्नैपशॉट किसी खास ब्लॉक के समय की UTXO स्थिति का सहेजा हुआ रिकॉर्ड है। प्रोग्राम पहले उसके hash, यानी डिजिटल फ़िंगरप्रिंट, को अपने कोड में दी गई अपेक्षित वैल्यू से मिलाता है; इससे यह नहीं मान सकते कि पिछला पूरा इतिहास स्वतंत्र रूप से जाँचा जा चुका है। दोनों की धारणाएँ अलग हैं; यह कहना ठीक नहीं कि हर इंस्टॉलेशन ने शुरू से बिल्कुल एक जैसी जाँच पूरी कर ली है। [9] [10] [12] [17]
सिंक के बाद भी Core जुड़े नोड से डेटा लेता रहता है; इन्हें peers कहते हैं। स्वीकार किए गए अपुष्ट लेनदेन उसके Mempool में रहते हैं, जो एक अस्थायी प्रतीक्षालय है। वहाँ होना ब्लॉक में पुष्टि मिलना नहीं है, और अलग नोड की सूची अलग हो सकती है। नया ब्लॉक आने पर Core उसे जाँचता है। मान्य उम्मीदवार चेन में वह सबसे अधिक संचित काम वाली चेन चुनता है, कंप्यूटरों के वोट या केवल ब्लॉक की संख्या नहीं गिनता। इसलिए पावेल भुगतान दिखने और उसकी पुष्टि होने में अंतर करता है। अपना नोड भी तुरंत ब्लॉक में शामिल होने की गारंटी नहीं देता और पुनर्गठन नहीं रोकता, जिसमें दूसरी मान्य शाखा देखे जा रहे इतिहास के एक हिस्से की जगह लेती है। [16]
मान लें पावेल का नोड किसी अपुष्ट लेनदेन को Mempool में नहीं लेता। इसका मतलब यह नहीं कि वह कभी मान्य ब्लॉक में आ ही नहीं सकता। सहमति के नियम तय करते हैं कि कौन-सा ब्लॉक और खर्च नोड के लिए मान्य है। स्थानीय relay policy अतिरिक्त शर्तें तय करती है कि कौन-से अपुष्ट लेनदेन स्वीकार और आगे भेजे जाएँ, जैसे संसाधनों को अत्यधिक भार से बचाना। प्राप्त ब्लॉक के भीतर मौजूद लेनदेन पर वही नीति उसी तरह लागू नहीं होती; वहाँ सहमति के नियमों के अनुसार वैधता मायने रखती है। इसलिए Mempool की अलग सेटिंग अपने आप नेटवर्क नहीं बाँटती। यह अंतर समझकर Core की बहस पढ़ें, ताकि हर विकल्प को पैसे के नियम बदलना न मान लें। [13]
Core ब्लॉक डेटा, नोड की स्थिति और इस्तेमाल होने पर वॉलेट रखता है। Pruning पुराने ब्लॉक फ़ाइलों और उनके बदलाव पलटने वाले डेटा को संसाधित करने के बाद हटाकर जगह बचाता है। नोड नए ब्लॉक फिर भी जाँचता है, बस पूरा पुराना संग्रह हाथ में नहीं रहता। पुराने रिकॉर्ड देखने या पुराने भुगतान दोबारा खोजने के लिए डेटा फिर डाउनलोड करना पड़ सकता है। इंडेक्स खोज तेज़ करने वाले सहायक रिकॉर्ड हैं; उदाहरण के लिए txindex, pruning के साथ नहीं चलता। इन्हें नोड के काम के अनुसार चुनना चाहिए। अहम अंतर यह है कि सार्वजनिक ब्लॉक फिर डाउनलोड हो सकते हैं, लेकिन खोई निजी कुंजियाँ उनसे वापस नहीं मिलतीं। Core वॉलेट को अपना सुरक्षित बैकअप चाहिए। चलते प्रोग्राम में backupwallet जैसी बैकअप सुविधा इस्तेमाल करें, लिखे जा रहे डेटाबेस की मनमानी कॉपी नहीं। [11] [12]
पावेल आधिकारिक वेबसाइट से शुरू करके चुनी रिलीज़ के निर्देश पढ़ता है। SHA-256 चेकसम डाउनलोड की गई फ़ाइल का फ़िंगरप्रिंट है: वह अपेक्षित फ़ाइल से अंतर पकड़ता है। अकेला वह नहीं बताता कि अपेक्षित फ़िंगरप्रिंट किसने प्रकाशित किया। इसलिए डिजिटल हस्ताक्षर और हस्ताक्षर करने वाली कुंजियों की पहचान भी जाँचनी होती है। अगर हमलावर प्रोग्राम और अपना चेकसम दोनों दे, तो उनके मेल खाने से हमला नहीं रुकता। गहरे सत्यापन के लिए परियोजना पुनरुत्पादनीय बिल्ड इस्तेमाल करती है: स्वतंत्र लोग एक ही सोर्स कोड से समान फ़ाइलें बना कर परिणाम मिला सकते हैं। Guix एक समान बिल्ड वातावरण बनाने में मदद करता है। इससे प्रोग्राम के मूल की जाँच मज़बूत होती है, लेकिन कोड में कोई त्रुटि नहीं होने का प्रमाण नहीं मिलता। [8] [7]
Core का JSON-RPC इंटरफ़ेस दूसरे प्रोग्राम को उसे नियंत्रित करने देता है। इससे स्थिति पूछना और सेवाएँ जोड़ना संभव है, लेकिन उपलब्ध वॉलेट और अधिकारों के अनुसार धन संबंधी काम भी किए जा सकते हैं। इसलिए लॉगिन जानकारी किसी कथित मददगार को न दें। यह इंटरफ़ेस खुद नेटवर्क ट्रैफ़िक एन्क्रिप्ट नहीं करता और सार्वजनिक इंटरनेट पर खोलने के लिए नहीं बना है। दूसरे Bitcoin नोड से सामान्य जुड़ाव और इन नियंत्रणों को बाहर खोलना अलग बातें हैं। स्थानीय पहुँच में Core, .cookie फ़ाइल की अस्थायी लॉगिन जानकारी भी इस्तेमाल करता है। दूर से प्रशासन के लिए दस्तावेज़ों के अनुसार सुरक्षित कनेक्शन और सीमित पहुँच चाहिए। केवल नोड आज़माने के लिए उसका प्रशासन दुनिया भर को खोलना ज़रूरी नहीं। [14]
कोई भी कोड में बदलाव सुझा सकता है। दूसरे योगदानकर्ता उसे पढ़ते, जाँचते और उस पर चर्चा करते हैं; रिपॉज़िटरी संभालने वाले maintainers स्वीकृत बदलाव मिला सकते हैं। इससे उन्हें पावेल के नोड का रिमोट नियंत्रण नहीं मिलता। कौन-सा सॉफ़्टवेयर चलेगा, यह संचालक चुनता है। लेकिन यह चुनाव भी ऐसा वोट नहीं जिससे एक व्यक्ति सबके नियम लिख दे: असंगत बदलाव उसका नोड बाकी से अलग कर सकता है। Bitcoin Core नियमों का महत्वपूर्ण कार्यान्वयन है, पूरे नेटवर्क की मालिक कंपनी नहीं। इसलिए घोषणा पढ़ते समय प्रस्ताव, सोर्स में स्वीकृति, रिलीज़ और वास्तविक उपयोग को अलग रखें। इन चरणों के बीच लंबा रास्ता हो सकता है। [15]
आप निजी कुंजियाँ रखे बिना नोड से शुरुआत कर सकते हैं। पावेल फ़ाइल और हस्ताक्षर जाँचता है, IBD पूरा होने देता है और पुष्टि करता है कि उसका वॉलेट वास्तव में उसके नोड से डेटा ले रहा है। फिर कनेक्शन, ब्लॉक की प्रगति और खाली जगह देखता है। अपडेट से पहले release notes पढ़ता है, जिनमें बदलाव और बदलाव लागू करने की शर्तें होती हैं; वॉलेट इस्तेमाल करने पर बैकअप और बहाली भी जाँचता है। समस्या समझने में debug.log मदद करता है, लेकिन उसे बिना सोचे सार्वजनिक नहीं करना चाहिए। Pruning, इंडेक्स और RPC उपयोग के हिसाब से हों, किसी अनजानी गाइड की अंधी नकल नहीं। अपना नोड ऐसा जाँच उपकरण होना चाहिए जिसे आप समझें। पहली छोटी खरीद के लिए यह अनिवार्य नहीं, लेकिन तब उपयोगी है जब जानना चाहते हों कि अपने भुगतान को मान्य क्यों मान रहे हैं। [12] [14]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Full Node, सहमति के नियम, BIP (Bitcoin Improvement Proposal), Bitcoin, Soft Fork, Mempool. इस प्रविष्टि का उल्लेख यहाँ भी है Soft Fork, Hard Fork, BIP (Bitcoin Improvement Proposal), सहमति के नियम.