Collaborative Custody ऐसी व्यवस्था है जिसमें मालिक और कोई दूसरा व्यक्ति या सेवा मिलकर बिटकॉइन सुरक्षित रखते हैं। एक आम मॉडल में मालिक के पास स्वतंत्र भुगतान के लिए पर्याप्त कुंजियाँ होती हैं और परेशानी में सेवा मदद करती है। यह स्वतंत्रता वॉलेट के वास्तविक नियमों से मिलनी चाहिए, केवल उत्पाद के नाम से नहीं।
पीटर अपने वॉलेट से अपने बिटकॉइन का प्रबंधन करता है। उसे डर है कि कभी उपकरण या बैकअप खो सकता है। वॉलेट बिटकॉइन पाने और भेजने वाला ऐप या उपकरण है। यहाँ हस्ताक्षर करने का मतलब निजी कुंजी, यानी एक गुप्त संख्यात्मक मान, से भुगतान की अनुमति का जाँचा जा सकने वाला प्रमाण बनाना है। बाकी लोग वह गुप्त मान जाने बिना हस्ताक्षर जाँच सकते हैं। Unchained 2-of-3 व्यवस्था बताता है: भुगतान के लिए तीन में से दो कुंजियों के हस्ताक्षर चाहिए। पीटर के पास A और B हैं, सेवा के पास C। इसलिए A+B, A+C और B+C मान्य हैं; अकेली C पर्याप्त नहीं। कई हस्ताक्षरों की इस आवश्यकता को Multisig कहते हैं। पीटर सेवा के बिना भुगतान कर सकता है और एक कुंजी खोने पर मदद ले सकता है। लेकिन एक ही Seed Phrase, यानी शब्दों में लिखे उसी बैकअप से बहाल दो उपकरण स्वतंत्र नहीं होते: साझा रहस्य खुलने पर दोनों खतरे में पड़ते हैं। [1] [4] [8]
जब तक पीटर के पास काम करने वाली A+B और वॉलेट की पूरी जानकारी है, केवल सेवा बंद होने से उसकी भुगतान क्षमता नहीं जाती। सिर्फ A बची हो तो A+C के लिए सेवा चाहिए। उसकी अनुपलब्धता या हस्ताक्षर से इनकार बहाली रोक सकता है। A और B दोनों खो जाएँ तो अकेली C नहीं बचा सकती। इसलिए स्वतंत्र रूप से सेवा छोड़ने और सहायता से बहाली की जाँच अलग-अलग करनी चाहिए। Casa के अपने ढाँचे के बिना बहाली के निर्देश भी साफ़ मानते हैं कि सेवा की कुंजी उपलब्ध नहीं होगी। प्रक्रिया और उपकरण उत्पाद पर निर्भर हैं; “collaborative” शब्द से उनका पता नहीं चलता। [1] [6]
पीटर के पास बैकअप हैं, लेकिन दूसरे ऐप को पता होना चाहिए कि कौन-सा वॉलेट फिर से बनाना है। सामान्य 2-of-3 में सेवा सहित तीनों प्रतिभागियों की सार्वजनिक कुंजियाँ और उनके इस्तेमाल के नियम चाहिए। सार्वजनिक कुंजियाँ हस्ताक्षर जाँचती हैं; निजी कुंजियाँ उन्हें बनाती हैं। Output Descriptor सॉफ़्टवेयर द्वारा पढ़ा जाने वाला विन्यास है, जिसमें पते निकालने का तरीका भी शामिल है। अपनी दो Seed Phrase से प्रदाता की गायब सार्वजनिक कुंजी नहीं बन जाती। इसलिए पीटर सेवा चालू रहते ही निर्यात सहेजता और जाँचता है। साझा करने से पहले सामग्री देखता है: सामान्य descriptor प्रारूप में निजी कुंजियाँ भी हो सकती हैं। [4] [5]
समन्वयक लेनदेन की जानकारी जुटाता है; हस्ताक्षरकर्ता के पास उसे मंज़ूरी देने वाली कुंजी होती है। BIP 174 में बताया PSBT प्रारूप अधूरा लेनदेन और ज़रूरी जानकारी कार्यक्रमों तथा उपकरणों के बीच पहुँचाता है। फ़ाइल बनाने से गायब हस्ताक्षर नहीं मिल जाता। बिना कुंजी वाला समन्वयक भी दूसरा प्राप्तकर्ता सुझाकर नुकसान पहुँचा सकता है। हस्ताक्षर से पहले पता, रकम, शुल्क और change जाँचें—यानी अपने वॉलेट में वापस आने वाला बचा पैसा। Hardware Wallet कुंजी को कंप्यूटर से अलग रखने में मदद करता है; फिर भी उसकी स्क्रीन क्या जाँचने देती है और पीटर वास्तव में किसे मंज़ूरी देता है, यह महत्वपूर्ण है। [2] [3]
पहले भुगतान से पहले, साझा वॉलेट बनाते समय भी गलती हो सकती है। BIP 129 कुंजियाँ और विन्यास साझा करने की प्रक्रिया बताता है ताकि प्रतिभागी आवश्यक हस्ताक्षरों की संख्या, शामिल कुंजियाँ और पहला पता मिलाकर देख सकें। इसमें खर्च की शर्तें बताने वाली script का प्रकार और आगे की कुंजियाँ निकालने वाले derivation paths शामिल हैं। बदली हुई सेटिंग जमा राशि कहीं और भेज सकती है। लेकिन यह दस्तावेज़ उपकरण के भंडारण की छेड़छाड़-प्रतिरोध क्षमता या बाद में प्राप्ति और change पते की जाँच को खुद नहीं संभालता। मानक का समर्थन पूरे उत्पाद की सुरक्षा का प्रमाण नहीं है। [2]
XPUB एक विस्तारित सार्वजनिक कुंजी है जिससे वॉलेट की किसी शाखा की सार्वजनिक कुंजियाँ निकाली जाती हैं। यह जानकारी और विन्यास जानने वाला प्रदाता पर्याप्त हस्ताक्षर न होते हुए भी पते और भुगतान देख सकता है। उन्हें ग्राहक के नाम वाले खाते से जोड़ने पर पहचान का एक और संबंध बनता है। गोपनीयता और खर्च करने का अधिकार अलग सवाल हैं। सेवा अकेले भुगतान नहीं कर सकती—यह दावा भी शर्तों पर टिका है: वह पीटर की दूसरी कुंजी पा सकती है या उसे हानिकारक लेनदेन पर हस्ताक्षर करने के लिए धोखा दे सकती है। कम अधिकार कुछ जोखिम घटाते हैं, सभी नहीं। [2] [4]
पीटर कुंजी खो देता है और ऐप में नई बना लेता है। इससे पुरानी जमा राशि के लिए पुरानी कुंजी अमान्य नहीं होती। लेनदेन का आउटपुट किसी रकम और उसे बाद में खर्च करने की शर्तों का रिकॉर्ड होता है। पहले जमा की गई राशि UTXO के रूप में होती है—लेनदेन के ऐसे आउटपुट जो अभी खर्च नहीं हुए और जिनकी अपनी खर्च-शर्तें हैं। सामान्य Multisig में नई शर्तें बनाकर पुष्टि हो चुके लेनदेन के ज़रिए संबंधित पैसा उनमें भेजना ज़रूरी है। फिर पुराने पतों पर बची राशि जाँची जाती है। खाते का पासवर्ड या कुंजी का नाम बदलना इस स्थानांतरण का विकल्प नहीं। विन्यास और परिवार के निर्देश भी बदलने चाहिए, वरना उत्तराधिकारी वास्तविक स्थिति से अलग योजना इस्तेमाल कर सकते हैं। [4] [9]
उपयोगी अभ्यास अलग परीक्षण वॉलेट में होता है। पीटर सहेजा विन्यास संगत कार्यक्रम में आयात करता है, पते मिलाता है और जाँचता है कि मूल सेवा के बिना अपनी कुंजियों से हस्ताक्षर कर सकता है। Watch-only मोड पते और शेष राशि दिखाता है, पर हस्ताक्षर की क्षमता सिद्ध नहीं करता। Caravan खुला-स्रोत समन्वयक है; खास प्रारूप और उपकरणों का समर्थन फिर भी जाँचना होगा। सहायता से बहाली, अनुपलब्ध कुंजी, शुल्क और change भी अभ्यास में शामिल हैं। परिणाम समझने योग्य लिखी प्रक्रिया होनी चाहिए, इस्तेमाल किए संस्करणों सहित—सिर्फ स्क्रीन पर रकम देखकर मिलने वाली तसल्ली नहीं। [3] [6] [7]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Multisig, स्व-अभिरक्षा, Output Descriptor, PSBT, Bitcoin Inheritance Plan, Counterparty risk. इस प्रविष्टि का उल्लेख यहाँ भी है Bitcoin Inheritance Plan, Institutional custody.