التغيير في OP_RETURN في Core v30 هو مجرد تعديل افتراضي لسياسة الإرسال - من حوالي 80 بايت إلى 100,000 بايت (فعليًا غير محدود لأن حدود حجم المعاملات تُطبق أولًا على أي حال). إنه لا يغير شيئًا في قواعد التوافق. يمكن للعقد لا تزال ضبط -datacarriersize على أي قيمة تريدها (بما في ذلك العودة إلى 83 بايت) في تكوينها الخاص. كان المعدّنون والخزّانات بالفعل أحرارًا في تضمين أي معاملات صالحة يرغبون فيها، ويمكن بالفعل تضمين البيانات عبر طرق أخرى (حلول عمل nulldata متعددة المخرجات، ونصوص Taproot، إلخ). لم يكن الحد القديم البالغ 80 بايت أبدًا حاجزًا موحدًا صارمًا؛ كان دائمًا مجرد اتفاقية إرسال تم تجاوزها عندما كانت الحوافز كافية. إن v30 يتوقف ببساطة عن التظاهر بأن مفتاح سياسة صغير يمكنه منع المستخدمين الملتزمين. إنه تقليل للضرر وصراحة حول الواقع، وليس تحولًا جذريًا في البروتوكول. من ناحية أخرى، فإن BIP-110 هو التصعيد الحقيقي المثير للجدل هنا. فهو يحاول فرض حد صارم جديد على مستوى التوافق لOUTPUTات البيانات العشوائية (العودة إلى 256 بايت أو حدود صارمة مشابهة) عبر عملية سوفت فورك. هذا سيغير ما كان صالحًا وفقًا لقواعد بيتكوين لسنوات، وسيدفع إلى نقاش عالمي للشبكة حول التحديث، ومخاطر انقسام السلسلة إذا لم تُحقق عتبات التفعيل بسلاسة، وسينهي سيادة العقد والمعدنين على ما يعتبرونه كتلًا/معاملات صالحة. الافتراضات السياسية هي خيار اختياري/إلغاء لكل عقدة. أما تغييرات التوافق فليست كذلك. واحدة هي خيار إرسال قابل للتكوين، والأخرى تحاول إعادة كتابة محيط السياسة النقدية من خلال كود يراه الكثيرون تجاوزًا. إذا كنت قلقًا بشأن "المركزية" أو "التحولات المتعمدة في البروتوكول"، فانظر إلى الجانب الذي يدفع بعملية سوفت فورك مدعومة من المستخدمين لفرض رؤيتهم لاستخدام "بيتكوين الصحيح" على الجميع. لم يُحطِّم v30 بيتكوين. إن BIP-110 هو الذي يعرضها للانقسام بسبب حرب ثقافية حول البيانات مقابل المال. في هذه المرحلة، لن أتراجع عنه أيضًا، لأنه سيشجع فقط على ردود أفعال صغيرة من قبل مجموعات UASF كلما وجد المتطفلون طريقة جديدة لتحميل البريد العشوائي.