كل ما جُمع من المصادر الرسمية.
141 منشورًا
خللان في معالجة رسالة version، فيضان عدد صحيح بإشارة وخطأ منطقي في abs64، أتاحا لمهاجم تحريف الوقت المعدّل لدى الضحية حتى ترفض الكتل الجديدة باعتبارها مؤرخة في مستقبل بعيد. وكان على المهاجم أن يكون بين أول 200 نظير يتصلون. وأُصلح هذا العيب متوسط الخطورة في Bitcoin Core 0.21.0.
Bitcoin Core
معاملات يتيمة مصممة خصيصًا، غير صالحة لكن التحقق منها مكلف، كانت قادرة على شلّ عقدة لساعات، لأن كل معاملة مقبولة جديدة تطلق بحثًا تربيعيًا في ذاكرة المعاملات اليتيمة. يقطع #15644 من Pieter Wuille هذا العمل لمعالجة الرسائل الجديدة فور العثور على تطابق. ووصل الإصلاح عالي الخطورة إلى المستخدمين في Bitcoin Core 0.18.0.
Bitcoin Core
رسالة GETDATA مشوهة كانت تترك خيط net_processing يدور عند 100% من المعالج في إصدارات Bitcoin Core قبل 0.20.0، مع إضافة 1.5 MB من الذاكرة لكل نظير مهاجم. واستمرت خدمة بقية النظراء، ومن هنا التصنيف المنخفض. اكتشف John Newbery الخلل وأصلحه في #18808.
Bitcoin Core
رؤوس مبنية مباشرة فوق كتلة التكوين، لا تحتاج إلا إلى صعوبة 1، تخطت منطق نقاط التفتيش من Bitcoin Core 0.12.0 حتى 0.15.0، فكان بوسع مرسل السبام أن ينفخ mapBlockIndex بلا حد وربما يسقط العقدة بنفاد الذاكرة. أبلغ Cory Fields عن هذا الخلل متوسط الخطورة عام 2017، وأغلقه #11028.
Bitcoin Core
رسالة INV واحدة محشوة بـ 50,000 عنصر كتلة كانت تدفع العقدة إلى صف 50,000 رد getheaders بحجم نحو 1 kB لكل منها، ونظير يرفض قراءتها يبقي مخزن الإرسال ذاك البالغ 50 MB ممتلئًا. وجاء #18962 من John Newbery، المطروح كتوفير في النطاق، ليرسل GETHEADERS واحدة لكل INV، ووصل في 0.20.0.
Bitcoin Core
بحجب ردود GETDATA ثم إغراق الضحية بإعلانات زائفة لطرد معاملة من جدول g_already_asked_for ذي 50,000 عنصر، كان المهاجم يعيد الإعلان عنها مرارًا ويمنع الضحية من طلبها من أي طرف آخر. كشف John Newbery هذا الخلل متوسط الخطورة، وأصلحه #19988 من Pieter Wuille في Bitcoin Core 0.21.0.
Bitcoin Core
قبل Bitcoin Core 0.10.1 كانت الرسائل الواردة تصل إلى 32 MiB، فيفرض المهاجم حجز هذا القدر من الذاكرة لكل اتصال وربما يُسقط العقدة. أبلغ عنها المستخدم Evil-Knievel في Bitcointalk، وخفض #5843 الحد إلى 2 MiB، ثم رُفع لاحقًا إلى 4 MB مع Segwit. وتأجل كشف كان مقررًا عام 2015، فلم تخرج التفاصيل إلا في 2024.
Bitcoin Core
فيضان مخزن ثانٍ في miniupnpc، اكتشفه Wladimir J. Van Der Laan، سرّب بيانات وأمكن ربطه بـ CVE-2015-6031 لتنفيذ شيفرة عن بُعد، وقد أثبت ذلك على miniupnpc 1.6-precise في Ubuntu. لم يُنقل استغلاله مباشرة إلى Bitcoin Core، وجاء الإصلاح في الإصدار 0.12 في فبراير 2016.
Bitcoin Core
إصلاحات أخطاء تملأ Bitcoin Core 27.1: عاد رفع الرسوم في الواجهة الرسومية يعمل مع المعاملات غير الموقعة، ولم يعد حقل IP للوكيل يقبل منفذًا، وصار GetAddedNodeInfo() يكتشف نظراء CJDNS المضافين عبر addnode (#30085). كذلك تغيرت معالجة TapMiniscript أثناء التوقيع (#29853).
Bitcoin Core
يُفعَّل نقل BIP324 v2 افتراضيًا في Bitcoin Core 27.0، وتبحث خوارزمية CoinGrinder الجديدة عن أخف مجموعة مدخلات عند رسوم 30 sat/vB فما فوق. ويخرج الوقت المعدّل بالشبكة من شيفرة الإجماع لصالح وقت النظام، فتزداد أهمية دقة الساعات لدى مشغّلي العقد. وأُهملت libbitcoinconsensus، مع خطة لإزالتها في v28.
Bitcoin Core
تتوقف عقد Bitcoin Core 25.2 عن معالجة الكتل المحوّرة (#29412). ويصلح التحديث أيضًا خطأ segfault في getrawtransaction (#29003) وuse-after-free في WalletBatch::EraseRecords (#29176) وانهيار الواجهة الرسومية عند اختيار «Mask values».
Bitcoin Core
تعتمد جلسات I2P في Bitcoin Core 26.1 تشفير ECIES-X25519 وElGamal معًا (#29200)، وصارت العقدة تسجّل التقدم أثناء تحميل mempool. ومن الإصلاحات رفض معالجة الكتل المحوّرة (#29412)، ومحفظة تتخطى اختيار العملات BnB عند تفعيل SFFO (#28994).
Bitcoin Core
نقل BIP324 v2 التجريبي يظهر لأول مرة في Bitcoin Core 26.0، معطلًا افتراضيًا ويُفعَّل بـ -v2transport. ويحمّل أمر RPC الجديد loadtxoutset لقطات assumeutxo، فتصبح العقدة قابلة للاستخدام خلال دقائق بينما ينهي chainstate الأصلي تحققه في الخلفية، فيما يرسل submitpackage المعاملات الخام إلى mempool كحزمة.
Bitcoin Core
لم يعد Bitcoin Core 24.2 يقدّم تقديرات رسوم قديمة (#27622)، وصُححت معالجة RPC لعناوين bech32 غير الصالحة (#27727). وتمس أغلب التغييرات الأخرى نظام البناء وCI، ومنها إصلاح بناء حزمة Qt لـ macOS مع رابط Xcode 15 (#28543).
Bitcoin Core
تنزيل الكتل المضغوطة بالتوازي يصل مع Bitcoin Core 25.1 (#27626). وتشمل الإصلاحات الأخرى انهيار REST على /deploymentinfo (#27853)، وإيقاف الخادم بعد انقطاع عميل بعيد (#28551)، وترحيل المحافظ الذي صار يرفض النصوص غير الصالحة (#28125).
Bitcoin Core
تتسارع عمليات إعادة فحص محافظ descriptor في Bitcoin Core 25.0 عند توفر مرشحات الكتل المضغوطة BIP158 عبر -blockfilterindex=1، ويبحث أمر RPC الجديد scanblocks في تلك المرشحات. وأصبحت سياسة الترحيل تقبل المعاملات ابتداءً من 65 بايت non-witness. وفي وضع -blocksonly تنخفض ذاكرة mempool القصوى من 300MB إلى 5MB.
Bitcoin Core
تمسح المحافظ في Bitcoin Core 24.1 المفتاح الرئيسي عند القفل كي لا يبقى في الذاكرة (#27080)، ويُتفادى تلف peers.dat بالتسلسل مرة واحدة فقط (#26909). وتعمل طوابير inv-to-send أسرع (#27610)، واختفى segfault في REST عند عناوين URI غير الصالحة (#27468).
Bitcoin Core
ثلاثة تغييرات في P2P يحملها Bitcoin Core 23.2: لا مزيد من تلف peers.dat (#26909)، ولا مسح مبكر لحالة تنزيل النظراء الآخرين (#27608)، وطوابير inv-to-send أسرع (#27610). والباقي عمل على البناء وCI، مثل ترجمة bdb بـ clang-16 على aarch64.
Bitcoin Core
لم يعد deriveaddresses ينهار عند الفهرس 2147483647 في Bitcoin Core 23.1 (#26275)، واختفى segfault على MacOS 13 كانت تطلقه إشعارات معينة. وترفض الواجهة الرسومية الآن تشفير محافظ watch-only، وينتقل Qt5 إلى 5.15.3 (#24668).
Bitcoin Core
صار الخيار -persistmempool وحده يعني -persistmempool=1 في Bitcoin Core 22.1، بعدما كان يوقف خطأً حفظ mempool (#23061). ويُقرَّب حساب الرسوم إلى الأعلى لتفادي الهبوط دون المعدل المتوقع (#22949)، وأُصلح segfault في المحفظة مرتبط بـ external_spk_managers (#23333).
Bitcoin Core
