Compact Block Filters

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

पुराने BIP 37 तरीके में क्लाइंट जिन डेटा पर नज़र रखना चाहता था, उनसे फ़िल्टर बनाकर जुड़े हुए दूसरे नोड को भेजता था। यहाँ दिशा उलटी है: सर्वर ब्लॉक का फ़िल्टर देता है और अन्ना अपने वॉलेट में खोजती है। एक ही ब्लॉक और फ़िल्टर प्रकार के लिए सभी क्लाइंट को समान सामग्री मिलती है। इसलिए हर सर्वर को खोजे जाने वाले स्क्रिप्ट सीधे बताना नहीं पड़ता। फिर भी गुमनामी की गारंटी नहीं है: दूसरा नोड IP पता, जुड़ने का समय और बाद में माँगे गए पूरे ब्लॉक देख सकता है। अलग-अलग नोड से डाउनलोड करने पर एक जगह जुटने वाली जानकारी घटती है, लेकिन उसे आपस में जोड़ने की हर संभावना समाप्त नहीं होती। [1]

Compact Block Filters जाँचने योग्य ब्लॉक चुनते हैं। BIP 152 के Compact Blocks अलग समस्या हल करते हैं: ब्लॉक भेजते समय उन लेनदेन के छोटे पहचानकर्ता इस्तेमाल करके डेटा बचाते हैं जिन्हें प्राप्तकर्ता अक्सर पहले से जानता है। वह उन्हें अपने Mempool, यानी स्थानीय अपुष्ट लेनदेन के संग्रह से लेता है और जो नहीं हैं उन्हें मँगाता है। दोनों में से कोई साधन अपने आप Bitcoin के सभी नियमों की जाँच नहीं करता। Full Node, यानी पूर्ण नोड, नेटवर्क के नियमों के अनुसार ब्लॉक और लेनदेन स्वतंत्र रूप से जाँचता है। केवल हेडर और अपने लेनदेन का शामिल होना जाँचने वाला हल्का वॉलेट सीमित जाँच करता है। डेटा बचाना और सभी नियमों के अनुसार सत्यापन करना अलग गुण हैं। [1] [5]

BIP 158 प्रारूप तय करता है। basic फ़िल्टर में नए आउटपुट के खर्च की शर्तें बताने वाला स्क्रिप्ट scriptPubKey शामिल होता है, सिवाय OP_RETURN से शुरू होने वाले आउटपुट के। ब्लॉक में खर्च किए गए पुराने आउटपुट के स्क्रिप्ट भी शामिल होते हैं। इनपुट के मामले में अपवाद coinbase है: ब्लॉक का पहला लेनदेन, जो माइनर का पुरस्कार बाँटता है और सामान्य पुराने आउटपुट खर्च नहीं करता। उसके नए आउटपुट पर भी अन्य नए आउटपुट जैसे ही समावेशन के नियम लागू होते हैं। खाली प्रविष्टियाँ छोड़ दी जाती हैं। वॉलेट को पते को सही स्क्रिप्ट में बदलना चाहिए; उसके छपे हुए पाठ को खोजना पर्याप्त नहीं। फ़िल्टर txid यानी लेनदेन पहचानकर्ताओं, हस्ताक्षर जैसे witness डेटा या मनमाने नोट खोजने का सामान्य साधन नहीं है। [2] [3]

ब्लॉक डाउनलोड करने के बाद अन्ना को पता चल सकता है कि उसमें उसका कुछ नहीं है। ऐसा गलत मिलान छोटे फ़िल्टर की सामान्य कीमत है, अपने आप में खराबी का प्रमाण नहीं। तकनीकी रूप से प्रविष्टियों को संख्यात्मक फ़िंगरप्रिंट में बदलकर क्रम में रखा जाता है और उनके अंतर Golomb-Rice एन्कोडिंग से कम जगह में सहेजे जाते हैं। basic के लिए P=19 और M=784931 हैं। अनुपस्थित प्रविष्टि की एक खोज में मिलान की संभावना लगभग 1/M है; अधिक प्रविष्टियाँ देखने पर मिलान के अवसर भी बढ़ते हैं। यह पूरे वॉलेट की स्थिर त्रुटि दर नहीं है। सही बना फ़िल्टर शामिल प्रविष्टि को नहीं छोड़ता। लेकिन नकारात्मक परिणाम तभी भरोसेमंद है जब फ़िल्टर सही हो, डेटा का प्रकार शामिल हो और खोज सही हो। [2]

BIP 157 फ़िल्टर का आदान-प्रदान और उनके जुड़े हेडर तय करता है। हर हेडर मौजूदा फ़िल्टर के hash, यानी क्रिप्टोग्राफ़िक फ़िंगरप्रिंट, को पिछले हेडर से जोड़ता है। फ़िल्टर बदलने पर अपेक्षित संबंध टूट जाता है। लेकिन यह शृंखला Bitcoin ब्लॉक के हेडर का हिस्सा नहीं है और माइनिंग सीधे इसकी सामग्री को बाँधती नहीं। बेईमान नोड नकली फ़िल्टर और उनके साथ सही गणना वाले जुड़े फ़िंगरप्रिंट तैयार कर सकता है। इससे Bitcoin नहीं बदलता, लेकिन अलग-थलग क्लाइंट से जानकारी छिपाई जा सकती है। इसलिए गणितीय संबंध जाँचने के साथ मूल डेटा का सही होना भी जाँचना ज़रूरी है। [1]

BIP 157 कई नोड की तुलना और कम-से-कम एक ईमानदार स्रोत की मौजूदगी पर निर्भर करता है। असहमति होने पर क्लाइंट पहली अलग जगह खोजकर मूल डेटा से फ़िल्टर जाँच सकता है। basic बनाने के लिए केवल नया ब्लॉक पर्याप्त न हो: उसके लेनदेन जिन पुराने आउटपुट को खर्च करते हैं, उनके स्क्रिप्ट भी चाहिए। पुनर्गठन को अलग से संभालना होता है। इसमें नेटवर्क अधिक संचित कार्य वाली वैध ब्लॉक की दूसरी शाखा पर जाता है। वॉलेट को फ़िल्टर नई शाखा से जोड़कर इतिहास और शेष राशि बदलनी चाहिए। एक ही ऊँचाई, यानी शृंखला में एक ही क्रम, का अर्थ हमेशा एक ही ब्लॉक नहीं होता। [1] [3]

वॉलेट को उपलब्ध फ़िल्टर और चुने गए पूरे ब्लॉक पाने का रास्ता, दोनों चाहिए। नोड फ़िल्टर बनाने के बाद पुराने ब्लॉक हटा सकता है; तब दूसरा स्रोत उन्हें देगा। Bitcoin Core में सही इंडेक्स चालू होने पर getblockfilter किसी दिए गए ब्लॉक का फ़िल्टर और हेडर लौटाता है। आदेश उपलब्ध होने से यह साबित नहीं होता कि दूसरे नोड के लिए सार्वजनिक P2P सेवा या पूरा इतिहास भी उपलब्ध है। बने हुए ब्लॉक के फ़िल्टर Mempool के अपुष्ट लेनदेन की सूचना भी नहीं देते। लंबित भुगतान दिखाने के लिए ऐप को दूसरा तरीका चाहिए। इन्हीं कामकाजी बातों से तय होता है कि हल्का वॉलेट सचमुच अच्छा चलेगा या नहीं। [1] [4]