getblocktemplate

सामान्य mode=template में पीटर के प्रोग्राम को पिछले ब्लॉक, लेनदेन और अनुमत इनाम जैसी जानकारी मिलती है। यह काम का प्रस्ताव है, पहले से खोजा गया ब्लॉक नहीं। सॉफ़्टवेयर को coinbase बनाना होता है, वह विशेष पहला लेनदेन जो इनाम आवंटित करता है, और ब्लॉक का निर्माण पूरा करना होता है। हेडर ब्लॉक के डेटा का संक्षिप्त सार होता है। फिर सॉफ़्टवेयर हेडर का ऐसा hash खोजता है जो माइनिंग के लक्ष्य को पूरा करे। Hash एक संख्यात्मक क्रिप्टोग्राफ़िक छाप है; लक्ष्य पूरा करने वाला परिणाम Proof of Work, यानी किए गए गणनात्मक काम का प्रमाण बनता है। getblocktemplate स्वयं भुगतान का पता नहीं लेता और माइनिंग मशीन की गणना शुरू नहीं करता। सफल उत्तर का मतलब अभी यह नहीं कि पीटर माइनिंग कर रहा है। [1]

मान लें कि नोड ऐसे रूप में डेटा भेजे जिसे पीटर का प्रोग्राम समझ नहीं सकता। इसलिए अनुरोध के rules फ़ील्ड में समर्थित नियम बताए जाते हैं। यहाँ जाँचा गया Bitcoin Core v29.0, segwit माँगता है और परीक्षण नेटवर्क Signet के लिए signet भी। SegWit, दूसरी बातों के साथ, लेनदेन जाँचने वाले डेटा के इस्तेमाल का तरीका बदलता है। सही शब्द जोड़ देना पर्याप्त नहीं: प्रोग्राम को डेटा सही ढंग से संभालना भी आना चाहिए। capabilities इंटरफ़ेस की दूसरी क्षमताएँ बताता है, rules की जगह नहीं लेता। सटीक आवश्यकताएँ इस्तेमाल किए जा रहे कार्यान्वयन और संस्करण पर निर्भर हैं। [2]

data फ़ील्ड में पूरा लेनदेन प्रोग्रामों के बीच भेजने योग्य क्रम में रहता है। इस तरह क्रम में रखने को सीरियलाइज़ेशन कहते हैं। डेटा की बुनियादी इकाइयाँ, बाइट, यहाँ हेक्साडेसिमल यानी सोलह-आधारी रूप में लिखी जाती हैं, जिसमें अंक 0–9 और अक्षर a–f इस्तेमाल होते हैं। उत्तर में लेनदेन के छोटे पहचानकर्ता भी होते हैं। तकनीकी दस्तावेज़ BIP 145 के अनुसार txid की गणना witness डेटा के बिना होती है, जबकि hash उसे शामिल करता है। Witness में, उदाहरण के लिए, धन खर्च करने के अधिकार का प्रमाण देने वाले हस्ताक्षर होते हैं। ब्लॉक हेडर का मुख्य Merkle root, यानी लेनदेन की संयुक्त छाप, txid इस्तेमाल करता है, witness hash नहीं। इन फ़ील्ड को आपस में उलट देना केवल नाम की गलती नहीं: इससे गलत संयुक्त छाप बन सकती है और तैयार ब्लॉक अमान्य हो सकता है। [3]

पीटर को लगातार यह पूछकर नोड पर बोझ डालने की ज़रूरत नहीं कि कुछ बदला या नहीं। Long polling अनुरोध को तब तक खुला रखता है जब तक सर्वर पुरानी जानकारी बदलना न चाहे। प्रोग्राम longpollid लेता है और उसे बिना बदले वापस भेजता है। इस मान से सर्वर को पता चलता है कि प्रोग्राम किस बदलाव का इंतज़ार कर रहा है। प्रोग्राम को इसके अक्षरों से कोई खास मतलब नहीं निकालना चाहिए। BIP 22 लंबे प्रतीक्षा-समय की बात करता है। बार-बार अधूरे या अमान्य जवाब मिलने पर प्रयासों के बीच अंतराल चाहिए, तुरंत दोहराने वाला चक्र नहीं। इसलिए शांत प्रतीक्षा अपने आप में सेवा बंद होने का संकेत नहीं है। [4]

सामान्य अनुरोध दोहराने से भी हर बार नई सामग्री चुने जाने की गारंटी नहीं मिलती। Bitcoin Core v29.0 तैयार टेम्पलेट कैश में रखता है। पिछला ब्लॉक बदलने पर वह इसे दोबारा बनाता है; या तब, जब mempool, अपुष्ट लेनदेन का स्थानीय संग्रह, बदल गया हो और तैयारी के बाद पाँच सेकंड से अधिक बीत चुके हों। हेडर का समय अलग से बदला जा सकता है। इसलिए पीटर को वही लेनदेन दोबारा मिल सकते हैं; इसका मतलब नोड अटक गया है, ऐसा नहीं। किसी खास संस्करण का यह व्यवहार हर कॉल पर अनोखा माइनिंग कार्य मिलने का वादा भी नहीं है। [2]

पीटर ने ब्लॉक बनाने का तरीका बदला है और भारी गणना शुरू करने से पहले गलती पकड़ना चाहता है। proposal मोड में वह पूरा ब्लॉक हेक्साडेसिमल रूप में data के जरिए देता है। Bitcoin Core v29.0, Merkle root भी जाँचता है, लेकिन यह ज़रूरी नहीं कि वैध Proof of Work, यानी गणनात्मक काम का प्रमाण, पहले ही मिल चुका हो। यदि प्रस्ताव नोड जिस चेन का अभी उपयोग करता है, उसके आखिरी ब्लॉक को आगे नहीं बढ़ाता, तो inconclusive-not-best-prevblk लौटता है। इसका अर्थ इस जाँच की एक पूर्वशर्त का पूरा न होना है, प्रस्ताव की वैधता का पूरा आकलन नहीं। शुरुआती जाँच ब्लॉक को नेटवर्क पर प्रसारित भी नहीं करती। [2]

ज़रूरी कार्य-प्रमाण मिलने पर सॉफ़्टवेयर पूरा ब्लॉक submitblock के जरिए जमा कर सकता है। hexdata में पूरा सीरियलाइज़ किया हुआ ब्लॉक हेक्साडेसिमल में होता है, केवल हेडर या छाप नहीं। Bitcoin Core 29 के दस्तावेज़ स्वीकार होने पर null और अन्य मामलों में विनिर्देश के अनुसार पाठ वाला परिणाम बताते हैं। वैकल्पिक दूसरा पैरामीटर dummy अनदेखा किया जाता है; उससे इनाम तय नहीं होता। नोड का स्वीकार करना स्थायी पुष्टि की गारंटी नहीं: आगे चेन का विकास बदल सकता है कि कौन-सी शाखा मुख्य रहेगी। [5]

नया शुरू हुआ नोड शायद अभी ज़रूरी इतिहास डाउनलोड और सत्यापित न कर पाया हो। मुख्य नेटवर्क mainnet पर Bitcoin Core v29.0 जुड़े हुए दूसरे नोड न होने पर, या शुरुआती सिंक्रोनाइज़ेशन IBD (initial block download) के दौरान, टेम्पलेट देने से मना करता है। यह वर्तमान नेटवर्क के साथ काम करने की नोड की तैयारी का सवाल है, किसी खास ब्लॉक को ठुकराने का नहीं। इसलिए समस्या खोजते समय प्रतीक्षा कर रहे long poll, तैयार न हुए नोड और प्रस्ताव की जाँच के परिणाम में अंतर करना चाहिए। सब बाहर से “नया काम नहीं मिला” जैसे लग सकते हैं, पर हर स्थिति का समाधान अलग है। [2]