Block Template, Bitcoin नेटवर्क में नए ब्लॉक का उम्मीदवार तैयार करने के लिए जानकारी का समूह है। इसके बाद ही माइनर उसके हेडर, यानी ब्लॉक डेटा के संक्षिप्त सार, के लिए मान्य कार्य-प्रमाण खोजता है। टेम्पलेट चुने गए लेनदेन, पुरस्कार और निर्माण नियमों को जोड़ता है। इसे मिल जाने का अर्थ यह नहीं कि ब्लॉक माइन हो चुका है या नेटवर्क ने स्वीकार कर लिया है।
हर नया ब्लॉक एक खास पिछले ब्लॉक के आगे बनता है। टेम्पलेट में previousblockhash उस पिछले ब्लॉक की विशिष्ट पहचान देता है, जबकि height प्रस्तावित ब्लॉक की चेन में स्थिति बताता है। दूसरे फ़ील्ड में version, यानी हेडर का संस्करण, bits, यानी माइनिंग परिणाम के लक्ष्य का छोटा कूटबद्ध रूप, और समय की जानकारी होती है। यह किसी खास ब्लॉक को बनाने की सामग्री है, स्वतंत्र भुगतान सूची नहीं। वही लेनदेन किसी दूसरे पिछले ब्लॉक के आगे रखे जाएँ, तो काम भी अलग हो जाता है। [1]
अन्ना बिटकॉइन प्राप्त करती है और फिर उससे भुगतान करती है। यदि दोनों हस्तांतरण एक ही ब्लॉक में आने हैं, तो पहले वह लेनदेन होना चाहिए जिसने उसे धन दिया, और फिर वह जो उसे खर्च करता है। टेम्पलेट का प्रारूप समझाने वाला तकनीकी दस्तावेज़ BIP 22 ऐसे संबंधों के लिए depends फ़ील्ड तय करता है। यह transactions सूची की पहले की प्रविष्टियों को एक से शुरू होने वाले क्रमांक से संदर्भित करता है। सूची में coinbase शामिल नहीं है; वह माइनर का पुरस्कार आवंटित करने वाला विशेष पहला लेनदेन है। depends का न होना अज्ञात निर्भरताओं का संकेत है, उनके न होने की पुष्टि नहीं। सॉफ़्टवेयर इसे खाली सूची नहीं मान सकता। [1]
पुरस्कार में उस ऊँचाई के नियमों के अनुसार नए जारी बिटकॉइन और वास्तव में शामिल लेनदेनों की फ़ीस आती है। यहाँ संदर्भित Bitcoin Core v29.0 भी पुरस्कार की गणना ऐसे ही करता है। यह सॉफ़्टवेयर ब्लॉक और लेनदेन की जाँच करता है और माइनिंग के लिए टेम्पलेट भी तैयार कर सकता है। हमारे उदाहरण में लेनदेन 10000 sats फ़ीस देते हैं। 3000 sats फ़ीस वाला स्वतंत्र लेनदेन हटाने पर 7000 sats बचते हैं। Sats बिटकॉइन की छोटी इकाइयाँ हैं। coinbasevalue फ़ील्ड बताता है कि मूल लेनदेन चयन के आधार पर माइनर अपने लिए अधिकतम कितना पुरस्कार रख सकता है। चयन बदलने पर इस रकम की फिर से गणना करनी होती है। गणना वास्तविक फ़ीस पर होनी चाहिए, पुराने डेटा के लिए निकाले कुल पर नहीं। [4] [1]
ब्लॉक में डेटा जाँचने के लिए क्रिप्टोग्राफ़िक पहचानें भी होती हैं। BIP 141 का witness commitment, witness डेटा को एक निश्चित क्रिप्टोग्राफ़िक पहचान से बाँधता है। इस डेटा में, उदाहरण के लिए, खर्च की अनुमति साबित करने वाले हस्ताक्षर होते हैं। यह उन wtxid पहचानकर्ताओं से बनता है जिनमें यह डेटा शामिल है। Bitcoin Core 29 बिना बदले टेम्पलेट के लिए default_witness_commitment देता है। संबंधित लेनदेन या उनका क्रम बदलने पर इस मान को जाँचना या दोबारा गणना करना होता है। हेडर में लेनदेनों की संयुक्त पहचान Merkle root की गणना भी अंतिम TXID पहचानकर्ताओं से करनी होती है, जिनमें बदली हुई coinbase का पहचानकर्ता शामिल है। बदली हुई सामग्री पर पुरानी मुहर सही नहीं होती। [5] [3]
ब्लॉक में जगह सीमित है और माइनर चुनता है कि क्या शामिल करना है। Bitcoin Core v29.0 जुड़े हुए लेनदेनों के समूह, डेटा के भार को मापने वाला उनका वज़न, और sigops देखता है, यानी हस्ताक्षर जाँच की वे क्रियाएँ जिन्हें ब्लॉक की सीमा में गिना जाता है। blockmaxweight और blockmintxfee जैसी सेटिंग बन रहे ब्लॉक के आकार और आवश्यक फ़ीस दर को प्रभावित करती हैं। यह चयन की नीति है। इस कारण छोड़ा गया भुगतान नेटवर्क के नियमों के अनुसार अमान्य हो, यह ज़रूरी नहीं। माइनर की सेटिंग दूसरे नोडों द्वारा जाँची जाने वाली नेटवर्क सीमाएँ भी नहीं बढ़ाती। [4] [3]
BIP 23 में mutable उन बदलावों की सूची है जिन्हें सर्वर अनुमति देता है, जैसे समय बदलना या लेनदेन जोड़ना। यह किसी खास टेम्पलेट पर काम करने का समझौता है। सर्वर की अनुमति आम सहमति के नियम नहीं हटाती, यानी वे वैधता नियम जिन्हें बाकी प्रतिभागी स्वतंत्र रूप से जाँचते हैं। पिछला ब्लॉक, समय, कठिनाई और लेनदेन अब भी सही होने चाहिए। टेम्पलेट तक पहुँच का अर्थ यह भी नहीं कि हर जुड़ा उपकरण उसकी सामग्री मनमाने ढंग से बदल सकता है; यह व्यवस्था और मिले हुए काम पर निर्भर है। [2]
गणना के दौरान दूसरा माइनर चेन को आगे बढ़ा सकता है। सबसे नए स्वीकार किए गए ब्लॉक के आगे काम जारी रखने के लिए पुराने टेम्पलेट में केवल पिछले ब्लॉक की पहचान बदलना पर्याप्त नहीं है। कुछ लेनदेन पहले ही पुष्ट हो चुके होंगे, और ऊँचाई तथा दूसरी शर्तें बदलती हैं। BIP 23 में expires काम की समय-सीमा और prevblock उसे किसी दूसरे पिछले ब्लॉक के साथ इस्तेमाल करने की अनुमति बताता है। यह अनुमति भी सत्यापन का विकल्प नहीं: लेनदेन, पुरस्कार और पूरे नए संदर्भ को फिर से परखना होता है। [2]
अपने मसौदे की गलती लंबी खोज से पहले मिलना बेहतर है। BIP 23 का proposal मोड बिना मान्य Proof of Work के मसौदा जँचवाने देता है। यानी आवश्यक गणना-कार्य साबित करने वाला परिणाम पहले से मिला होना ज़रूरी नहीं। सकारात्मक आकलन का मतलब यह नहीं कि ब्लॉक मिल गया, प्रसारित हो गया या चेन में उसकी स्थायी जगह पक्की हो गई। इसका अर्थ है कि मसौदे ने संबंधित प्रारंभिक जाँच पार की। पूरा ब्लॉक भेजते समय उसे कार्य-प्रमाण समेत उचित सत्यापन से गुजरना होगा। [2]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Mining Pool, Block Header, Extranonce, Merkle Tree, Bitcoin, Bitcoin Core. इस प्रविष्टि का उल्लेख यहाँ भी है कॉइनबेस लेनदेन, ASIC Miner, Mining Pool, Nonce.