Nostr ، اختصار لـ "الملاحظات والمحتويات الأخرى المنقولة عبر الترحيل" ، هو بروتوكول اتصال جديد تم تطويره بواسطة مطور Lightning Network fiatjaf في عام 2021. تطورت محاولات تطبيق اللامركزية في الأسواق. على عكس حلول الاتصالات الأخرى ، والتي يعمل معظمها من خلال العملاء الخادمين والخوادم الذكية ، توفر Nostr عملاء أذكياء وخوادم غبية ، مما يزيد من مقاومة المستخدمين للرقابة.
** في Nostr ، يتم تخزين جميع البيانات محليًا على المستخدم ويتم توزيعها فقط من خلال المرحلات ، وليس على خادم مركزي مثل Twitter. ** في حالة وسائل التواصل الاجتماعي ، يضيف Nostr مقاومة الرقابة حيث يمتلك المستخدمون الملكية الكاملة لمحتوياتهم وملفاتهم الشخصية. في ضوء الجدل الأخير حول سياسات الرقابة في تويتر ، بدأ المستخدمون في الهجرة إلى حل الاتصالات الفيدرالية Mastodon. في Mastodon ، ومع ذلك ، فإن ملكية المحتوى والملفات الشخصية تقع على عاتق مشغل خادم Mastodon الذي يسجل المستخدم عليه. في حين أن نظامًا متحدًا مثل Mastodon يقدم مقاومة أكثر للرقابة من الخادم المركزي ، حيث يمكن للمستخدمين ببساطة التسجيل في خادم آخر إذا كانوا خاضعين للرقابة ، فقد كانت هناك انتقادات بأن Mastodon قد تفرض الرقابة من خلال مالك الخادم.
في ديسمبر 2022 ، تلقى مجتمع Nostr تمويلًا قدره 14 BTC من مؤسس Twitter Jack Dorsey ، مما جذب انتباهًا غير مسبوق إلى البروتوكول. مع استمرار نمو التطبيقات المبنية على Nostr ، احتل عميل الهاتف المحمول Damus المرتبة الأولى في فئة الشبكات الاجتماعية لمتجر تطبيقات iOS الصيني وتم حظره نتيجة لذلك. في محاولة للحد من حركة #MarchOffTwitter ، حظر الرئيس التنفيذي لشركة Twitter Elon Musk بسرعة المحتوى المرتبط بـ Nostr وحظر منصات الطرف الثالث الأخرى مثل Instagram ، دون نجاح.
على الرغم من أن Nostr نفسه ليس بروتوكول خصوصية - بشكل افتراضي ، يقوم العملاء بتسريب عناوين IP الخاصة بالمستخدمين إلى المرحلات - يمكن لبروتوكول Nostr أن يحسن خصوصية Bitcoin.
** تحسين خصوصية وقابلية التوسع في BIP47 **
** BIP47 هو اقتراح تحسين Bitcoin لإنشاء رموز دفع قابلة لإعادة الاستخدام للدفعات المتكررة مع حماية خصوصية المستخدم. ** في حالة عدم وجود BIP47 ، من أجل تجنب إعادة استخدام العنوان ، يحتاج المستخدمون إلى إنشاء عناوين جديدة يدويًا وبقوة. عندما يعيد المستخدم استخدام عنوان للمعاملات ، يمكن لأي شخص يراقب blockchain تجميع جميع المعاملات التي تنتمي إلى هذا العنوان بسهولة ، مما يشكل رسمًا بيانيًا لسجل مدفوعات المستخدم وصافي ثروته. لذلك ، في Bitcoin ، يعد منع إعادة استخدام العنوان من أفضل ممارسات الخصوصية ويتم تنفيذه بالفعل افتراضيًا في العديد من محافظ Bitcoin. ومع ذلك ، قد يكون إنشاء عناوين جديدة بشكل متكرر أمرًا غير مريح عندما يحاول المستخدم إنشاء علاقة دفع متكررة مع طرف آخر ، مثل العلاقة بين التاجر والعميل.
** من خلال BIP47 ، يمكن للعملاء إنشاء مجموعة من عناوين الدفع للتجار. ** إذا قام العميل بشراء المنتجات شهريًا ، يحتاج التاجر إلى إرسال عنوان إلى العميل كل شهر. باستخدام BIP47 ، ينشئ العميل رمز دفع مخصصًا للتاجر ، على غرار المفتاح العام الممتد. يتيح ذلك للعميل إنشاء عنوان جديد تلقائيًا للتاجر دون مطالبة التاجر بإنشاء عنوان للعميل.
** يستخدم BIP47 عناوين الإخطار ، والتي يتم مراقبتها بواسطة HD Wallet للنواتج. ** في معاملة الإخطار ، يرسل التاجر للعميل المفتاح العام المكفوفين والرمز التسلسلي عبر حقل OP \ _RETURN ، جنبًا إلى جنب مع سر مشترك للحفاظ على خصوصية العنوان المشترك على blockchain العام. نظرًا لبنية شبكة Bitcoin ، فإن هذا التبادل يخلق العديد من المشاكل. أول مشكلتين اقتصاديتين: تتكون معاملة الإخطار من 80 بايت ، والتي يمكن أن تصبح باهظة الثمن للمستخدمين عندما تكون رسوم المعاملات على شبكة Bitcoin مرتفعة. بالإضافة إلى ذلك ، تنشئ معاملات الإشعارات مخرجات لا يمكن إرسالها ، ** تضخيم UTXO الذي تم تعيينه بمرور الوقت. ** يؤدي هذا إلى زيادة الحمل الحسابي على عقد Bitcoin ، حيث يحتاجون حاليًا إلى تخزين المجموعة الكاملة من UTXOs ، أي كل مخرجات Bitcoin التي لا يتم استخدامها كمدخل جديد لضمان صحة المعاملة.
** يؤدي الإخطار إلى المعاملات إلى إنشاء ما يُعرف باسم "التغيير المسموم". ** عندما يتلقى المستخدم تغييرًا من معاملة إشعار ويدفعها إلى طرف ثالث ، فإن أي شخص يراقب blockchain سيكون قادرًا على ربط الدفع المتكرر للمستخدم بدفع غير متكرر ، حتى إذا لم يتم إعادة استخدام العنوان. يوجد عنوان إعلام مرة واحدة فقط لكل محفظة. إذا كان التاجر يرغب في إقامة علاقات دفع متكررة مع 10 عملاء ، فسيتمكن أي شخص يراقب blockchain من التعرف على قاعدة عملاء التاجر ، حيث سيحتاج جميع العملاء العشرة إلى إنشاء معاملات إشعار للتاجر على نفس عنوان الإخطار.
** بدلاً من استخدام معاملات الإخطار لتبادل رموز الدفع بين التجار والعملاء ، يمكن استبدال رموز الدفع من خلال Nostr. ** بخلاف طرق الاتصال الأخرى ، Nostr مناسب لتبادل رموز الدفع BIP47 لأنه لا توجد سلطة مركزية يمكنها مراقبة تبادل الرسائل. في الوقت نفسه ، يتم تشفير جميع الرسائل المباشرة على Nostr افتراضيًا ، ولا داعي لحساب سر مشترك. باستخدام BIP47 من خلال Nostr ، يمكن للمستخدمين تجنب إنشاء سخام لمجموعة UTXO بمخرجات غير قابلة للإنفاق ، وفصل الإنفاق المزدوج من النفقات غير المكررة عن طريق تجنب التغيير السام وإعادة استخدام عناوين الإشعارات ، وتجنب تعريض قاعدة العملاء للتخلص من إطلاق سراح قاعدة العملاء.
ملاحظة: من خلال تنفيذ UTreeXO ، قد يتم التخلص من الحاجة إلى عقد Bitcoin لتخزين المجموعة الحالية بالكامل من UTXO في المستقبل. يقوم UTreeXO بتحويل عبء إثبات ما إذا كانت المعاملة تستخدم UTXO صالحًا إلى مالك UTXO ، مما يقلل من متطلبات التخزين من بضع غيغابايت إلى بضعة كيلوبايت.
** Nostr Pay-To-EndPoint **
** في Bitcoin ، تقوم خدمة تحليل blockchain بتعيين المعاملات إلى الهويات باستخدام قاعدة إرشادية لـ "ملكية المدخلات المشتركة". ** وفقًا لهذه القاعدة ، يتم تصنيف المعاملات التي تحتوي على مفاتيح عامة مختلفة كمدخلات على أنها تخص نفس الشخص. إن بروتوكول Bitcoin أيضًا عرضة لتحليل تجميع المجموعات الفرعية نظرًا لهندسته القائمة على UTXO والتي يتم من خلالها ربط مدخلات ومخرجات المعاملات. في تحليل المجموع الفرعي ، يكون المهاجم قادرًا على حساب احتمالية أن أحد المدخلات والمخرجات ينتميان إلى نفس الكيان ، حتى لو تم استخدام مفاتيح عامة مختلفة كمدخلات لمعاملة ما. على سبيل المثال ، إذا كانت المعاملة تحتوي على مدخلات 1 و 4 و 7 و 23 و 6 والمخرجات 5 و 36 ، فيمكن استنتاج أن المدخلات 1 و 4 والمدخلات 7 و 23 و 6 تنتمي إلى نفس الكيان.
المصدر: اكتشاف المعرفة في تداول العملات المشفرة: دراسة استقصائية ، 2021 بواسطة Xia Fan Lu و Xin-Jiang Jang
** الدفع إلى النهاية (P2EP) هو إعادة تصميم محمية بخصوصية الدفع مقابل IP (P2IP) الخاصة بساتوشي ناكاموتو ، المشفرة في عميل البيتكوين الأصلي. ** أحد أشكال معاملات P2EP هو معاملة PayJoin ، المصممة لكسر القاعدة الاستكشافية لملكية المدخلات المشتركة. في معاملة PayJoin ، يوفر كل من المرسل والمستقبل مدخلات لكسر توجيه الإدخال المشترك. باستخدام PayJoins ، يمكن للمستخدمين تبادل المعلومات حول UTXOs لاستخدامها كمدخلات لإنشاء معاملات Bitcoin الموقعة جزئيًا (PSBT) عبر أي قناة اتصال (مثل Tor Onion كنقطة نهاية). بمجرد اتفاق الطرفين على الشروط وتوقيع المعاملة ، تبدو معاملة PayJoin مثل أي معاملة Bitcoin أخرى على blockchain. نظرًا لأن الأطراف المعنية تلعب دور المرسل والمتلقي ، فإن معاملات PayJoin لا تكسر فقط القاعدة التجريبية للملكية المشتركة ، بل تكسر أيضًا تحليل مجموع المجموعة الفرعية: يمكن للأطراف توفير مدخلات من 3 و 5 ، والمخرجات الناتجة عن المعاملة لمدة 6 و 2.
المصدر: Pay To EndPoint بواسطة Adam Fiscor ، 2018
المشكلة: تنسيق معاملات PayJoin معقد نوعًا ما ، حيث يجب أن يكون المشاركون متصلين بالإنترنت في نفس الوقت ، سواء باستخدام مجالات clearnet أو نقاط نهاية Tor Onion. إذا بدأ المستخدم معاملة P2EP ، على سبيل المثال عن طريق إيقاف تشغيل جهاز الكمبيوتر الخاص به أو فقد اتصال الشبكة ، فلن تتمكن المعاملة من الاتصال. في Nostr ، يكون الاتصال غير متزامن: يحصل المستخدمون على معلومات من المرحل بعد استعادة اتصال الشبكة. يمكن تنسيق معاملات P2EP بسهولة أكبر باستخدام مفاتيح Nostr بدلاً من Tor Onion كنقطة نهاية لمعاملات P2EP.
تطبيق آخر لـ P2EP هو LNURL المثير للجدل. باستخدام LNURL ، بدلاً من إنشاء فواتير جديدة بشكل مضجر لكل معاملة ، يمكن للمستخدمين تلقي نقطة نهاية ثابتة تشير إلى خادم ويب لإنشاء فواتير جديدة تلقائيًا. ومع ذلك ، نظرًا لأن خوادم الويب تعتمد على خدمة اسم المجال العالمية (DNS) ، فإن المستخدمين الذين يستخدمون LNURL يكشفون حتمًا عن هوياتهم لموفري الاستضافة ، وإذا لم يتم اتخاذ الاحتياطات المناسبة ، فإن عناوين IP الخاصة بهم إلى المدفوع لهم. ** اعتماد LNURL على نطاق واسع سيكون ضارًا بإخفاء الهوية لشبكة Lightning Network ****. بدلاً من استخدام خادم الويب كنقطة نهاية لـ LNURL ، يمكن للمستخدمين استخدام مفاتيح Nostr كنقطة نهاية لمعاملات LNURL لإخفاء هوياتهم. **
** Nostr for CoinJoin **
بينما يكسر PayJoin أساليب الملكية المشتركة والإسناد والتحليل بشكل جيد ، يفشل PayJoin في تزويد المرسل والمتلقي بحماية الخصوصية من الأطراف المتعاونة. PayJoin هي في الأساس CoinJoin من طرفين ، تقتصر على اثنين من المشاركين ، مما يعني أن كلا من المرسل والمستقبل يعرف مدخلاتهم ومخرجاتهم ، مما يجعل مدخلات ومخرجات شركائهم قابلة للتحديد. ما لم يتم استخدام معاملة CoinJoined لتسهيل PayJoin ، يخاطر المستخدمون بالكشف عن أرصدة المحفظة والمعاملات السابقة والمستقبلية لشركاء PayJoin.
في نظام شهادة المبلغ المجهول مثل بروتوكول تنسيق CoinJoin الخاص بـ Wasabi Wallet (WabiSabi) ، يمكن أن يعمل مفتاح Nostr كنقطة نهاية للاتصال لتنسيق معاملات CoinJoin. يسمح هذا لمرسل ومتلقي معاملة CoinJoin بتبادل بيانات الاعتماد المطلوبة للمشاركة في جولة CoinJoin ، مما يتيح طريقة دفع منفصلة في CoinJoin. باستخدام مفتاح Nostr كنقطة نهاية في CoinJoins ، تظل الأطراف المتعاونة مخفية عن الحشد ، وتبقى غير مدركة لأرصدة ومعاملات الطرف المقابل. في الوقت نفسه ، فإن استخدام مفاتيح Nostr كنقطة نهاية لمعاملات CoinJoin يساعد مستخدمي PayJoin على توفير الرسوم عن طريق إجراء المدفوعات مباشرة في CoinJoin بدلاً من تسهيل المدفوعات من خلال CoinJoin.
استخدام آخر لـ Nostr في CoinJoins هو اكتشاف المنسق. بينما يعمل معظم منسقي CoinJoin خلف Tor لإخفاء هويات المشاركين في CoinJoin ، لا يمكن للمستخدمين حاليًا اكتشاف منسقين جدد بسهولة ، باستثناء JoinMarket (سوق CoinJoin لمستخدمي CoinJoin الأكثر تقدمًا). بينما يمكن لمستخدمي CoinJoin إضافة منسقين مخصصين إلى Wasabi Wallet (بسهولة تبادل عناوين URL في الخلفية) ، نظرًا لعدم وجود نظام أساسي للنشر ، لا توجد طريقة لأتمتة عملية تحديث المنسقين. لذلك ، من أجل اكتشاف المنسقين الجدد ، يجب على المستخدمين البحث يدويًا في الوسائط الاجتماعية والمنتديات (مثل Reddit أو Twitter) لإضافة منسقين. ومع ذلك ، قد يشكل نشر خدمة منسق عبر وسائل التواصل الاجتماعي أو المنتديات خطرًا على مزود التنسيق ، اعتمادًا على السياسات المطبقة على الخدمة ، حيث قد يتم إغلاق بعض الصفحات بسهولة.
إذا كان Tor هو خادم ترحيل مجهول ، وهو بروتوكول يسهل إعادة توجيه الرسائل واستلامها بشكل مجهول بين أقرانه ، فيمكن أن يعمل Nostr كلوحة إعلانات مجهولة. يمكن لمنسقي CoinJoin نشر خدماتهم عبر نوع حدث Nostr ، ويمكن لمحافظ CoinJoin تمكين الجلب التلقائي للمعلومات من خوادم الترحيل هذه وعرضها في عملائها. يمكن لخوادم منسق البث بواسطة Nostr ، مثل المكون الإضافي CoinJoin لخوادم BTCPay والنهج المقترح في برنامج CoinJoin المستند إلى شبكة Lightning ، أن تلغي الحاجة إلى البحث يدويًا عن منسقي CoinJoin وإضافتهم في عملاء CoinJoin ، مما يزيد من اللامركزية في مشهد تنسيق CoinJoin.
** تجاوز متطلبات IP عبر NOSTR **
كما ذكرنا سابقًا ، كان المفهوم الأصلي لبروتوكول ** Nostr هو تنفيذ سوق لامركزية بالكامل يسمى Diagon Alley. ** مع تطوير بروتوكول Nostr ، أصبح Diagon Alley هو NostrMarkets ، وهو امتداد لـ LNbits: سوق يدعم Nostr يمكّن التجار والعملاء من إدارة المتاجر عبر الإنترنت والتفاعل معها من خلال المرحلات. في NostrMarkets ، يمكن للعملاء الاشتراك في المفتاح العام للتاجر والحصول على المنتجات من التتابع بدلاً من زيارة موقع التاجر عبر المتجر عبر الإنترنت. يؤدي هذا إلى زيادة مقاومة الرقابة على المتجر عبر الإنترنت لأنه بدلاً من الاعتماد على موقع ويب خاضع للرقابة ، يتم استضافة متجر التاجر بواسطة جميع المرحلات التي يتصل بها. حتى إذا تم الاستيلاء على خادم التاجر ، يمكن بسهولة إعداد المتجر في مواقع مختلفة ، لأن جميع المنتجات مخزنة على المرحل على شبكة Nostr. تتولى NostrMarkets تنسيق الطلبات والدفع عبر رسائل Nostr Direct المشفرة ، بينما تتم المدفوعات عبر شبكة Lightning Network.
بالإضافة إلى كونه مقاومًا للرقابة ، فإن امتداد NostrMarkets الخاص بـ LNbits يتيح سوقًا مجهول الهوية بالكامل. لا يكشف التجار والعملاء عن عناوين IP الخاصة بهم للعالم ، ولكن فقط للترحيل الذي يتصلون به ، ويمكن حل ذلك بسهولة عن طريق تشغيل العميل أو المتجر خلف Tor. تتمثل ميزة تشغيل المتجر بالكامل خلف Tor في أنه بينما لا يمكن الوصول إلى المتجر إلا من خلال متصفح Tor وصفحات الويب .onion ، يمكن لـ NostrMarkets العمل على أي متصفح ويب أو هاتف ذكي ، مما يحسن تجربة المستخدم في الاتصال الذي يحافظ على الخصوصية بين العميل وخادم العميل. نظرًا لأنه يتم التفاوض على المدفوعات عبر رسائل Nostr Direct المشفرة وتنفيذها عبر شبكة Lightning Network ، ستظل المدفوعات في NostrMarkets خاصة نسبيًا طالما أن عقدة Lightning في المتجر تعمل خلف Tor ، حيث لا يمكن مقارنة تنسيق الدفع بالرسائل المباشرة الأخرى في Nostr. .
هناك طريقة أخرى لتجاوز متطلبات عنوان IP في الاتصال بين الخادم والعميل وهي NOSTREST. يرمز REST إلى "النقل التمثيلي للحالة" ، وهو جزء من بنية برمجيات شبكة الويب العالمية للاتصال بين الخوادم والعملاء عبر طلبات GET و POST و PUT و DELETE و PATCH. ومع ذلك ، عندما يرسل العميل طلب REST إلى خادم ، يتم كشف عنوان IP ، ويحتمل أن يكشف عن معلومات التعريف الشخصية. على GitHub ، اقترح \ _ \ _ escapeee \ _ \ _ جسر REST API مبني على Nostr يسمى NOSTREST. باستخدام مفاتيح Nostr بدون رأس المصادقة ، لا يحتاج المستخدمون ومشغلو الخادم إلى معرفة عناوين IP لبعضهم البعض. لذلك ، يمكن أن يؤدي تطبيق NOSTREST إلى تحسين خصوصية تطبيقات Bitcoin باستخدام REST ، لأن الخادم لا يتطلب عنوان IP الخاص بالعميل.
مثال على ذلك يمكن أن يكون تشغيل صندوق Chaumian للنقد الإلكتروني ، وهو نظام قسيمة مجهول للمبالغ. في عملية سك النقود الإلكترونية ، لا يعرف مشغل سك العملة أرصدة مستخدميه أو قيمة التبادل. ومع ذلك ، نظرًا لبنية REST الحالية ، ما لم يكن يعمل خلف Tor افتراضيًا (كما هو الحال في نظام النقد الإلكتروني Cashu) ، فإنه يتعرف على عنوان IP الخاص بالمستخدم. ومع ذلك ، فإن تنفيذ وإدارة دعم Tor أمر مرهق. من خلال جسر NOSTREST ، يمكن للمشروع حماية خصوصية المستخدمين بسهولة. من خلال تشغيل أداة سك النقود الإلكترونية خلف Tor واستخدام NOSTREST للتواصل بين الخادم والعميل ، يمكن تحقيق الاتصال غير المتزامن ، بينما لا يعرف مشغل الخادم والمستخدم سوى المفتاح العام لبعضهما البعض ، مما يلغي الحاجة إلى تحديد الهوية من خلال مخاطر IP.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
مفارقة خصوصية Nostr والتحسينات التي تم إدخالها على خصوصية Bitcoin
المؤلف: L0la L33tz ، المترجم: DoraFactory
Nostr ، اختصار لـ "الملاحظات والمحتويات الأخرى المنقولة عبر الترحيل" ، هو بروتوكول اتصال جديد تم تطويره بواسطة مطور Lightning Network fiatjaf في عام 2021. تطورت محاولات تطبيق اللامركزية في الأسواق. على عكس حلول الاتصالات الأخرى ، والتي يعمل معظمها من خلال العملاء الخادمين والخوادم الذكية ، توفر Nostr عملاء أذكياء وخوادم غبية ، مما يزيد من مقاومة المستخدمين للرقابة.
** في Nostr ، يتم تخزين جميع البيانات محليًا على المستخدم ويتم توزيعها فقط من خلال المرحلات ، وليس على خادم مركزي مثل Twitter. ** في حالة وسائل التواصل الاجتماعي ، يضيف Nostr مقاومة الرقابة حيث يمتلك المستخدمون الملكية الكاملة لمحتوياتهم وملفاتهم الشخصية. في ضوء الجدل الأخير حول سياسات الرقابة في تويتر ، بدأ المستخدمون في الهجرة إلى حل الاتصالات الفيدرالية Mastodon. في Mastodon ، ومع ذلك ، فإن ملكية المحتوى والملفات الشخصية تقع على عاتق مشغل خادم Mastodon الذي يسجل المستخدم عليه. في حين أن نظامًا متحدًا مثل Mastodon يقدم مقاومة أكثر للرقابة من الخادم المركزي ، حيث يمكن للمستخدمين ببساطة التسجيل في خادم آخر إذا كانوا خاضعين للرقابة ، فقد كانت هناك انتقادات بأن Mastodon قد تفرض الرقابة من خلال مالك الخادم.
في ديسمبر 2022 ، تلقى مجتمع Nostr تمويلًا قدره 14 BTC من مؤسس Twitter Jack Dorsey ، مما جذب انتباهًا غير مسبوق إلى البروتوكول. مع استمرار نمو التطبيقات المبنية على Nostr ، احتل عميل الهاتف المحمول Damus المرتبة الأولى في فئة الشبكات الاجتماعية لمتجر تطبيقات iOS الصيني وتم حظره نتيجة لذلك. في محاولة للحد من حركة #MarchOffTwitter ، حظر الرئيس التنفيذي لشركة Twitter Elon Musk بسرعة المحتوى المرتبط بـ Nostr وحظر منصات الطرف الثالث الأخرى مثل Instagram ، دون نجاح.
على الرغم من أن Nostr نفسه ليس بروتوكول خصوصية - بشكل افتراضي ، يقوم العملاء بتسريب عناوين IP الخاصة بالمستخدمين إلى المرحلات - يمكن لبروتوكول Nostr أن يحسن خصوصية Bitcoin.
** تحسين خصوصية وقابلية التوسع في BIP47 **
** BIP47 هو اقتراح تحسين Bitcoin لإنشاء رموز دفع قابلة لإعادة الاستخدام للدفعات المتكررة مع حماية خصوصية المستخدم. ** في حالة عدم وجود BIP47 ، من أجل تجنب إعادة استخدام العنوان ، يحتاج المستخدمون إلى إنشاء عناوين جديدة يدويًا وبقوة. عندما يعيد المستخدم استخدام عنوان للمعاملات ، يمكن لأي شخص يراقب blockchain تجميع جميع المعاملات التي تنتمي إلى هذا العنوان بسهولة ، مما يشكل رسمًا بيانيًا لسجل مدفوعات المستخدم وصافي ثروته. لذلك ، في Bitcoin ، يعد منع إعادة استخدام العنوان من أفضل ممارسات الخصوصية ويتم تنفيذه بالفعل افتراضيًا في العديد من محافظ Bitcoin. ومع ذلك ، قد يكون إنشاء عناوين جديدة بشكل متكرر أمرًا غير مريح عندما يحاول المستخدم إنشاء علاقة دفع متكررة مع طرف آخر ، مثل العلاقة بين التاجر والعميل.
** من خلال BIP47 ، يمكن للعملاء إنشاء مجموعة من عناوين الدفع للتجار. ** إذا قام العميل بشراء المنتجات شهريًا ، يحتاج التاجر إلى إرسال عنوان إلى العميل كل شهر. باستخدام BIP47 ، ينشئ العميل رمز دفع مخصصًا للتاجر ، على غرار المفتاح العام الممتد. يتيح ذلك للعميل إنشاء عنوان جديد تلقائيًا للتاجر دون مطالبة التاجر بإنشاء عنوان للعميل.
** يستخدم BIP47 عناوين الإخطار ، والتي يتم مراقبتها بواسطة HD Wallet للنواتج. ** في معاملة الإخطار ، يرسل التاجر للعميل المفتاح العام المكفوفين والرمز التسلسلي عبر حقل OP \ _RETURN ، جنبًا إلى جنب مع سر مشترك للحفاظ على خصوصية العنوان المشترك على blockchain العام. نظرًا لبنية شبكة Bitcoin ، فإن هذا التبادل يخلق العديد من المشاكل. أول مشكلتين اقتصاديتين: تتكون معاملة الإخطار من 80 بايت ، والتي يمكن أن تصبح باهظة الثمن للمستخدمين عندما تكون رسوم المعاملات على شبكة Bitcoin مرتفعة. بالإضافة إلى ذلك ، تنشئ معاملات الإشعارات مخرجات لا يمكن إرسالها ، ** تضخيم UTXO الذي تم تعيينه بمرور الوقت. ** يؤدي هذا إلى زيادة الحمل الحسابي على عقد Bitcoin ، حيث يحتاجون حاليًا إلى تخزين المجموعة الكاملة من UTXOs ، أي كل مخرجات Bitcoin التي لا يتم استخدامها كمدخل جديد لضمان صحة المعاملة.
** يؤدي الإخطار إلى المعاملات إلى إنشاء ما يُعرف باسم "التغيير المسموم". ** عندما يتلقى المستخدم تغييرًا من معاملة إشعار ويدفعها إلى طرف ثالث ، فإن أي شخص يراقب blockchain سيكون قادرًا على ربط الدفع المتكرر للمستخدم بدفع غير متكرر ، حتى إذا لم يتم إعادة استخدام العنوان. يوجد عنوان إعلام مرة واحدة فقط لكل محفظة. إذا كان التاجر يرغب في إقامة علاقات دفع متكررة مع 10 عملاء ، فسيتمكن أي شخص يراقب blockchain من التعرف على قاعدة عملاء التاجر ، حيث سيحتاج جميع العملاء العشرة إلى إنشاء معاملات إشعار للتاجر على نفس عنوان الإخطار.
** بدلاً من استخدام معاملات الإخطار لتبادل رموز الدفع بين التجار والعملاء ، يمكن استبدال رموز الدفع من خلال Nostr. ** بخلاف طرق الاتصال الأخرى ، Nostr مناسب لتبادل رموز الدفع BIP47 لأنه لا توجد سلطة مركزية يمكنها مراقبة تبادل الرسائل. في الوقت نفسه ، يتم تشفير جميع الرسائل المباشرة على Nostr افتراضيًا ، ولا داعي لحساب سر مشترك. باستخدام BIP47 من خلال Nostr ، يمكن للمستخدمين تجنب إنشاء سخام لمجموعة UTXO بمخرجات غير قابلة للإنفاق ، وفصل الإنفاق المزدوج من النفقات غير المكررة عن طريق تجنب التغيير السام وإعادة استخدام عناوين الإشعارات ، وتجنب تعريض قاعدة العملاء للتخلص من إطلاق سراح قاعدة العملاء.
ملاحظة: من خلال تنفيذ UTreeXO ، قد يتم التخلص من الحاجة إلى عقد Bitcoin لتخزين المجموعة الحالية بالكامل من UTXO في المستقبل. يقوم UTreeXO بتحويل عبء إثبات ما إذا كانت المعاملة تستخدم UTXO صالحًا إلى مالك UTXO ، مما يقلل من متطلبات التخزين من بضع غيغابايت إلى بضعة كيلوبايت.
** Nostr Pay-To-EndPoint **
** في Bitcoin ، تقوم خدمة تحليل blockchain بتعيين المعاملات إلى الهويات باستخدام قاعدة إرشادية لـ "ملكية المدخلات المشتركة". ** وفقًا لهذه القاعدة ، يتم تصنيف المعاملات التي تحتوي على مفاتيح عامة مختلفة كمدخلات على أنها تخص نفس الشخص. إن بروتوكول Bitcoin أيضًا عرضة لتحليل تجميع المجموعات الفرعية نظرًا لهندسته القائمة على UTXO والتي يتم من خلالها ربط مدخلات ومخرجات المعاملات. في تحليل المجموع الفرعي ، يكون المهاجم قادرًا على حساب احتمالية أن أحد المدخلات والمخرجات ينتميان إلى نفس الكيان ، حتى لو تم استخدام مفاتيح عامة مختلفة كمدخلات لمعاملة ما. على سبيل المثال ، إذا كانت المعاملة تحتوي على مدخلات 1 و 4 و 7 و 23 و 6 والمخرجات 5 و 36 ، فيمكن استنتاج أن المدخلات 1 و 4 والمدخلات 7 و 23 و 6 تنتمي إلى نفس الكيان.
المصدر: اكتشاف المعرفة في تداول العملات المشفرة: دراسة استقصائية ، 2021 بواسطة Xia Fan Lu و Xin-Jiang Jang
** الدفع إلى النهاية (P2EP) هو إعادة تصميم محمية بخصوصية الدفع مقابل IP (P2IP) الخاصة بساتوشي ناكاموتو ، المشفرة في عميل البيتكوين الأصلي. ** أحد أشكال معاملات P2EP هو معاملة PayJoin ، المصممة لكسر القاعدة الاستكشافية لملكية المدخلات المشتركة. في معاملة PayJoin ، يوفر كل من المرسل والمستقبل مدخلات لكسر توجيه الإدخال المشترك. باستخدام PayJoins ، يمكن للمستخدمين تبادل المعلومات حول UTXOs لاستخدامها كمدخلات لإنشاء معاملات Bitcoin الموقعة جزئيًا (PSBT) عبر أي قناة اتصال (مثل Tor Onion كنقطة نهاية). بمجرد اتفاق الطرفين على الشروط وتوقيع المعاملة ، تبدو معاملة PayJoin مثل أي معاملة Bitcoin أخرى على blockchain. نظرًا لأن الأطراف المعنية تلعب دور المرسل والمتلقي ، فإن معاملات PayJoin لا تكسر فقط القاعدة التجريبية للملكية المشتركة ، بل تكسر أيضًا تحليل مجموع المجموعة الفرعية: يمكن للأطراف توفير مدخلات من 3 و 5 ، والمخرجات الناتجة عن المعاملة لمدة 6 و 2.
المصدر: Pay To EndPoint بواسطة Adam Fiscor ، 2018
المشكلة: تنسيق معاملات PayJoin معقد نوعًا ما ، حيث يجب أن يكون المشاركون متصلين بالإنترنت في نفس الوقت ، سواء باستخدام مجالات clearnet أو نقاط نهاية Tor Onion. إذا بدأ المستخدم معاملة P2EP ، على سبيل المثال عن طريق إيقاف تشغيل جهاز الكمبيوتر الخاص به أو فقد اتصال الشبكة ، فلن تتمكن المعاملة من الاتصال. في Nostr ، يكون الاتصال غير متزامن: يحصل المستخدمون على معلومات من المرحل بعد استعادة اتصال الشبكة. يمكن تنسيق معاملات P2EP بسهولة أكبر باستخدام مفاتيح Nostr بدلاً من Tor Onion كنقطة نهاية لمعاملات P2EP.
تطبيق آخر لـ P2EP هو LNURL المثير للجدل. باستخدام LNURL ، بدلاً من إنشاء فواتير جديدة بشكل مضجر لكل معاملة ، يمكن للمستخدمين تلقي نقطة نهاية ثابتة تشير إلى خادم ويب لإنشاء فواتير جديدة تلقائيًا. ومع ذلك ، نظرًا لأن خوادم الويب تعتمد على خدمة اسم المجال العالمية (DNS) ، فإن المستخدمين الذين يستخدمون LNURL يكشفون حتمًا عن هوياتهم لموفري الاستضافة ، وإذا لم يتم اتخاذ الاحتياطات المناسبة ، فإن عناوين IP الخاصة بهم إلى المدفوع لهم. ** اعتماد LNURL على نطاق واسع سيكون ضارًا بإخفاء الهوية لشبكة Lightning Network ****. بدلاً من استخدام خادم الويب كنقطة نهاية لـ LNURL ، يمكن للمستخدمين استخدام مفاتيح Nostr كنقطة نهاية لمعاملات LNURL لإخفاء هوياتهم. **
** Nostr for CoinJoin **
بينما يكسر PayJoin أساليب الملكية المشتركة والإسناد والتحليل بشكل جيد ، يفشل PayJoin في تزويد المرسل والمتلقي بحماية الخصوصية من الأطراف المتعاونة. PayJoin هي في الأساس CoinJoin من طرفين ، تقتصر على اثنين من المشاركين ، مما يعني أن كلا من المرسل والمستقبل يعرف مدخلاتهم ومخرجاتهم ، مما يجعل مدخلات ومخرجات شركائهم قابلة للتحديد. ما لم يتم استخدام معاملة CoinJoined لتسهيل PayJoin ، يخاطر المستخدمون بالكشف عن أرصدة المحفظة والمعاملات السابقة والمستقبلية لشركاء PayJoin.
في نظام شهادة المبلغ المجهول مثل بروتوكول تنسيق CoinJoin الخاص بـ Wasabi Wallet (WabiSabi) ، يمكن أن يعمل مفتاح Nostr كنقطة نهاية للاتصال لتنسيق معاملات CoinJoin. يسمح هذا لمرسل ومتلقي معاملة CoinJoin بتبادل بيانات الاعتماد المطلوبة للمشاركة في جولة CoinJoin ، مما يتيح طريقة دفع منفصلة في CoinJoin. باستخدام مفتاح Nostr كنقطة نهاية في CoinJoins ، تظل الأطراف المتعاونة مخفية عن الحشد ، وتبقى غير مدركة لأرصدة ومعاملات الطرف المقابل. في الوقت نفسه ، فإن استخدام مفاتيح Nostr كنقطة نهاية لمعاملات CoinJoin يساعد مستخدمي PayJoin على توفير الرسوم عن طريق إجراء المدفوعات مباشرة في CoinJoin بدلاً من تسهيل المدفوعات من خلال CoinJoin.
استخدام آخر لـ Nostr في CoinJoins هو اكتشاف المنسق. بينما يعمل معظم منسقي CoinJoin خلف Tor لإخفاء هويات المشاركين في CoinJoin ، لا يمكن للمستخدمين حاليًا اكتشاف منسقين جدد بسهولة ، باستثناء JoinMarket (سوق CoinJoin لمستخدمي CoinJoin الأكثر تقدمًا). بينما يمكن لمستخدمي CoinJoin إضافة منسقين مخصصين إلى Wasabi Wallet (بسهولة تبادل عناوين URL في الخلفية) ، نظرًا لعدم وجود نظام أساسي للنشر ، لا توجد طريقة لأتمتة عملية تحديث المنسقين. لذلك ، من أجل اكتشاف المنسقين الجدد ، يجب على المستخدمين البحث يدويًا في الوسائط الاجتماعية والمنتديات (مثل Reddit أو Twitter) لإضافة منسقين. ومع ذلك ، قد يشكل نشر خدمة منسق عبر وسائل التواصل الاجتماعي أو المنتديات خطرًا على مزود التنسيق ، اعتمادًا على السياسات المطبقة على الخدمة ، حيث قد يتم إغلاق بعض الصفحات بسهولة.
إذا كان Tor هو خادم ترحيل مجهول ، وهو بروتوكول يسهل إعادة توجيه الرسائل واستلامها بشكل مجهول بين أقرانه ، فيمكن أن يعمل Nostr كلوحة إعلانات مجهولة. يمكن لمنسقي CoinJoin نشر خدماتهم عبر نوع حدث Nostr ، ويمكن لمحافظ CoinJoin تمكين الجلب التلقائي للمعلومات من خوادم الترحيل هذه وعرضها في عملائها. يمكن لخوادم منسق البث بواسطة Nostr ، مثل المكون الإضافي CoinJoin لخوادم BTCPay والنهج المقترح في برنامج CoinJoin المستند إلى شبكة Lightning ، أن تلغي الحاجة إلى البحث يدويًا عن منسقي CoinJoin وإضافتهم في عملاء CoinJoin ، مما يزيد من اللامركزية في مشهد تنسيق CoinJoin.
** تجاوز متطلبات IP عبر NOSTR **
كما ذكرنا سابقًا ، كان المفهوم الأصلي لبروتوكول ** Nostr هو تنفيذ سوق لامركزية بالكامل يسمى Diagon Alley. ** مع تطوير بروتوكول Nostr ، أصبح Diagon Alley هو NostrMarkets ، وهو امتداد لـ LNbits: سوق يدعم Nostr يمكّن التجار والعملاء من إدارة المتاجر عبر الإنترنت والتفاعل معها من خلال المرحلات. في NostrMarkets ، يمكن للعملاء الاشتراك في المفتاح العام للتاجر والحصول على المنتجات من التتابع بدلاً من زيارة موقع التاجر عبر المتجر عبر الإنترنت. يؤدي هذا إلى زيادة مقاومة الرقابة على المتجر عبر الإنترنت لأنه بدلاً من الاعتماد على موقع ويب خاضع للرقابة ، يتم استضافة متجر التاجر بواسطة جميع المرحلات التي يتصل بها. حتى إذا تم الاستيلاء على خادم التاجر ، يمكن بسهولة إعداد المتجر في مواقع مختلفة ، لأن جميع المنتجات مخزنة على المرحل على شبكة Nostr. تتولى NostrMarkets تنسيق الطلبات والدفع عبر رسائل Nostr Direct المشفرة ، بينما تتم المدفوعات عبر شبكة Lightning Network.
بالإضافة إلى كونه مقاومًا للرقابة ، فإن امتداد NostrMarkets الخاص بـ LNbits يتيح سوقًا مجهول الهوية بالكامل. لا يكشف التجار والعملاء عن عناوين IP الخاصة بهم للعالم ، ولكن فقط للترحيل الذي يتصلون به ، ويمكن حل ذلك بسهولة عن طريق تشغيل العميل أو المتجر خلف Tor. تتمثل ميزة تشغيل المتجر بالكامل خلف Tor في أنه بينما لا يمكن الوصول إلى المتجر إلا من خلال متصفح Tor وصفحات الويب .onion ، يمكن لـ NostrMarkets العمل على أي متصفح ويب أو هاتف ذكي ، مما يحسن تجربة المستخدم في الاتصال الذي يحافظ على الخصوصية بين العميل وخادم العميل. نظرًا لأنه يتم التفاوض على المدفوعات عبر رسائل Nostr Direct المشفرة وتنفيذها عبر شبكة Lightning Network ، ستظل المدفوعات في NostrMarkets خاصة نسبيًا طالما أن عقدة Lightning في المتجر تعمل خلف Tor ، حيث لا يمكن مقارنة تنسيق الدفع بالرسائل المباشرة الأخرى في Nostr. .
هناك طريقة أخرى لتجاوز متطلبات عنوان IP في الاتصال بين الخادم والعميل وهي NOSTREST. يرمز REST إلى "النقل التمثيلي للحالة" ، وهو جزء من بنية برمجيات شبكة الويب العالمية للاتصال بين الخوادم والعملاء عبر طلبات GET و POST و PUT و DELETE و PATCH. ومع ذلك ، عندما يرسل العميل طلب REST إلى خادم ، يتم كشف عنوان IP ، ويحتمل أن يكشف عن معلومات التعريف الشخصية. على GitHub ، اقترح \ _ \ _ escapeee \ _ \ _ جسر REST API مبني على Nostr يسمى NOSTREST. باستخدام مفاتيح Nostr بدون رأس المصادقة ، لا يحتاج المستخدمون ومشغلو الخادم إلى معرفة عناوين IP لبعضهم البعض. لذلك ، يمكن أن يؤدي تطبيق NOSTREST إلى تحسين خصوصية تطبيقات Bitcoin باستخدام REST ، لأن الخادم لا يتطلب عنوان IP الخاص بالعميل.
مثال على ذلك يمكن أن يكون تشغيل صندوق Chaumian للنقد الإلكتروني ، وهو نظام قسيمة مجهول للمبالغ. في عملية سك النقود الإلكترونية ، لا يعرف مشغل سك العملة أرصدة مستخدميه أو قيمة التبادل. ومع ذلك ، نظرًا لبنية REST الحالية ، ما لم يكن يعمل خلف Tor افتراضيًا (كما هو الحال في نظام النقد الإلكتروني Cashu) ، فإنه يتعرف على عنوان IP الخاص بالمستخدم. ومع ذلك ، فإن تنفيذ وإدارة دعم Tor أمر مرهق. من خلال جسر NOSTREST ، يمكن للمشروع حماية خصوصية المستخدمين بسهولة. من خلال تشغيل أداة سك النقود الإلكترونية خلف Tor واستخدام NOSTREST للتواصل بين الخادم والعميل ، يمكن تحقيق الاتصال غير المتزامن ، بينما لا يعرف مشغل الخادم والمستخدم سوى المفتاح العام لبعضهما البعض ، مما يلغي الحاجة إلى تحديد الهوية من خلال مخاطر IP.