إلى جانب الانهيار المعلن سابقًا، أتاحت CVE-2018-17144 لمُعدِّن تضخيم معروض بيتكوين في الإصدارات 0.15.X حتى 0.16.2 بإنفاق مخرج مرتين داخل معاملة واحدة. وحجب المطورون هذا الجزء لمنح الأنظمة وقتًا للانتقال إلى 0.16.3 أو 0.17.0rc4. ويُعتقد أن أكثر من نصف قوة التجزئة قد حُدّث، ولا تُعرف أي محاولات استغلال، ويُحث المستخدمون المتأثرون على الترقية.
تُسقط CVE-2018-17144 الإصدارات من Bitcoin Core 0.14.0 حتى 0.16.2 عند كتلة تحوي معاملة تنفق مدخلًا واحدًا مرتين، ويُطلب من المستخدمين الترقية فورًا إلى 0.16.3. ولا يقدر على إنتاج كتلة كهذه إلا مُعدِّن مستعد للتخلي عن 12.5 BTC على الأقل من الدخل الذي يحق له.
لم يعد أمر verifytxoutproof في Bitcoin Core 0.16.2 يسقط أمام هجوم مكلف على إثباتات SPV كُشف في مطلع يونيو، لكن عملاء SPV الفعليين ما زالوا عرضة له. ويجعل إصلاح منفصل abandontransaction يُسقط كل أحفاد المعاملة بدل التوقف عند أبنائها.
كفّ Bitcoin Core 0.16.1 عن ترحيل OP_CODESEPARATOR في نصوص التوقيع القديمة، وهو تغيير في السياسة يسهّل نشر إصلاحات مستقبلية للكتل البطيئة التحقق. ويفقد المُعدِّنون الخيار -blockmaxsize لصالح -blockmaxweight، ويحصلون على إصلاح لخلل ربما كلّفهم إيرادات عند إنتاج كتلتين متتاليتين بسرعة.
يصبح Segwit الخيار الافتراضي للمحفظة في Bitcoin Core 0.16.0: العناوين الجديدة من نوع p2sh-segwit ما لم يحدد -addresstype غير ذلك، ويمكن توليد عناوين bc1 الأصلية وفق BIP173 والدفع إليها. والمحافظ الجديدة من نوع HD حصرًا وترفضها الإصدارات السابقة، فيما تفعّل شاشة الإرسال في الواجهة الرسومية BIP125 RBF افتراضيًا.
احترازًا من انقسامات مستقبلية في الشبكة، يقطع Bitcoin Core 0.15.1 الاتصال بالنظراء الذين يقدمون سلسلة دون minimum-chain-work أثناء المزامنة الأولية، وبالنظراء الصادرين الذين يقدمون رؤوسًا معروفة بعدم صلاحيتها. ويؤدي رأس سلسلة عالق 30 دقيقة الآن إلى اتصال صادر إضافي. ويفقد المُعدِّنون الاستخدام المباشر لـ blockmaxsize، فقد أُهمل ولم يعد سوى مؤشر ضمني لحد الوزن.
انهيار في الواجهة الرسومية عند الإقلاع هو ما دفع إلى Bitcoin Core 0.15.0.1: فبعض العملاء الذين رقّوا إلى 0.15.0 تعثروا بإعداد رسوم مخصص لم تعد الواجهة تعرضه. ويعالج تصحيح صغير، #11332، تلك القيمة غير الصالحة.
تمتد تقديرات الرسوم في Bitcoin Core 0.15.0 إلى 1,008 كتل مقدمًا بدل 25، ويستطيع مستخدمو الواجهة الرسومية رفع رسوم معاملة غير مؤكدة عبر Replace-By-Fee. وتسرّع قاعدة بيانات chainstate القائمة على المخرجات التنزيل الأولي للكتل بنسبة 30-40%. ويجري تحويلها تلقائيًا عند التشغيل الأول في نحو 5 إلى 30 دقيقة.
لا صلة للمساهمين المنتظمين في Bitcoin Core بـ btc1، تطبيق Segwit2x، ويرفض المشروع الادعاء بأنه تحديث ضروري، واصفًا إياه بخروج خلافي عن قواعد الشبكة. أما Segwit، الانقسام الناعم المرتقب خلال أيام، فلا علاقة له بذلك الانقسام الصلب ولا يطلب شيئًا من معظم المستخدمين. ويحذر البيان أيضًا من أن Segwit2x لا يخطط لحماية قوية من هجمات إعادة الإرسال.
على كل من فعّل UPnP تثبيت Bitcoin Core 0.14.2 دون إبطاء: فخطأ في إشارة عدد صحيح داخل miniupnpc المضمّنة، CVE-2017-8798، يتيح لمهاجمين على الشبكة المحلية حجب الخدمة وربما إلحاق أضرار أخرى. ويبقى UPnP معطلًا افتراضيًا، فلا تتأثر العقد التي لم تشغّله قط.
يستطيع المُعدِّنون غير الداعمين لـ segwit مواصلة استخدام getblocktemplate بعد التفعيل، لأن Bitcoin Core 0.14.1 يحذف معاملات segwit من القالب. وتنتقل القيمة الافتراضية لـ -dbcache إلى 450MiB، ويصمد الحد الآن عند ذروات التفريغ. وتؤدي الوسائط المعاد تسميتها في createrawtransaction وdisconnectnode إلى كسر الجهات التي تستخدم الوسائط المسماة من 0.14.0.
يمكن لمحفظة عقدة جديدة الإرسال والاستلام قبل انتهاء المزامنة في وضع SPV الهجين بالكتل الكاملة ضمن خارطة طريق Bitcoin Core، إذ يجلب الكتل ابتداءً من أقدم مفتاح في المحفظة بينما يستمر التحقق الكامل في الخلفية. وتزول تسريبات الخصوصية في مرشحات Bloom مقابل عرض نطاق أكبر، وينبغي انتظار 6 تأكيدات أو أكثر للمدفوعات.
إحلال توقيعات Schnorr محل ECDSA يقلّص multisig من نوع 50-of-50 إلى حجم إنفاق بمفتاح واحد ويخفي سياسته عن المراقبين. وترى خارطة طريق Bitcoin Core أن العقبة الرئيسية هي هجوم الإلغاء، إذ يطرح موقّع خبيث مفتاح مستخدم آخر. والرد هو Delinearization، وإن كان إثبات أمانه لا يزال قيد مراجعة الأقران.
تخزين التوقيعات مؤقتًا في Bitcoin-Qt 0.7.0، وUltraprune مع LevelDB في 0.8.0، والمزامنة بالرؤوس أولًا في Bitcoin Core 0.10: هذه محطات الجزء 1 من جولة في تسريعات البرنامج المرجعي. وقد حقق التحقق المتوازي من النصوص وحده زيادة بين 35% و100% في اختبارات المطورين.
أنهت العقد الجديدة التنزيل الأولي للكتل أسرع بـ 5.7 مرة على Bitcoin Core 0.14.0 مقارنة بـ 0.13.2 في اختبار على Amazon EC2 بالإعدادات الافتراضية: 6 ساعات و24 دقيقة مقابل يوم و12 ساعة و40 دقيقة. ويعود هذا الكسب إلى الكتل المفترضة الصلاحية والذاكرة المشتركة بين mempool وذاكرة UTXO المؤقتة. وتحصل المحافظ أيضًا على رفع اختياري للرسوم، معطل افتراضيًا.
عمليات الإرسال من المحفظة التي تبلغ حد السلاسل غير المؤكدة لم تعد تعيد خطأ RPC في Bitcoin Core 0.13.2: فهي تبلّغ بالنجاح، وتُعاد محاولة إدراجها في mempool عند إعادة البث دون حاجة إلى إعادة تشغيل. وعُطلت تقديرات الرسوم لهدف كتلة واحدة، وأُصلحت معالجة الكتل المضغوطة غير الصالحة.
تغليف segwit داخل P2SH هو الأعلى كلفة بالبايت: 19% إضافية لـ P2WSH/P2SH و11% لـ P2WPKH/P2SH في معاملة من 180 بايت، بحسب جرد Bitcoin Core لما سيجلبه BIP141. ويحتاج التحقق إلى نحو خمس عمليات SHA256 إضافية لكل معاملة. وتُوزن الأخطاء البرمجية والكتل الأكبر والرسوم الأقل كمخاطر، ولا يتخذ الكتّاب موقفًا من التفعيل.
يحصل المُعدِّنون على شيفرة الإشارة إلى الانقسام الناعم segwit في Bitcoin Core 0.13.1، وتُفتح الإشارة من 15 نوفمبر 2016 مع بداية فترة إعادة الضبط التالية. يتطلب حسم التفعيل 95% من كتل فترة من 2,016 كتلة، ويبدأ سريانه بعد فترة واحدة. وتبقى المحافظ متوافقة، فقد لا يحتاج أحد إلى التحرك سوى المُعدِّنين.
يحتاج Segwit إلى موافقة فئتين: مُعدِّنون يشيرون بالبت 1 في 95% من الكتل خلال فترة إعادة ضبط، وعدد كافٍ من العقد الكاملة التي تشغّل Bitcoin Core 0.13.1 أو تطبيقًا متوافقًا. تُفتح الإشارة عند أول إعادة ضبط تقع في 15 نوفمبر 2016 أو بعده. وتخص خطوات منفصلة المُعدِّنين ومشغّلي العقد ومستخدمي المحافظ والمطورين، ومنهم من يختار عدم الترقية.
تصل شيفرة Segwit إلى Bitcoin Core 0.13.0 لكنها تبقى خاملة على الشبكة الرئيسية، فاستخدامها هناك يتطلب إصدارًا لاحقًا يُتوقع أن يكون 0.13.1. ويخفف ترحيل الكتل المضغوطة (BIP152) قفزات عرض النطاق، وتعتمد المحافظ الجديدة مفاتيح BIP32 HD، فتغطي نسخة احتياطية واحدة كل المفاتيح الخاصة المستقبلية. وتنضم نسخ Linux ARM إلى التنزيلات الرسمية.