Gloria Zhao

Gloria Zhao ने 4 जनवरी 2021 को Brink की पहली फ़ेलो के रूप में काम शुरू किया। 2022 में वह Bitcoin Core मेंटेनर बनीं, यानी स्रोत कोड और विकास प्रक्रिया की देखरेख करने वाले लोगों में शामिल हुईं। यह एक खास सॉफ़्टवेयर की ज़िम्मेदारी है, Bitcoin का नेतृत्व सौंपे जाने जैसी बात नहीं। इस संशोधन के दौरान देखी गई Brink की पूर्व प्रतिभागियों की सूची उन्हें पूर्व मेंटेनर बताती है। इसलिए जीवन परिचय में तारीखें देखना ज़रूरी है: पुरानी नियुक्ति की खबर किसी का आज का पद साबित नहीं करती। [1] [2]

अच्छे कोड को भी दूसरे लोगों की जाँच चाहिए। Zhao ने Bitcoin Core PR Review Club में काम किया, जहाँ नए योगदानकर्ता प्रस्तावित बदलाव पढ़ना और उनके असर समझना सीखते हैं। PR, यानी pull request, परियोजना में बदलाव शामिल करने का अनुरोध है। क्लब यह समझने में मदद करता है कि बदलाव कौन-सी समस्या हल करता है और उसकी समीक्षा कैसे करें; उसका मुख्य लक्ष्य किसी खास PR को मिलवाना नहीं है। चर्चा सीखने और तैयारी का हिस्सा है, कोड या किसी संस्करण को अपने-आप मंज़ूरी देने का तरीका नहीं। [2] [3]

Mempool पूरे नेटवर्क की एक साझा कतार नहीं है। हर नोड तय करता है कि कौन-से अपुष्ट लेनदेन स्वीकार करे और आगे भेजे; इसमें फ़ीस और संसाधनों पर अत्यधिक भार से बचाव जैसी बातें आती हैं। यह स्थानीय नीति है। यह उन सहमति नियमों से अलग है जिनसे ब्लॉक की वैधता जाँची जाती है। Zhao ने 6 जून 2025 के डेवलपर वक्तव्य पर हस्ताक्षर किए, जो उपयोगकर्ता के सॉफ़्टवेयर चुनने पर ज़ोर देता है। डेवलपर दूसरी नीति सुझा सकता है, लेकिन हस्ताक्षर या कोड रिपॉज़िटरी की देखरेख का अधिकार दूसरों के नोड का सॉफ़्टवेयर नहीं बदल देता। [4]

कोई लेनदेन दूसरे ऐसे लेनदेन की रकम खर्च कर सकता है जिसकी अभी पुष्टि नहीं हुई। पहले को parent और उस पर निर्भर अगले को child कहते हैं। Zhao का BIP 331, Package Relay का प्रस्ताव है: संबंधित लेनदेन को एक पैकेज में भेजना। नोड sendpackages से समर्थन पर सहमत होंगे, पहले ज़रूरी पूर्ववर्ती लेनदेन की जानकारी लेंगे और फिर उनका डेटा प्राप्त करेंगे। इससे हर गायब कड़ी को अलग खोजने की मेहनत घटेगी। दस्तावेज़ की स्थिति Draft, यानी मसौदा है; उसका मौजूद होना पूरे नेटवर्क में प्रोटोकॉल के पूरी तरह लागू होने का प्रमाण नहीं। [5]

मान लें कि आपको बहुत कम फ़ीस वाला अपुष्ट भुगतान मिला। अगर आप उसका आउटपुट खर्च कर सकते हैं, तो ज़्यादा फ़ीस वाला अगला लेनदेन बना सकते हैं। यही CPFP, Child Pays for Parent है: child की फ़ीस पाने के लिए माइनर को parent भी शामिल करना होगा, इसलिए वह दोनों का लाभ साथ देख सकता है। लेकिन जिस नोड के पास parent नहीं है, वह सामान्यतः child को अकेले स्वीकार नहीं कर सकता। BIP 331 इसी तरह की प्रसारण बाधा पर काम करता है। ज़्यादा फ़ीस भी वैध हस्ताक्षर और इनपुट की जगह नहीं लेती, न किसी तय समय तक पुष्टि की गारंटी देती है। [5]

Bitcoin Core 28.0 ने सीमित 1P1C प्रक्रिया शुरू की, यानी एक parent और एक child। मौजूदा P2P संचार, अर्थात नोडों के बीच सीधे आदान-प्रदान, से उपयुक्त लेनदेन को जोड़कर साथ परखा जा सकता था। यह ठोस सुधार है, लेकिन BIP 331 का पूरा लागू होना नहीं। संस्करण विवरण स्पष्ट कहता है कि इस नेटवर्क प्रक्रिया में कई अपुष्ट parents वाले child का समर्थन नहीं है और हमले की स्थिति में यह अभी विश्वसनीय नहीं है। प्रसारण पर निर्भर वॉलेट बनाते समय किसी संस्करण की सीमित सुविधा और व्यापक प्रस्ताव का अंतर समझना ज़रूरी है। [5] [6]

हमलावर mempool की सीमाओं का फायदा उठाकर लेनदेन बदलना या उसकी फ़ीस बढ़ाना मुश्किल कर सकता है। इसे pinning कहते हैं। TRUC नीति पुष्टि होने तक लेनदेन की आपसी निर्भरता सीमित करती है, जिससे उन्हें स्वीकार करने या बदलने का निर्णय सरल हो। Bitcoin Core 28.0 ने इसे nVersion=3 वाले लेनदेन के लिए शुरू किया। Zhao का BIP 431 इस तरीके को Draft स्थिति वाले सूचनात्मक दस्तावेज़ में समझाता है। अपुष्ट पूर्ववर्ती और बाद के निर्भर लेनदेन सीमित करने से मदद मिलती है, लेकिन सुरक्षा अन्य नोडों के इस नीति को अपनाने पर भी निर्भर है। यह हर pinning से बचाव या समय पर ब्लॉक में शामिल होने की गारंटी नहीं है। [6] [7]

कोई ऐप submitpackage से अपने नोड को पैकेज दे सकता है। Bitcoin Core 28.0 के दस्तावेज़ बताते हैं कि नोड से संवाद करने वाले RPC इंटरफ़ेस का यह कमांड सहमति नियमों और mempool नीति दोनों की जाँच करता है। जाँच में सफल लेनदेन स्वीकार हो सकते हैं, भले ही पैकेज का दूसरा हिस्सा असफल हो जाए। इसलिए त्रुटि आने पर पूरा परिणाम वापस होना ज़रूरी नहीं। समग्र package_msg और अलग-अलग tx-results, दोनों पढ़ने चाहिए। स्थानीय सफलता भी नहीं बताती कि पैकेज पूरे नेटवर्क तक पहुँच गया या उसके लेनदेन ब्लॉक में आ गए। [8]