Gavin Andresen

لا يصون البرنامج نفسه حين يتراجع مؤسس المشروع عن الواجهة. يحتاج إصلاح الأخطاء والاختبار وإصدار النسخ الجديدة إلى تنسيق. تولى Gavin Andresen هذه المسؤولية بعد ساتوشي في السنوات الأولى لبيتكوين. ويعرض تعريف MIT الخاص بلقاء ⁦17⁩ نوفمبر ⁦2015⁩ هذا التاريخ، ويذكر Wladimir van der Laan بوصفه المسؤول الرئيسي عن الصيانة حينها. هذه وظيفة في تطوير البرنامج وليست ملكية للشبكة. كما أن السيرة القديمة لا تثبت وجود صلاحية حالية للدخول إلى المستودع، أي المكان المشترك الذي يُحفظ فيه الكود المصدري. [1]

قد يفهم المبتدئ فكرة النقود الرقمية، لكنه يصعب أن يجرب استلامها وإرسالها دون أن يمتلك عملات. عالج أندرسن هذه العقبة بخدمة Bitcoin Faucet. أعلنها في ⁦11⁩ يونيو ⁦2010⁩، ووضع فيها رصيدًا أوليًا قدره ⁦1,100⁩ BTC، وعرض خمس عملات للتجربة. لم يعد الزائر مضطرًا إلى انتظار نجاح التعدين أو البحث عن بائع. كانت الخدمة توزع أموالًا موجودة بالفعل، ولا تنشئ بيتكوين جديدة أو مكافأة كتلة. الغرض كان تسهيل التجربة الأولى، لا تغيير قواعد إصدار النقود. [2]

في رد بتاريخ ⁦11⁩ يونيو ⁦2010⁩، أوضح أندرسن الحد: خمس عملات لكل عنوان IP، وليس كل يوم. عنوان IP يحدد اتصالًا في شبكة حاسوبية؛ وهو ليس عنوان محفظة بيتكوين ولا سجلًا موثوقًا بالأشخاص. لذلك لم تكن حماية الخدمة مساوية للتحقق من الهوية. وكان CAPTCHA، أي اختبار يساعد على التمييز بين الإنسان والبرنامج الآلي، مطروحًا كإجراء إضافي محتمل. من المهم فصل هذه البداية عن التغييرات اللاحقة، وعدم إعادة تصوير الماضي على أساس عمل الخدمات المشابهة اليوم. [2]

تناولت مساهمة أخرى مشكلة عملية مختلفة. قد يريد المستلم اشتراط عدة توقيعات قبل إنفاق المال. فهل يجب على المرسل التعامل مع القاعدة كاملة في كل مرة؟ يصف ⁦BIP 16⁩ من عام ⁦2012⁩ أسلوب Pay to Script Hash: يشير الدفع إلى hash، أي بصمة رقمية قصيرة للسكربت الذي يحتوي الشروط. وBIP مقترح مرقم لتحسين Bitcoin. أما السكربت نفسه، المسمى هنا redeemScript، فيقدمه من ينفق الأموال لاحقًا. لا تختفي الشروط؛ إنما يتغير موعد تقديمها والطرف المسؤول عنه. [3]

تخيل صندوق مال لا يُفتح إلا بموافقة عدة أشخاص. عرض قواعده وحده لا يخرج المال منه. وبالمثل، يطلب ⁦BIP 16⁩ من عام ⁦2012⁩ التحقق من hash الخاص بالسكربت redeemScript المقدم، ثم تنفيذ شروطه. معرفة السكربت لا تغني عن التوقيعات المطلوبة. وهناك أيضًا حد تقني قدره ⁦520⁩ بايت لهذا السكربت المدرج؛ والبايت وحدة لقياس حجم البيانات. ما يهم المبتدئ هو الفصل بين فحصين: تقديم القاعدة الصحيحة، وامتلاك ما تطلبه تلك القاعدة. [3]

في عام ⁦2015⁩، قدم أندرسن ⁦BIP 101⁩ لزيادة الحد الأقصى لحجم الكتلة تدريجيًا. تصف الوثيقة التغيير بأنه Hard Fork: أي إن القواعد القديمة سترفض بعض الكتل التي تسمح بها القواعد الجديدة. يصنف السجل المقترح بأنه Closed، أي مغلق. في المقابل، يحمل ⁦BIP 16⁩ حالة Deployed، أي مطبق. وجود رقم BIP أو اسم مؤلف معروف لا يثبت التفعيل. وعند قراءة مقترح، يجب أيضًا التحقق مما إذا كانت قواعده قد دخلت الاستخدام فعلًا. [4] [3]

لماذا أثار توسيع الكتل خلافًا؟ تستوعب الكتلة الأكبر معاملات أكثر، لكن بياناتها تحتاج إلى إرسال واستقبال وتحقق. لذلك يناقش ⁦BIP 101⁩ من عام ⁦2015⁩ تكاليف النقل وخطر أن تمنح المتطلبات الأعلى أفضلية للمشغلين الكبار. قد يواجه صاحب الاتصال البطيء ظروفًا مختلفة عن شركة تعدين ضخمة. توقعات المؤلف بشأن تقدم التقنية حجة لصالح مقترحه، وليست نتيجة مقاسة لكل ظرف مستقبلي. المسألة هي الموازنة بين السعة وإمكان التحقق من الشبكة بصورة مستقلة. [4]

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