Common-Input Ownership Heuristic

يتلقى بيتر دفعتين على عنوانين مختلفين. وعندما يدفع لاحقًا ثمن إصلاح دراجته، تنفق المحفظة المبلغين معًا. المحفظة تطبيق أو جهاز لاستقبال البيتكوين وإرساله. يرى المراقب الخارجي صلة لم تكن ظاهرة في الاستلامين المنفصلين: استطاع أحدهم إنفاق هذه الأموال في معاملة واحدة. في محفظة شخصية عادية، من المعقول افتراض جهة تحكم واحدة. هذا السلوك أساس القاعدة الاستدلالية، أي طريقة عملية للتقدير. لكن Bitcoin لا يشترط مالكًا واحدًا لجميع المدخلات. كما أن زيادة عددها لا تحدد وحدها احتمال صحة الاستنتاج. [1] [6]

توجد الأموال المستلمة على هيئة UTXO، وهي مخرجات لم تُنفق بعد من معاملات سابقة. يسجل كل مخرج مبلغًا والشروط التي يجب استيفاؤها لإنفاقه. يشير مدخل المعاملة الجديدة إلى مخرج محدد منها. يبحث المحلل عن شروط إنفاقه المكتوبة في سكربت، وهو برنامج قصير يحدد قواعد الإنفاق، ويربط العنوان أو السكربت المقابل بما يخص المدخلات الأخرى. هذا هو نطاق الطريقة بدقة. المعاملة ذات المدخل الوحيد لا توفر زوجًا جديدًا للربط. كذلك لا تحدد القاعدة أي مخرج جديد هو الدفعة وأيهما change، أي الباقي العائد إلى الدافع. يتطلب ذلك قرينة أخرى. لذلك لا يجوز نسبة مخرج ورشة الإصلاح تلقائيًا إلى بيتر لمجرد ظهوره في دفعته. [1] [4]

يمكن لبيتر وشخص آخر إعداد معاملة مشتركة، ويوقع كل منهما مدخلاته. تبقى مفاتيحهما الخاصة، أي الأعداد السرية المستخدمة لإنشاء توقيعات تجيز إنفاق البيتكوين، منفصلة. PSBT تنسيق لتبادل معاملة غير مكتملة والمعلومات اللازمة لها بين البرامج أو الأجهزة، ويصفه BIP 174. ولا يلزم أن يمتلك المنسق الذي يجمع البيانات جميع المفاتيح. تتحقق الشبكة من استيفاء شروط الإنفاق، لا من أن شخصًا واحدًا أنشأ كل التوقيعات. أما Multisig فيعالج مسألة أخرى: قد يطلب عدة توقيعات لمدخل واحد، بينما تقدر هذه القاعدة العلاقة بين عدة مدخلات. [2] [5] [6]

يتيح CoinJoin لعدة مشاركين إضافة أموالهم إلى معاملة مشتركة. ويُظهر Payjoin المشكلة داخل دفعة: وفق BIP 78، يمكن للمستلم أيضًا إضافة مدخلاته الخاصة. لو قبلت الورشة دفعة كهذه، فقد يؤدي تطبيق القاعدة بلا تمحيص إلى دمج أموالها مع أموال بيتر. ولا تتطلب هذه المشاركة تساوي مبالغ جميع المخرجات. لذا لا يكفي استبعاد المعاملات التي تبدو بوضوح من نوع CoinJoin ثم اعتبار الباقي دفعات لمالك واحد. ليس المقصود أن كل معاملة تعاونية، بل إن شكلها وحده لا يستبعد هذا الاحتمال دائمًا. [2]

لنتصور العناوين A وB وC. تنفق المعاملة الأولى مخرجات من A+B معًا، وتجمع أخرى مخرجات مختلفة من B+C. هذا ليس إنفاقًا لنفس UTXO مرتين. عبر B المشترك قد يدمج البرنامج A+B+C في مجموعة واحدة، أو cluster. لكن إذا كانت المعاملة الثانية تعاونًا بين أشخاص مختلفين، فإن الخطأ يصيب أيضًا العنوان A الذي سبق تصنيفه. بهذه الطريقة قد تنتشر الأخطاء بين مجموعات كاملة. لذلك لا يضمن العدد القليل من الروابط الخاطئة عددًا قليلًا من العناوين المنسوبة خطأً. [1] [3]

قد تنفق منصة في معاملة واحدة أموالًا تديرها لعملاء كثيرين. يمكن للقاعدة حينها أن تكشف بشكل صحيح عن التحكم التشغيلي المشترك للخدمة، لكنها لا تحدد أي العملاء يملك الأموال اقتصاديًا. وحتى اسم الخدمة لا يُقرأ من المدخلات وحدها: يحتاج الوسم إلى أدلة أخرى وإلى أن يكون صالحًا للفترة المعنية. وعلى العكس، قد يستخدم بيتر عدة محافظ لا يجمع أموالها أبدًا. لذلك لا يعادل عدّ المجموعات المكتشفة عدّ الأشخاص ببساطة. التحكم والملكية والهوية مسائل مترابطة لكنها مختلفة. [1]

يريد المحلل معرفة إن كان ربط العناوين صحيحًا. إذا اعتمد فقط على إنفاق مشترك لاحق لتأكيده، فقد يكرر الافتراض نفسه. لا ينتج عن ذلك دليل مستقل تلقائيًا. يصف Malte Möser وArvind Narayanan استخدام بيانات مرجعية كهذه وحدودها. لذلك يجب أن يوضح التقييم مصدر العينة والمعاملات المستبعدة والفترة المشمولة. وينبغي تقييم الدمج الخاطئ والروابط الفائتة والتغطية كلًّا على حدة. من دون معايرة بحالات معلومة، لا يمكن تفسير الدرجة على أنها احتمال تحديد الشخص الصحيح. [3]

يمكن لبيتر استخدام Coin Control، أي اختيار UTXO المراد إنفاقها يدويًا، للحد من الربط مستقبلًا بين مبالغ كانت منفصلة. هذا لا يمحو المعاملات السابقة ويتطلب فهم الأموال المختارة. كما لا يزيل Payjoin كل طرق النسبة الأخرى. وفي التحليل ينبغي أن يعود كل رابط إلى معاملة ونسخة من القاعدة وسبب للإدراج أو الاستبعاد. تُستمد أسئلة المراجعة هذه من الحدود المذكورة في المصادر. عند اكتشاف خطأ يجب أن يمكن تحديد العناوين التي تنتمي إلى المجموعة من جديد؛ فإضافة ملاحظة إلى استنتاج لم يتغير لا تصحح النسب الخاطئة. [2] [3]