MuSig2 कई लोगों को मिलकर एक Schnorr हस्ताक्षर बनाने देता है। यह उनकी निजी कुंजियाँ उजागर किए बिना किसी खास संदेश की मंजूरी साबित करता है। BIP327 की प्रक्रिया में संचार के दो चरण होते हैं: सार्वजनिक कुंजियाँ एक संयुक्त कुंजी में और हस्ताक्षर योगदान एक BIP340-संगत हस्ताक्षर में जुड़ते हैं। मूल मॉडल n-of-n है, यानी सभी शामिल हस्ताक्षरकर्ताओं का योगदान ज़रूरी है।
ऐसे साझा कोष की कल्पना करें जिसमें हर भुगतान के लिए ऐलिस और बॉब दोनों की मंजूरी चाहिए। डिजिटल हस्ताक्षर निजी कुंजी, यानी एक गुप्त संख्यात्मक मान, से भुगतान की अनुमति का प्रमाण बनाता है, लेकिन उस कुंजी को उजागर नहीं करता। सामान्य स्क्रिप्ट-आधारित Multisig में लेनदेन कई कुंजियाँ और हस्ताक्षर उजागर कर सकता है। MuSig2 में हर व्यक्ति अपनी निजी कुंजी अपने पास रखता है और साझा हस्ताक्षर में योगदान देता है। नेटवर्क एक परिणाम जाँचता है। बचत ब्लॉकचेन पर रिकॉर्ड और सत्यापन में होती है; प्रतिभागियों के बीच तालमेल की जरूरत बनी रहती है। Jonas Nick, Tim Ruffing और Yannick Seurin ने अक्टूबर 2020 में प्रकाशित शोधपत्र में यह प्रोटोकॉल प्रस्तुत किया था। [3] [2] [10]
MuSig2 अपने आप में 2-of-3 व्यवस्था नहीं है, जिसमें कोई भी दो लोग अनुपस्थित तीसरे की जगह ले सकें। इसके n-of-n मॉडल में समूह के हर सदस्य का योगदान जरूरी है। उपलब्ध न होने वाला या मना करने वाला प्रतिभागी सहयोग रोक सकता है। वॉलेट बिटकॉइन पाने और भेजने वाला ऐप या उपकरण है। उस स्थिति में भी वॉलेट चलना हो तो खर्च का दूसरा रास्ता या हस्ताक्षर की दूसरी व्यवस्था पहले से बनानी होगी; MuSig2 नाम अपने आप यह सुविधा नहीं देता। [1] [8]
हस्ताक्षर से पहले प्रतिभागी संयुक्त सार्वजनिक कुंजी बनाते हैं। सार्वजनिक कुंजी से हस्ताक्षर की जाँच की जाती है; उसे गुप्त रखना ज़रूरी नहीं है। पहले चरण में वे सार्वजनिक nonce का आदान-प्रदान करते हैं, जो हस्ताक्षर तैयार करने के एक बार इस्तेमाल होने वाले योगदान हैं। दूसरे चरण में एक ही संदेश और संदर्भ पर आंशिक हस्ताक्षर बनाकर भेजते हैं और उन्हें अंतिम हस्ताक्षर में जोड़ते हैं। प्रोटोकॉल की शर्तों के अनुसार भुगतान का विवरण पता चलने से पहले पहला चरण तैयार किया जा सकता है। लेकिन अपना आंशिक हस्ताक्षर बनाने से पहले हर प्रतिभागी को असली ट्रांज़ैक्शन, खासकर पाने वाला पता, रकम और शुल्क जाँचना चाहिए। तैयारी अनजान भुगतान की मंजूरी नहीं है; हस्ताक्षर के बाद जाँचना बहुत देर है। [1] [3]
साधारण जोड़ में हमलावर अपनी सार्वजनिक कुंजी इस तरह चुन सकता है कि दूसरे लोगों की कुंजियों का फायदा उठा सके। इसलिए MuSig2 कुंजियों की सूची से निकले संख्यात्मक भार, जिन्हें गुणांक कहते हैं, इस्तेमाल करता है। KeyAgg उनका क्रम भी ध्यान में रखता है; ऐप क्रम एक जैसा रखने के लिए KeySort इस्तेमाल कर सकता है। सभी को एक ही सूची और नियम लेने होंगे, वरना संयुक्त कुंजी एक जैसी नहीं बनेगी। [1] [5]
यहाँ nonce माइनिंग का काउंटर नहीं है। यह एक बार इस्तेमाल होने वाली हस्ताक्षर सामग्री है: pubnonce दूसरों को दी जाती है, जबकि secnonce हस्ताक्षरकर्ता के पास रहती है। किसी दूसरे Sign कॉल में गुप्त nonce दोबारा कभी इस्तेमाल नहीं करनी चाहिए। दोबारा इस्तेमाल से बने दो आंशिक हस्ताक्षर निजी कुंजी उजागर कर सकते हैं। संदेश बदलना या ऊपर से एक जैसे लगने वाले भुगतान को दोहराना सुरक्षित अपवाद नहीं है। [1] [7]
सही क्रिप्टोग्राफिक गणना काफी नहीं, अगर दोबारा शुरू होने पर ऐप बैकअप से इस्तेमाल की हुई secnonce लौटा ले या उसे एक साथ चल रहे दो कामों को दे दे। Libsecp256k1 हस्ताक्षर करते समय गुप्त nonce पर नया डेटा लिखकर उसे अमान्य करता है, लेकिन उसके नियंत्रण से बाहर की कॉपी इस सुरक्षा को पार कर सकती है। स्थिति के प्रबंधन में गलती, बहाली और साथ चल रहे कामों के दौरान भी दोबारा इस्तेमाल रुकना चाहिए। निजी हस्ताक्षर कुंजी बार-बार इस्तेमाल की जा सकती है; एक बार की पाबंदी nonce पर है। [7]
समन्वयक सार्वजनिक nonce और आंशिक हस्ताक्षर इकट्ठा कर आदान-प्रदान में मदद कर सकता है। प्रोटोकॉल सही लागू हो तो इससे उसे ईमानदार प्रतिभागी की जगह हस्ताक्षर करने की क्षमता नहीं मिलती, हालांकि वह प्रक्रिया विफल कर सकता है। हर हस्ताक्षरकर्ता को जाँचना चाहिए कि वह किस पर हस्ताक्षर कर रहा है। आंशिक हस्ताक्षरों की जाँच समस्या खोजने में मदद कर सकती है, पर इसके लिए मूल सार्वजनिक योगदान और सही संदर्भ चाहिए; केवल संयुक्त nonce से दोषी का पता नहीं लगाया जा सकता। [1] [7]
परिणाम 64 बाइट का BIP340 हस्ताक्षर है। Taproot key path खर्च का वह तरीका है जिसमें नेटवर्क आउटपुट में दर्ज कुंजी के लिए हस्ताक्षर जाँचता है, बिना वैकल्पिक स्क्रिप्ट उजागर किए। डिफॉल्ट मोड न लेने पर हस्ताक्षर के बाद sighash प्रकार बताने वाला एक बाइट जुड़ता है। यह तय करता है कि ट्रांज़ैक्शन के कौन से हिस्से हस्ताक्षर से बँधे हैं; उन्हें बदलने पर हस्ताक्षर अमान्य हो जाएगा। हस्ताक्षर अकेले प्रतिभागियों की संख्या या अलग-अलग कुंजियाँ नहीं बताता। लेकिन MuSig2 रकम, भुगतान के सभी संबंध या पक्षों के संवाद नहीं छिपाता। यह अलग इनपुट के हस्ताक्षर भी अपने-आप नहीं जोड़ता; इनपुट पहले मिले उन आउटपुट की ओर इशारा करते हैं जिन्हें यह ट्रांज़ैक्शन खर्च करता है। [5] [6]
साझा key path के अलावा Taproot में स्क्रिप्ट की शर्तें हो सकती हैं, जैसे दूसरी कुंजियों का संयोजन या समय-लॉक। समय-लॉक किसी रास्ते को तय समय या ब्लॉक ऊँचाई के बाद उपलब्ध करता है; यह ज़रूरी हस्ताक्षरों की जगह नहीं लेता। ब्लॉक लेनदेन का एक समूह है, जो साझा इतिहास में जोड़ा जाता है। ब्लॉक की ऊँचाई चेन में उसका स्थान बताती है। शर्तें आउटपुट बनाते समय ही क्रिप्टोग्राफिक रूप से तय करनी होती हैं। आउटपुट खर्च के नियमों से जुड़ी एक खास रकम है। किसी हस्ताक्षरकर्ता को खोने के बाद शर्तें जोड़ी नहीं जा सकतीं। Script path ऐसे स्क्रिप्ट से खर्च करने का तरीका है: इससे संबंधित शर्तें उजागर होती हैं और लागत बढ़ सकती है। इसलिए बहाली में केवल अलग गुप्त कुंजियाँ नहीं, चुनी व्यवस्था की जानकारी भी चाहिए। [6] [1] [9]
BIP327 प्रोटोकॉल बताता है, जबकि लाइब्रेरी और वॉलेट वास्तविक इंटरफेस, बैकअप और उपलब्ध तरीके तय करते हैं। संस्करण, परीक्षण उदाहरण, nonce का प्रबंधन और हस्ताक्षर वाले लेनदेन की जाँच देखें। Schnorr हस्ताक्षर का समर्थन होने का मतलब हर वॉलेट में पूरा MuSig2 समर्थन होना नहीं है। साझा हस्ताक्षर मौजूदा BIP340 और Taproot नियम इस्तेमाल करता है; MuSig2 के इस्तेमाल के लिए अपने आप कोई नया सहमति opcode जरूरी नहीं है। [4] [7] [2]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Schnorr Signature, Taproot, Multisig, PSBT. इस प्रविष्टि का उल्लेख यहाँ भी है Schnorr Signature, Submarine Swap, FROST, PTLC.