b-money مقترح للنقد الرقمي قدمه Wei Dai عام 1998. يصف طريقتين لتسجيل الأرصدة بصورة مشتركة ومعالجة العقود بين أشخاص بهويات رقمية مستعارة. لم يكن عملة أُطلقت أو نسخة أقدم من برنامج Bitcoin. وأدرجته Bitcoin whitepaper لاحقًا بوصفه أول مرجع لها.
تخيّل أن آنا طلبت من بيتر رسمًا عبر الإنترنت. لا يعرف أحدهما إلا الاسم المستعار للآخر. يريدان الدفع والاتفاق على ما يحدث إذا أخلف أحدهما وعده، دون كشف هويتيهما أولًا لبنك أو سلطة أخرى. اهتمت جماعة Cypherpunks، التي بحثت حماية الخصوصية بالتشفير، بمثل هذه الأسئلة. ورد Wei Dai بمقترح b-money عام 1998. لم يكن الاسم الرقمي المستعار مجرد لقب اختياري، بل مفتاحًا عامًا، أي بيانات لا يلزم إبقاؤها سرية ويستطيع الآخرون التحقق بها من توقيع رسالة. وكان إخفاء الهوية الحقيقية يعتمد أيضًا على الاتصال المجهول الذي يفترضه المقترح. [1] [2]
في مثالنا لدى آنا 10 وحدات وتريد إرسال 3 إلى بيتر. كانت ستنشر رسالة تحويل وتوقّعها رقميًا. هذا ليس صورة لتوقيع مكتوب باليد: يحسبه البرنامج من الرسالة ومفتاح خاص، أي بيانات تحتفظ بها آنا سرًا. ويستطيع الآخرون استخدام المفتاح العام للتحقق من أن حامل المفتاح الخاص المقابل هو من وقّع الأمر. يتحقق حافظو الحسابات من التوقيع وكفاية الرصيد، ويخصمون 3 من آنا ويضيفونها إلى بيتر؛ فيتبقى لها 7. ليست العملية إرسال ملف يحتوي قطعة نقدية، بل تعديل سجلات الأرصدة. وهنا يظهر السؤال الأساسي: كيف تبقى النسخ كلها متفقة إذا أرسلت آنا تعليمات متعارضة؟ التوقيع وحده لا يحقق هذا الاتفاق. [1] [5]
يجعل البروتوكول الأول، أي مجموعة القواعد المقترحة، كل مشارك يحتفظ بقاعدة بيانات للأرصدة. ولكي يجري الجميع التحديثات نفسها، يفترض قناة بث مجهولة ومتزامنة ولا يمكن تعطيلها. بمعنى أبسط، يجب أن تصل الرسائل إلى الجميع بالتنسيق الزمني اللازم، وألا يمكن منع انتشارها أو كشف مرسلها. وهذا افتراض أقوى بكثير من اتصال إنترنت عادي تتأخر فيه الرسائل أو تضيع. لذلك وصف Dai نفسه النسخة الأولى بأنها غير عملية. كانت منطلقًا للتفكير في الثانية، لا شبكة جاهزة للتشغيل. [1] [2]
لا بد للأرصدة من بداية. اقترح Dai أن ينشر أي شخص حل مسألة جديدة تتطلب حسابًا مكلفًا ويحصل مقابله على وحدات نقدية. يجب أن يسهل على الآخرين تقييم الجهد، وألا تكون للحل قيمة عملية أو فكرية إضافية. ويتحدد النقد المنشأ وفق تكلفة الحساب، مقاسة بسلة معيارية من السلع، أي مجموعة متفق عليها للمقارنة بين التكاليف. يشبه ذلك Proof of Work، إثبات بذل العمل الحسابي، لكنه ليس بعد تعدين كتل Bitcoin. والكتلة مجموعة من المعاملات تضاف إلى سجل المدفوعات المشترك. كما يتطلب تقديرًا مشتركًا للتكلفة رغم اختلاف قدرات الحواسيب وأسعارها بين الناس. [1] [2] [5]
في البروتوكول الثاني لا يحتفظ الجميع بالدفتر الكامل. تتولى المهمة مجموعة من المشاركين تسمى الخوادم. وكانت آنا وبيتر سيتحققان من معالجة الدفعة لدى جزء مختار عشوائيًا من هذه الخوادم. ولأن ذلك يتضمن قدرًا من الثقة بالمشغلين، يتعين على كل خادم إيداع ضمان مالي يمكن استخدامه لمعاقبة مخالفة مثبتة. كما تنشر الخوادم دوريًا حالة الأرصدة وإنشاء المال. يراجع المستخدم رصيده ويتحقق من أن مجموع الأرصدة لا يتجاوز المال المنشأ. هذه ضوابط محددة لحافظي الحسابات، وليست الترتيب نفسه لعُقد Bitcoin ومعدّنيها اليوم. [1]
كان المال جزءًا واحدًا من b-money. في طلب آنا وبيتر، يحدد العقد الشروط والحد الأقصى للتعويض عند الإخلال. يوقّع الأطراف وأي محكّم يتولى تقييم النزاع، ويضعون مبالغ مقررة في حساب خاص. بعد ختام متفق عليه، توزع الأموال وفق النتيجة. ويذهب المقترح أبعد: إذا لم يحل التحكيم النزاع، ينشر الأطراف حججهم، ويقدّر كل حافظ للحسابات التعويضات أو الغرامات بنفسه. هنا تظهر حدود الفكرة. يؤكد التوقيع الموافقة، لكنه لا يقرر وحده هل سُلّم الرسم فعلًا، ولا يضمن حكمًا متطابقًا من جميع حافظي الحسابات. [1] [2]
أدرك Dai صعوبة الاتفاق على التكلفة الحقيقية للحساب. تتغير التقنية، وقد يمتلك بعض المشاركين مزايا لا يعرفها الآخرون. لذلك اقترح الملحق A بديلًا يصلح للبروتوكولين. يخطط حافظو الحسابات أولًا لعدد الوحدات الجديدة. ثم يعرض الراغبون المسألة التي سيحلونها مقابل كمية المال المطلوبة، وينفذون الحساب وينشرون الحلول. ويأتي الإصدار وفق العروض المقبولة. هذه المراحل الأربع — التخطيط والعروض والحساب والإنشاء — تحل محل تقدير التكلفة وحده. وهي ليست سقف Bitcoin المحدد مسبقًا عند 21 مليونًا، ولا Halving، أي التنصيف الدوري لكمية بيتكوين الجديدة التي تُنشأ مع كل كتلة. [1] [3]
ناقش Adam Back المقترح في ديسمبر 1998. وأشار، ضمن أمور أخرى، إلى تفاوت تكلفة الحساب وإمكان ربط المدفوعات التي تستخدم أسماء مستعارة ثابتة. فإخفاء الاسم المدني لا يجعل المدفوعات غير قابلة للربط تلقائيًا. يتضمن النص الأصلي فحوصًا للخوادم، ولذلك لا يصح القول إنه تجاهل عدم الأمانة تمامًا. لكنه لم يقدم طريقة مكتملة ومختبرة عمليًا لإبقاء جميع قواعد البيانات متفقة عند الأعطال والنزاعات المختلفة. وتشكّل هذه الحالات جزءًا من المسافة بين مقترح ونظام يعمل. لذا تفيد قراءة النقاش المحفوظ إلى جانب النص نفسه. [1] [3] [7]
في 22 أغسطس 2008 كتب Satoshi Nakamoto إلى Wei Dai أن Adam Back لفت نظره إلى b-money، وسأل عن سنة نشره للاستشهاد به. أجاب Dai أنه أعلن المقترح عام 1998. ثم وضعت Bitcoin whitepaper مقترح b-money في أول قائمة المراجع. وفي رسالة أخرى بتاريخ 10 يناير 2009 أعلن Satoshi إصدار Bitcoin v0.1، وأبدى رأيه بأنه يحقق تقريبًا جميع أهداف b-money. هذه اتصالات موثقة واعتراف بفكرة سابقة. لكنها لا تثبت أن Wei Dai كتب Bitcoin، أو أن التصميمين يعملان بالطريقة نفسها، أو مقدار الحلول التقنية التي انتقلت مباشرة بينهما. [4] [5] [6]
b-money محطة مهمة في تاريخ الأفكار، لا عملة يمكن وضعها اليوم في محفظة وفق هذا المقترح. لم يُنفذ بوصفه نظام الدفع العامل الموصوف هنا. لم تكن فيه سلسلة كتل Bitcoin ولا قاعدة اختيار السلسلة الصالحة ذات أكبر عمل متراكم. لكنه طرح سؤالًا واضحًا: كيف نجمع التوقيعات الرقمية وإنشاء المال والدفتر المشترك من دون أن يدير بنك واحد كل شيء؟ جمع Bitcoin لاحقًا إجاباته الخاصة في شبكة تعمل. قراءة b-money تميز فكرة النقد الرقمي عن المهمة الأصعب: الحفاظ على حالة مشتركة قابلة للتحقق بين أشخاص لا يلزم أن يثقوا بعضهم ببعض. [1] [4] [5]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Wei Dai, السايفربانك, Reusable Proofs of Work, Proof of Work, Hashcash, Bit Gold. تشير إلى هذا المدخل أيضًا السايفربانك, Bit Gold, Wei Dai, The Genesis Book.