При подписи Bitcoin Core 26.2 больше не считает TapMiniscript заведомо корректным (#29853), getnetworkhashps выдаёт ошибку на неверных параметрах (#28554), а для setmocktime введён жёсткий максимум (#29869). Сборка также работает с miniupnpc 2.2.8.
До Bitcoin Core 0.10.1 входящие сообщения могли достигать 32 МиБ, поэтому атакующий мог вынудить узел выделять столько ОЗУ на соединение и, возможно, обрушить его. Сообщил об этом пользователь Bitcointalk Evil-Knievel; #5843 снизил лимит до 2 МиБ, позже поднятый до 4 МБ для SegWit. Раскрытие, анонсированное на 2015 год, отложили, и детали стали известны только в 2024-м.
IPv6 удешевил раздувание неограниченного бан-листа Bitcoin Core, и каждое сообщение GETADDR заставляло просматривать этот список для каждого возвращаемого адреса, которых могло быть до 2500. Падение из-за нехватки памяти и нагрузку на процессор, оценённые как высокая опасность, устранил #19219, вышедший в 0.20.1 и 0.21.0.
Два бага в обработке сообщения version, переполнение знакового целого и логическая ошибка в abs64, позволяли атакующему сдвинуть скорректированное время жертвы, так что она отвергала новые блоки как датированные слишком далёким будущим. Для этого атакующий должен был оказаться среди первых 200 подключившихся пиров. Уязвимость средней опасности исправлена в Bitcoin Core 0.21.0.
Открытие поддельной платёжной ссылки BIP72 могло обрушить Bitcoin-Qt: её параметр r мог указывать на огромный файл, под который приложение пыталось выделить память, пока загрузка тихо шла в фоне. Баг средней опасности исчез, когда #17165 удалил поддержку BIP70 в 0.20.0.
Подготовленные орфанные транзакции, невалидные, но дорогие для проверки, могли остановить узел на часы: каждая новая принятая транзакция запускала квадратичный поиск по кэшу орфанов. #15644 от Pieter Wuille прерывает эту работу и переходит к новым сообщениям, как только находится совпадение. Исправление уязвимости высокой опасности дошло до пользователей в Bitcoin Core 0.18.0.
Некорректное сообщение GETDATA могло загонять поток net_processing на 100% CPU в Bitcoin Core до версии 0.20.0, добавляя по 1,5 МБ памяти на каждого атакующего пира. Остальных пиров узел продолжал обслуживать, поэтому опасность оценена как низкая. John Newbery нашёл этот баг и исправил его в #18808.
Заголовки, построенные прямо на генезис-блоке и требующие лишь сложности 1, обходили логику чекпойнтов в Bitcoin Core с 0.12.0 до 0.15.0: спамер мог неограниченно раздувать mapBlockIndex и, возможно, обрушить узел из-за нехватки памяти. Cory Fields сообщил об этом баге средней опасности в 2017 году, закрыл его #11028.
Одно сообщение INV с 50 000 блочных записей могло заставить узел поставить в очередь 50 000 ответов getheaders примерно по 1 КБ, а пир, отказывающийся их читать, держал этот буфер отправки на 50 МБ заполненным. #18962 от John Newbery, поданный как экономия трафика, отправлял один GETHEADERS на INV и вошёл в 0.20.0.
Не отвечая на GETDATA и заваливая узел фиктивными анонсами, чтобы вытеснить транзакцию из карты g_already_asked_for на 50 000 записей, атакующий мог анонсировать её снова и снова, и жертва не запрашивала её ни у кого другого. Баг средней опасности раскрыл John Newbery, а #19988 от Pieter Wuille исправил его в Bitcoin Core 0.21.0.
Wladimir J. Van Der Laan нашёл в miniupnpc второе переполнение буфера: оно раскрывало данные и в связке с CVE-2015-6031 давало удалённое выполнение кода, что он и показал на miniupnpc 1.6-precise из Ubuntu. Напрямую на Bitcoin Core его эксплойт не переносился, а исправление вошло в версию 0.12 в феврале 2016 года.
Bitcoin Core 27.1 состоит из исправлений: в GUI починено повышение комиссии для неподписанных транзакций, поле IP прокси больше не принимает порт, а GetAddedNodeInfo() теперь видит пиров CJDNS, добавленных через addnode (#30085). Изменилась и обработка TapMiniscript при подписи (#29853).
По умолчанию узлы на Bitcoin Core 27.0 общаются через транспорт BIP324 v2, а новый алгоритм CoinGrinder ищет самый лёгкий набор входов при ставках от 30 сат/вБ. Скорректированное по сети время уходит из кода консенсуса в пользу системного, так что операторам важнее следить за точностью часов. libbitcoinconsensus объявлена устаревшей, удаление намечено на v28.
Узлы на Bitcoin Core 25.2 больше не обрабатывают мутированные блоки (#29412). Кроме того, устранены segfault в getrawtransaction (#29003), use-after-free в WalletBatch::EraseRecords (#29176) и падение GUI при выборе «Mask values».
Сессии I2P в Bitcoin Core 26.1 используют шифрование и ECIES-X25519, и ElGamal (#29200), а узел теперь пишет в лог ход загрузки мемпула. Среди исправлений отказ обрабатывать мутированные блоки (#29412) и кошелёк, который пропускает выбор монет BnB при включённом SFFO (#28994).
Экспериментальный транспорт BIP324 v2 дебютирует в Bitcoin Core 26.0: по умолчанию он выключен, включается через -v2transport. Новый RPC loadtxoutset загружает снимки assumeutxo, и узлом можно пользоваться уже через несколько минут, пока исходный chainstate проверяется в фоне; submitpackage отправляет сырые транзакции в мемпул пакетом.
Устаревшие оценки комиссии Bitcoin Core 24.2 больше не отдаёт (#27622), а RPC корректно обрабатывает невалидные адреса bech32 (#27727). Прочие изменения в основном касаются системы сборки и CI, включая исправление сборки пакета Qt для macOS с линковщиком Xcode 15 (#28543).
Узлы на Bitcoin Core 25.1 могут загружать компактные блоки параллельно (#27626). Также исправлены падение REST на /deploymentinfo (#27853), остановка сервера после отключения удалённого клиента (#28551) и миграция кошельков, которая теперь отвергает невалидные скрипты (#28125).
Пересканирование дескрипторных кошельков ускоряется в Bitcoin Core 25.0, если компактные фильтры блоков BIP158 доступны через -blockfilterindex=1, а новый RPC scanblocks ищет по этим фильтрам. Политика ретрансляции теперь принимает транзакции от 65 байт без учёта witness. С -blocksonly максимальная память мемпула снижается с 300 МБ до 5 МБ.
Главное в Bitcoin Core 23.2 — три изменения в P2P: peers.dat больше не повреждается (#26909), состояние загрузки других пиров не сбрасывается преждевременно (#27608), очереди inv-to-send работают быстрее (#27610). Остальное относится к сборке и CI, например компиляция bdb через clang-16 на aarch64.