Continuă discuțiile despre TCP hole punching pentru ca nodurile de acasă aflate în spatele routerelor să poată fi accesate. Buletinul tratează și un proiect BIP pentru standardizarea politicilor de cheltuire aplicate de co-semnatari la emularea covenanturilor.
Greg Sanders, Antoine Poinsot, Elias Rohrer, Oleksandr Kurbatov și Nishant Bansal li se alătură gazdelor Optech la recapitularea numărului #429, care începe cu Bitcoin Core #36665, #36667 și #36669, apoi trece la politica de securitate actualizată. Urmează plățile silențioase cu mai mulți participanți, o vulnerabilitate DoS dezvăluită în Core Lightning și Eclair 0.14.6; transcrierea încă nu e gata.
Un anunț de canal cu același nod la ambele capete putea să prăbușească Core Lightning, de la 25.02 la 26.04, la fiecare repornire, iar atacatorul plătea doar comisioane on-chain; remedierea a venit în 26.04.1. Numărul #429 mai aduce protocolul lui Oleksandr Kurbatov pentru intrări multiparty în plăți silențioase și versiunile de mentenanță mai rapide ale Bitcoin Core pentru bugurile ușor de descoperit.
Prefăcându-se că nu suportă pingurile BIP 31, un peer rău intenționat putea evita deconectarea de după 20 de minute și citea lent, umflând coada de trimitere a nodului cu până la 2 MB pe oră pentru fiecare peer de intrare și 5 MB pentru fiecare peer de ieșire. CVE-2026-117349, de severitate medie, e reparat prin #36667 în Bitcoin Core 32.1, 31.2, 30.4 și 29.5; nodurile -blocksonly erau mult mai puțin expuse.
Monitorizarea excepțiilor de socket funcționează acum la fel în poll() și select() în Bitcoin Core 29.5 (#36665), iar peerii cu trimiterea în pauză au un timeout impus (#36667). Pozițiile din flatfile trec pe întregi de 64 de biți (#36669), nodurile presupun v2transport pentru adresele primite de la seeduri, iar un seed DNS dispare din listă.
Un miner putea împinge un fișier undo din Bitcoin Core peste 4 GiB, ceea ce dădea peste cap pozițiile pe 32 de biți și corupea datele, astfel că nodurile se opresc dacă urmează reorganizarea potrivită; pe Windows și pe sistemele de 32 de biți eșecul apare la 2 GiB, fără reorganizare. CVE-2026-117346 are severitate scăzută și ar cere cam o lună din toate blocurile rețelei. Versiunile 32.1, 31.2, 30.4 și 29.5 repară sistemele de 64 de biți; nodurile de 32 de biți și stocarea blocurilor pe FAT32 rămân afectate.
Nodurile pe Windows, macOS și BSD puteau fi doborâte de un peer conectat care trimitea date urgente TCP: acestea treceau de citirile suspendate din backendul select() și ocupau memorie fără limită (CVE-2026-117350). Pe Linux, unde nodurile folosesc poll(), problema nu există. Bugul, de severitate medie, a ieșit la iveală la o scanare cu LLM din cadrul Project Loupe și e reparat în Bitcoin Core 32.1, 31.2, 30.4 și 29.5.
Bitcoin Core 30.4 nu mai tratează biții 5-28 din BIP 9 drept semnale de soft fork, conform BIP 323, așa că blocurile care îi setează nu mai declanșează avertismente despre activări necunoscute (#34779). La capitolul rețea apare un timeout impus peerilor cu trimiterea în pauză (#36667), iar pozițiile din flatfile trec pe întregi de 64 de biți (#36669).
Private broadcast primește o limită în Bitcoin Core 31.2: coada tranzacțiilor pe care rețeaua nu le-a trimis încă înapoi se oprește la 10.000 de poziții și, odată plină, refuză alte trimiteri, iar golirea ei rămâne pe seama apelantului, prin abortprivatebroadcast (#35406). Conform BIP 323, biții de versiune 5-28 nu mai contează ca semnale de soft fork.
Private broadcast din Bitcoin Core 32.1 nu mai riscă să expună adresa IP a expeditorului, scurgere posibilă atunci când o conexiune v2 eșuată se relua pe v1 direct, nu prin Tor. Valoarea implicită a -maxconnections urcă de la 125 la 200, iar retransmiterea tranzacțiilor către peeri are o limită de rată printr-un backlog global, nu per peer.