Mining Target वह संख्या है जिससे ब्लॉक हेडर के हैश की तुलना होती है। हेडर ब्लॉक के मुख्य डेटा का संक्षिप्त सार है। वैध कार्य-प्रमाण के लिए हैश सही लक्ष्य से अधिक नहीं होना चाहिए। Bitcoin नेटवर्क में लक्ष्य धनात्मक और उस ब्लॉक के नियमों के अनुरूप होना चाहिए; माइनर इसे मनमाने ढंग से नहीं चुन सकता।
सिर्फ़ समझाने के लिए सीमा 20 मानो: परिणाम 19 और 20 स्वीकार होंगे, 21 नहीं। असली माइनिंग की संख्याएँ बहुत बड़ी होती हैं, लेकिन संबंध वही है: hash ≤ target। चिह्न का अर्थ है छोटा या बराबर, सिर्फ़ सख्ती से छोटा नहीं। Bitcoin Core वह सॉफ़्टवेयर है जिससे नेटवर्क के सहभागी ब्लॉक और लेनदेन की जाँच करते हैं। यहाँ संदर्भित संस्करण v29.0 भी पूरे हेडर के हैश की ऐसी तुलना करता है। Nonce, जिसे माइनर खोज के दौरान बदलता है, एक इनपुट है। लक्ष्य से तुलना गणना के बाद मिले हैश की होती है। [1]
याना किसी सफल हैश की तस्वीर देखती है जिसकी शुरुआत बहुत से शून्यों से होती है। यह उपयोगी चित्रण है: समान लंबाई के लेखन में अधिक शुरुआती शून्य का अर्थ छोटी संख्या है। लेकिन बराबर शुरुआती शून्यों वाले दो हैश लक्ष्य के अलग-अलग ओर हो सकते हैं। बाकी अंक भी मायने रखते हैं। इसलिए शून्य गिनना पूरी तुलना hash ≤ target की जगह नहीं लेता। नियम किसी सुंदर अक्षर-पैटर्न की प्रतियोगिता नहीं, एक सटीक संख्यात्मक शर्त है। [1]
बिट शून्य या एक दर्ज करता है; आठ बिट मिलकर एक बाइट बनाते हैं। पूरी लंबी संख्या हेडर में रखने के बजाय Bitcoin 32 बिट का nBits फ़ील्ड इस्तेमाल करता है। यह 256 बिट की संख्याओं के दायरे में लक्ष्य को गुणांक, खिसकाव तय करने वाले घातांक और चिह्न के बिट से कूटबद्ध करता है। उदाहरण के लिए 0x04123456 खोलने पर 0x12345600 बनता है। शुरुआत का 0x बताता है कि यह हेक्साडेसिमल, यानी सोलह-आधारी लेखन है जिसमें अक्षर भी आते हैं। यह कूटबद्ध करने का उदाहरण है, नेटवर्क का मौजूदा लक्ष्य नहीं। बुनियादी समझ के लिए संख्या और उसके छोटे लेखन में अंतर करना काफ़ी है। [3] [5]
कच्चे डेटा में वही संख्या उलटी दिख सकती है। 80 बाइट के हेडर में nBits चार बाइट लेता है, जो little-endian क्रम में रखे जाते हैं: सबसे कम स्थान-महत्त्व वाला बाइट पहले आता है। इसलिए संख्या 0x1d00ffff डेटा में ff ff 00 1d दिखती है। बाइट का क्रम लक्ष्य नहीं बदलता, केवल रखने का तरीका बताता है। यह कच्चे डेटा पर काम करने का विवरण है; सामान्य ब्लॉक एक्सप्लोरर पढ़ते समय दिखाई गई संख्याएँ उलटने की ज़रूरत नहीं। [2]
याना सोच सकती है कि बड़ी संख्या लिख देने से खोज आसान हो जाएगी। लेकिन सॉफ़्टवेयर सिर्फ़ यह नहीं जाँचता कि वह nBits पढ़ सकता है या नहीं। Bitcoin Core v29.0 में DeriveTarget ऋणात्मक लक्ष्य, शून्य, संख्या की सीमा से बाहर जाने वाला ओवरफ़्लो और powLimit से बड़ी संख्या को अस्वीकार करता है। powLimit उस नेटवर्क का सबसे बड़ा अनुमत लक्ष्य है। सफल डिकोडिंग केवल यह बताती है कि लेखन किस संख्या का प्रतिनिधित्व करता है; वह उसे इस्तेमाल करने की अनुमति नहीं देती। [1]
अनुमत दायरे का लक्ष्य भी किसी खास ब्लॉक के लिए गलत हो सकता है। Bitcoin Core nBits की तुलना GetNextWorkRequired से करता है, जो पिछले ब्लॉक और नेटवर्क के नियमों पर आधारित गणना है। मेल न होने पर bad-diffbits आता है। अपने चुने हुए आसान लक्ष्य के नीचे का हैश हेडर के गलत मान को सही नहीं बनाता। याना केवल शर्तें आसान करके स्वीकार किया जाने वाला ब्लॉक नहीं बना सकती: दूसरे नोड, यानी नियमों की जाँच करने वाले कंप्यूटर, कोशिश अस्वीकार कर देंगे। [4]
समान रूप से वितरित 256 बिट हैश के मॉडल में हर संभव परिणाम की संभावना समान होती है। अनुमत लक्ष्य T के लिए शून्य से T तक, दोनों छोर सहित, मान स्वीकार होते हैं। इसलिए एक कोशिश पर p = (T + 1) / 2^256 होता है; p सफलता की संभावना है। अंश में एक जोड़ने का कारण यह है कि शून्य भी गिना जाए। यह संबंध समझाता है कि छोटा लक्ष्य खोज कठिन क्यों करता है। लेकिन यह नहीं बताता कि मशीन हर सेकंड कितनी कोशिशें करेगी या अगला ब्लॉक ठीक कब आएगा। [1]
शर्त पूरी करने पर याना ने ज़रूरी गणना-कार्य साबित किया है, ब्लॉक के अंदर हर चीज़ की शुद्धता नहीं। Bitcoin Core लेनदेन का संयुक्त डिजिटल निशान, coinbase नाम का विशेष इनाम-लेनदेन, ब्लॉक की सीमाएँ और लेनदेन की वैधता भी जाँचता है। यहाँ coinbase ब्लॉक के पहले लेनदेन का तकनीकी नाम है, एक्सचेंज का नहीं। छोटा हैश अमान्य सामग्री को ठीक नहीं कर सकता। लक्ष्य नियमों का अहम हिस्सा है, बाकी नियमों को छोड़ने की अनुमति नहीं। [4]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Share Difficulty, Proof of Work, Nonce, Block Header, Bitcoin. इस प्रविष्टि का उल्लेख यहाँ भी है ASIC Miner, Nonce, Mining Share, Share Difficulty.