Address Clustering

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

पहले मिला धन UTXO, यानी अभी तक खर्च न हुए लेनदेन आउटपुट, के रूप में दर्ज रहता है। हर ऐसे आउटपुट में रकम और उसे खर्च करने की शर्तें दर्ज होती हैं। नया इनपुट किसी खास पुराने आउटपुट की ओर इशारा करता है, किसी सार्वभौमिक “भेजने वाले का पता” खाने की ओर नहीं। उपकरण मूल scriptPubKey खोजता है, जिसमें उस आउटपुट को खर्च करने की शर्तें लिखी हैं। समर्थित प्रकारों में पता इन शर्तों को सुविधाजनक रूप में दिखाता है; हर स्क्रिप्ट का सामान्य पता नहीं होता। सही व्याख्या में स्पष्ट होना चाहिए कि समूह पतों का है या स्क्रिप्टों का, किस नेटवर्क का है और किन ब्लॉकों तक है। ब्लॉक लेनदेन का एक समूह है, जो साझा इतिहास में जोड़ा जाता है। तकनीकी पहचानकर्ता अपने आप इंसान की पहचान नहीं बन जाता। [4] [6]

Common-Input Ownership Heuristic एक लेनदेन के कई इनपुटों पर साझा नियंत्रण मानती है। change पहचानना अलग कदम है: वह आउटपुट खोजना जो भुगतान और शुल्क के बाद बची रकम देने वाले को लौटाता है। सही अनुमान अन्ना के नए change पते को पुरानी प्राप्तियों से जोड़ सकता है। अगर दुकान का भुगतान ही change समझ लिया जाए, तो दूसरे का धन समूह में जुड़ जाएगा। केवल दो आउटपुट उनकी भूमिका नहीं बताते। वे दो प्राप्तकर्ता या अपने वॉलेटों के बीच स्थानांतरण भी हो सकते हैं। पहले कभी न दिखा पता भी अकेले साबित नहीं करता कि वह भुगतान करने वाले का है। [1] [3]

गोल रकम, स्क्रिप्ट का प्रकार या दोबारा इस्तेमाल हुआ पता संकेत हो सकते हैं, स्थायी नियम नहीं। वॉलेट अपडेट लेनदेन बनाने का तरीका बदल सकता है और पुराना मॉडल गलत हो सकता है। CoinJoin कई प्रतिभागियों को साझा लेनदेन बनाने देता है; BIP 78 के Payjoin में प्राप्तकर्ता अपने इनपुट भी जोड़ सकता है। सहयोग के लिए समान रकम वाले आउटपुट जरूरी नहीं हैं। इसलिए नया मूल्यांकन किए बिना पुराने सटीकता आँकड़े आज के लेनदेन के लिए वादा नहीं बन सकते। यह जानना भी जरूरी है कि किन मामलों में विधि कोई अनुमान नहीं देती। [2] [3]

पतों के दो अलग समूह सोचिए। एक गलत संबंध उन्हें जोड़कर गलती सभी सदस्यों तक पहुँचा सकता है। तेज विलय के लिए प्रोग्राम अक्सर union-find इस्तेमाल करते हैं, जो जुड़े समूहों का हिसाब रखने वाली डेटा संरचना है। उसका सामान्य रूप पुराना संबंध हटाकर परिणाम को अपने आप सही हिस्सों में नहीं बाँट सकता। जाँच योग्य विश्लेषण के लिए व्यावहारिक सुझाव है कि केवल अंतिम सूची नहीं, बल्कि लेनदेन, अलग-अलग संबंध और नियमों के संस्करण भी सुरक्षित रखें। यह शोध में वर्णित गलती फैलने की समस्या से निकला निष्कर्ष है: सुधार के लिए नाम बदलने के बजाय दोबारा गणना जरूरी हो सकती है। [2]

Malte Möser और Arvind Narayanan cluster collapse, यानी कई समूहों के गलत तरीके से एक बहुत बड़े समूह में मिल जाने, को रोकने का अध्ययन करते हैं। उनका constrained union-find उन समूहों का विलय रोकता है जो अनुमानित भुगतान आउटपुट से जुड़े हों। अन्ना के उदाहरण में “वह दुकान को भुगतान कर रही है” का अनुमान बाद में दोनों पक्षों का विलय रोक सकता है। लेकिन यह सुरक्षा स्वतंत्र रूप से सच नहीं जानती: यह खुद भुगतान के अनुमान पर निर्भर है और सही संबंध भी खारिज कर सकती है। कम विलय से मालिकों की तस्वीर अपने आप पूरी या त्रुटिरहित नहीं बनती। [2]

किसी एक पते को एक्सचेंज का नाम देना और वही नाम पूरे cluster पर लागू करना अलग कदम हैं। लेबल के लिए स्रोत, मान्य अवधि और उसके फैलने का पता लगाने योग्य रास्ता चाहिए। एक्सचेंज के नियंत्रण वाला समूह कई ग्राहकों को सेवा दे सकता है। मॉडल का सत्यापन भी केवल उसी धारणा से बने डेटा पर निर्भर नहीं होना चाहिए। गलत विलय, छूटे संबंध और नमूने का कवरेज अलग-अलग परखने चाहिए। बहुत से पतों पर नाम लिखे होने से वे नाम अपने आप सही नहीं हो जाते। [1] [2]

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