CPFP (Child Pays for Parent)

Anna को 100 000 sat मिलने हैं। sat, satoshi का संक्षिप्त रूप है, जो बिटकॉइन की सबसे छोटी इकाई है। भुगतान दिखाई दे रहा है, लेकिन भेजने वाले ने कम फ़ीस रखी थी और ट्रांज़ैक्शन अभी ब्लॉक में नहीं आई है। Anna का वॉलेट इस अपुष्ट आउटपुट को खर्च करने देता है। वह उससे अपने पते पर एक नई ट्रांज़ैक्शन बनाती है और अधिक फ़ीस देती है। वह न भेजने वाले को पैसे दे रही है, न किसी विशेष सेवा को इनाम; यह बिटकॉइन की सामान्य ट्रांज़ैक्शन फ़ीस है। माइनर मूल ट्रांज़ैक्शन के बिना नई को कन्फ़र्म नहीं कर सकता, क्योंकि मूल ट्रांज़ैक्शन के बिना जाँची जा रही चेन में वह आउटपुट मौजूद नहीं होगा जिसे नई ट्रांज़ैक्शन खर्च करती है। Parent या तो पहले से कन्फ़र्म हो, या उसी ब्लॉक में child से पहले आए। ज़रूरी अन्य अपुष्ट पूर्ववर्ती ट्रांज़ैक्शन भी पहले शामिल होनी चाहिए। उलटी शर्त नहीं है: parent, child के बिना भी कन्फ़र्म हो सकती है। [3] [5]

एक सरल उदाहरण लें जिसमें कोई और अपुष्ट पूर्ववर्ती ट्रांज़ैक्शन नहीं है। Parent का आकार 200 vB और फ़ीस 200 sat है। वर्चुअल बाइट, vB, ट्रांज़ैक्शन के वज़न से निकली आकार की इकाई है; sat/vB बताता है कि ऐसी हर इकाई के लिए कितने satoshi दिए जा रहे हैं। Child का आकार 100 vB है और Anna उसके लिए 2 800 sat देती है। अगर child में केवल एक आउटपुट हो, तो मिले हुए 100 000 sat में से 97 200 sat बचेंगे। दोनों मिलकर 300 vB के लिए 3 000 sat देती हैं, यानी 10 sat/vB। अकेली child की दर 28 sat/vB है, लेकिन माइनर को कम फ़ीस वाली parent भी शामिल करनी है। केवल child की ऊँची दर देखने से यह निर्भरता छूट जाती है। यह समझाने के लिए गणना है, आज की सुझाई गई दर नहीं; वास्तविक आकार और ज़रूरी कुल फ़ीस वॉलेट जाँचता है। दूसरे ज़रूरी पूर्ववर्ती लेनदेन हों तो हिसाब बदलेगा। गहराई से समझने वाली एक बात: किसी पैकेज को स्थानीय रूप से स्वीकार करते समय पहले से स्वीकार की गई ट्रांज़ैक्शन दोबारा नहीं गिनी जातीं और नोड समायोजित फ़ीस का उपयोग कर सकता है। नोड वह प्रोग्राम है जो लेनदेन जाँचता है और उन्हें आगे भेजता है। इसलिए वहाँ दिखी दर, माइनर के लिए की गई इस सरल संयुक्त गणना से अलग हो सकती है। यह समायोजित फ़ीस नोड के फैसलों के लिए स्थानीय मान है; इससे ट्रांज़ैक्शन द्वारा वास्तव में दी गई फ़ीस नहीं बदलती। [3]

CPFP ऐसा बटन नहीं है जिससे कोई भी किसी और की ट्रांज़ैक्शन तेज़ कर दे। आपके पास parent का कोई आउटपुट खर्च करने का अधिकार होना चाहिए और हस्ताक्षरों समेत उसकी शर्तें पूरी करनी होंगी। Anna पाने वाली के रूप में ऐसा कर सकती है; भेजने वाला शायद अपनी बची हुई रकम लौटाने वाले आउटपुट का उपयोग कर सके, जिसे change कहते हैं। एक्सप्लोरर या Watch-only Wallet में रकम दिखना भर काफ़ी नहीं है। Watch-only Wallet भुगतान देखने के लिए है; उसमें रकम खर्च करने के लिए ज़रूरी निजी कुंजियाँ नहीं रखी जातीं। वॉलेट को अपुष्ट आउटपुट खर्च करने का समर्थन भी करना चाहिए। हस्ताक्षर करने से पहले देखें कि कौन-सा आउटपुट खर्च हो रहा है, पैसे कहाँ जाएँगे, कितने बचेंगे और कुल फ़ीस क्या होगी। आउटपुट छोटा हो तो फ़ीस उसके मूल्य का बड़ा हिस्सा खा सकती है। [5]

Replace-by-Fee (RBF) एक नई टकराने वाली ट्रांज़ैक्शन बनाता है, जिसका उद्देश्य मूल को बदलना है। वह कम से कम एक वही इनपुट खर्च करती है, लेकिन सारे इनपुट का समूह बिल्कुल एक जैसा होना ज़रूरी नहीं है। CPFP मूल भुगतान और उसका पहचानकर्ता बरकरार रखकर एक और ट्रांज़ैक्शन जोड़ता है। RBF के लिए प्रतिस्थापन के इनपुट की शर्तें पूरी करनी होती हैं; सामान्य CPFP के लिए मूल भुगतान के आउटपुट की शर्तें। इसलिए पाने वाला CPFP कर सकता है, भले ही वह भेजने वाले की प्रतिस्थापन ट्रांज़ैक्शन पर हस्ताक्षर न कर सके। किसी दूसरे, स्वतंत्र भुगतान पर बड़ी फ़ीस देने से मदद नहीं होती: child को वास्तव में प्रतीक्षा कर रहे भुगतान पर निर्भर होना चाहिए। [3]

ऊँची संयुक्त दर माइनर को दोनों ट्रांज़ैक्शन चुनने की बेहतर वजह देती है, लेकिन अगले ब्लॉक में जगह आरक्षित नहीं करती। अधिक फ़ीस देने वाली ट्रांज़ैक्शन आ सकती हैं या पैकेज कुछ माइनरों तक पहुँच ही न पाए। इसलिए मूल भुगतान और child, दोनों की पुष्टि पर नज़र रखें। नोड द्वारा स्वीकार किए जाने की सूचना, ब्लॉक में पुष्टि नहीं है। अगर भेजने वाला RBF से मूल भुगतान बदल दे, तो पुराने आउटपुट का संदर्भ देने वाली child अपने आप अलग नई ट्रांज़ैक्शन से नहीं जुड़ सकती; स्थिति फिर से देखनी होगी। Child बनाना भी अपुष्ट आने वाली रकम को पक्का भुगतान नहीं बना देता। [3]

आगे के भाग अधिक गहराई से पढ़ने या अपना नोड चलाने वालों के लिए नियम समझाते हैं। Mempool किसी एक नोड की प्रतीक्षारत ट्रांज़ैक्शन की सूची है, पूरे नेटवर्क की साझा कतार नहीं। पैकेज साथ में भेजी गई ट्रांज़ैक्शन का समूह है। तीन निर्णय अलग रखें: क्या ट्रांज़ैक्शन वैध है, क्या नोड उसे स्वीकार करता है और क्या माइनर उसे चुनता है। सहमति लेनदेनों और ब्लॉकों की वैधता तय करती है। mempool नीति स्थानीय स्वीकृति और रिले तय करती है; माइनर के नियम उम्मीदवार ब्लॉक के लिए चयन तय करते हैं। CPFP सहमति नहीं बदलता। आर्थिक रूप से आकर्षक पैकेज स्थानीय नियमों का उल्लंघन कर सकता है, और एक नोड की स्वीकृति दूसरे नोडों या माइनरों को बाध्य नहीं करती। [3] [5]

Parent और child को साथ आगे भेजने के तरीके विकसित हो रहे हैं। Package CPFP का अर्थ है जुड़ी हुई ट्रांज़ैक्शन को पैकेज की तरह परखना। RPC नोड से काम कराने का कमांड है; minrelaytxfee सामान्य प्रसारण के लिए नोड की न्यूनतम दर का नाम है। TRUC ट्रांज़ैक्शन के लिए विशेष नियम हैं, जो पूर्ववर्ती और बाद में जुड़ने वाली ट्रांज़ैक्शन के संबंध सीमित करते हैं। नीचे का इतिहास Bitcoin Core के बताए गए संस्करणों से जुड़ा है। Bitcoin Core 26 ने submitpackage RPC और package CPFP जोड़ा। चाइल्ड ट्रांज़ैक्शन, यानी बाद की ट्रांज़ैक्शन, उस पैरेंट की मदद कर सकती थी जिसकी फ़ीस दर mempool की बदलती न्यूनतम दर से कम थी। लेकिन उस समय पैरेंट की दर सामान्य प्रसारण की न्यूनतम दर से कम नहीं हो सकती थी। यह सीमा स्थायी नहीं है। Core 31 में समर्थित एक पैरेंट और एक चाइल्ड वाले पैकेज के प्रसारण में पैरेंट की दर minrelaytxfee से कम हो सकती है, यहाँ तक कि उसकी फ़ीस शून्य भी हो सकती है। यह TRUC के अलावा दूसरी ट्रांज़ैक्शन पर भी लागू होता है। चाइल्ड के दूसरे अपुष्ट पैरेंट पहले से mempool में होने चाहिए। स्थानीय स्वीकृति अब भी पूरे नेटवर्क में समान प्रसार की गारंटी नहीं देती। [1] [2]

नोड किसी भी आकार का निर्भरता-जाल स्वीकार नहीं कर सकता। पूर्ववर्ती ट्रांज़ैक्शन दूसरी से पहले ज़रूरी होती है; वंशज ट्रांज़ैक्शन इस श्रृंखला में आगे के आउटपुट खर्च करती है। WU ट्रांज़ैक्शन के वज़न की इकाइयाँ हैं और टोपोलॉजी बताती है कि ट्रांज़ैक्शन आपस में कैसे जुड़ी हैं। ये तकनीकी सीमाएँ संबंधित नोड संस्करण की नीति का हिस्सा हैं। सीमाएँ मेमोरी, प्रोसेसर की क्षमता और बैंडविड्थ बचाती हैं। पुराने Core संस्करण पूर्वजों और वंशजों की संख्या तथा आकार सीमित करते थे; Core 31 ने उन mempool सीमाओं को जुड़े cluster की सीमाओं से बदला। अलग पैकेज सीमाएँ बनी हुई हैं: Core 31 दस्तावेज अधिकतम 25 लेनदेन और कुल भार 404000 WU बताते हैं। भार आभासी आकार नहीं है। गलत संरचना, विरोध या स्वीकार्य लेनदेन के रूपों से जुड़े स्थानीय नियमों (standardness) का उल्लंघन पर्याप्त शुल्क के बावजूद CPFP रोक सकता है। [2] [3]

आपस में जुड़ी अपुष्ट ट्रांज़ैक्शन का आर्थिक आकलन हमेशा अलग-अलग नहीं हो सकता। Cluster Mempool नोड को उनके जुड़े समूह देखने देता है। Cluster पूरा जुड़ा समूह है; ट्रांज़ैक्शन चुनते समय संसाधित छोटा समूह chunk कहलाता है। ये पहले से कन्फ़र्म ब्लॉक के टुकड़े नहीं हैं। Bitcoin Core 31 में Cluster Mempool है: cluster में पैरेंट–चाइल्ड संबंधों को किसी भी दिशा में जोड़कर बनने वाले लेनदेन होते हैं। प्रति cluster डिफ़ॉल्ट सीमाएँ 64 लेनदेन और 101 kB आभासी आकार हैं; इन्हें बदला जा सकता है। क्रम साथ में माइन किए जाने वाले chunks नामक समूहों और उनकी दरों को ध्यान में रखता है। ऐतिहासिक CPFP carveout वंशज सीमा से सीमित छूट देता था; Core 31 ने उसे हटा दिया और इस तरह cluster की लेनदेन संख्या सीमा पार नहीं की जा सकती। [2] [4]

इस भाग के कमांड एक-दूसरे के बदले नहीं चलाए जा सकते। टेस्ट केवल नतीजा बता सकता है; पैकेज भेजने पर हस्ताक्षरित ट्रांज़ैक्शन वास्तव में स्वीकार और आगे प्रसारित हो सकती हैं। vsize फ़ील्ड वर्चुअल आकार बताती है। सामान्य वॉलेट ये बारीकियाँ उपयोगकर्ता की ओर से संभाल सकता है। Core 31 में getmempoolentry RPC उस नोड के mempool में मौजूद ट्रांज़ैक्शन का शुल्क, vsize, निर्भरताएँ और chunk डेटा दिखाता है; getmempoolcluster संबंधित cluster दिखाता है। testmempoolaccept RPC स्वीकृति या प्रसारण के बिना स्थानीय परीक्षण करता है; कई लेनदेनों में पूर्ववर्ती लेनदेन उन पर निर्भर लेनदेन से पहले होने चाहिए और लेनदेन आपस में या mempool से विरोध नहीं कर सकते। submitpackage RPC समर्थित पैकेज को वास्तव में mempool स्वीकृति और रिले के लिए प्रस्तुत करता है, केवल परीक्षण नहीं करता। हर लेनदेन के परिणाम, संस्करण और कॉन्फ़िगरेशन जाँचें; कोई परिणाम ट्रांज़ैक्शन के ब्लॉक में शामिल होने की गारंटी नहीं देता। [2] [6] [7] [8] [9]