W drugim tygodniu sierpnia 2026 r. pseudonimowy deweloper Bitcoina znany jako Calle opublikował zdanie, które rykoszetem obiegło branżę: „Everything is broken, Bitcoin is burning" — wszystko jest zepsute, Bitcoin płonie. Za hiperbolą stał zbiór danych. Wolontariacki Bitcoin Red Team właśnie przepuścił Kimi K3 od Moonshot AI — chiński model graniczny o otwartych wagach, opublikowany ledwie dwa tygodnie wcześniej — przez praktycznie cały open source’owy ekosystem Bitcoina: portfele, aplikacje Lightning, biblioteki płatności i narzędzia wokół nich. Po około 108 godzinach — czasu kampanii, przepracowanego przez zespół, który urósł do dwudziestu pięciu osób — na 501 projektach zespół zarejestrował 7 958 potencjalnych ustaleń bezpieczeństwa, z czego 1 280 sklasyfikowanych jako wysokie lub krytyczne.
Ta jedna kampania kondensuje wszystko, o czym jest ten artykuł: co modele AI potrafią już zrobić bazie kodu, kto celuje nimi w Bitcoina, co znajdują — i dlaczego europejskie rozporządzenie, które zaczyna gryźć 11 września 2026 r., zmienia to wszystko z historii inżynierskiej w prawną.
Napastnicy byli pierwsi
Zanim obrońcy się uprzemysłowili, zrobili to napastnicy. Łańcuch dostaw open source, od którego zależą Bitcoin i szersza branża aktywów cyfrowych, od lat znajduje się pod trwałym, motywowanym finansowo atakiem — a ekosystem krypto konsekwentnie był zamierzoną ofiarą.
We wrześniu 2025 r. napastnicy sphishowali opiekuna chalk, debug i szesnastu innych narzędzi
npm — pakietów o łącznie miliardach cotygodniowych pobrań — i wypuścili krypto-clipper, który
podpinał się pod API przeglądarki i po cichu podmieniał adresy odbiorców dokładnie w chwili, gdy
użytkownik portfela zatwierdzał transakcję, dobierając nawet adresy napastnika po wizualnym
podobieństwie, by ujść wykryciu. Kilka tygodni później robak Shai-Hulud dodał samorozprzestrzenianie,
zmieniając izolowane przejęcia opiekunów w reakcje łańcuchowe. W marcu 2026 r. biblioteka
Axios — rzędu stu milionów cotygodniowych pobrań — była przez niecałe trzy godziny wyposażona w
backdoora przez przejęte konto opiekuna, równolegle z kampanią TeamPCP, która w jeden tydzień
skompromitowała cztery szeroko używane projekty open source. A w lipcu 2026 r. napastnicy
wsunęli backdoora przebranego za „telemetrię" do SDK blockchaina Injective, wpinając eksfiltrację
fraz seed i kluczy prywatnych wprost w funkcje wyprowadzania kluczy portfeli; zautomatyzowana
publikacja rozniosła go w kilka minut na osiemnaście pakietów.
Kierunek marszu jest mierzalny. Raport Sonatype State of the Software Supply Chain 2026 naliczył ponad 454 600 nowych złośliwych pakietów open source w samym 2025 r. — skok o 75 % rok do roku, pchający skumulowaną liczbę blokad ponad 1,2 miliona. Ewoluują też narzędzia po stronie ofensywnej: Google Threat Intelligence Group doniosła w 2026 r., że po raz pierwszy zidentyfikowała aktora zagrożeń władającego exploitem zero-day, który według jej oceny opracowano z użyciem AI, przeznaczonym do masowej eksploatacji.
Repozytoria open source są celem właśnie dlatego, że są warstwą zaufania. Nikt nie musi włamywać się do waszej infrastruktury, jeśli może zatruć zależność, którą instalujecie dobrowolnie. A nigdzie ta dźwignia nie jest większa niż w oprogramowaniu dotykającym kluczy i pieniędzy.
Klęska ColdCard
Pod koniec lipca abstrakcyjne ryzyko stało się ryzykiem zmieniającym życie. Od 30 lipca 2026 r. napastnik zaczął opróżniać to, co miało być najbezpieczniejszą kryjówką Bitcoina: zimne przechowywanie. W kolejnych falach — największa zgarnęła 1 082 BTC z 1 196 portfeli w zaledwie 41 minut, według rachuby Galaxy Research — strata sięgnęła 1 367 BTC — około 88,6 mln dolarów — na 4 585 adresach wygenerowanych na portfelach sprzętowych ColdCard firmy Coinkite, według punktu kontrolnego Galaxy z 1 sierpnia. Późniejsze rachuby przekroczyły 1 800 BTC i zbliżały się do 130 mln dolarów po doliczeniu podejrzewanej czwartej fali. (Korekta: wcześniejsza wersja tej notatki podawała 116 mln dolarów — wziętych z krążących doniesień i potem niemożliwych do prześledzenia do żadnego źródła, które by tę kwotę podało, datowało i zdefiniowało. Większe sumy doliczają falę jeszcze tygodnie później opisywaną jako niepotwierdzona, a własne zastrzeżenie Galaxy warto nosić przy liczbie — dopasowywali adresy wzorcem i nie użyli mocy obliczeniowej, by dowieść, że te seedy były słabe.) Według opublikowanego mechanizmu nic z tego nie wymagało phishingu, skradzionego urządzenia ani żadnego fizycznego dostępu — klucze zrekonstruowano offline. Te wykluczenia wynikają z tego, jak działała wada; komunikaty producenta nie twierdzą, że każdą z nich zbadano i wykluczono. Tysiące długoterminowych posiadaczy, którzy zrobili wszystko, co nakazuje ortodoksja samodzielnego przechowywania — portfel sprzętowy, klucze offline, nienaruszona przerwa powietrzna — patrzyło, jak oszczędności życia opuszczają adresy, które tylko oni mieli kontrolować. Przyczyna źródłowa była miażdżąco przyziemna: flaga kompilacji firmware’u, wypuszczona w marcu 2021 r., kazała dotkniętym urządzeniom pomijać dedykowany sprzętowy układ losowości i cofać się do słabego programowego PRNG, zawalając efektywną entropię — do ledwie około 40 bitów na starszych egzemplarzach Mk3 — na tyle, że frazy seed dawały się zrekonstruować offline. Matematyka Bitcoina wytrzymała; oprogramowanie wokół niej — nie. Coinkite wypuścił awaryjny firmware, zniszczył podatne zapasy i błagał użytkowników o migrację — przyznając zarazem, że żadna łatka nie naprawi seeda już wygenerowanego na podatnym firmwarze.
Potem przyszła wojna narracji. Prezes Coinkite, Rodolfo Novak, ujął exploita jako „a sober reality of the new AI paradigm" — trzeźwą rzeczywistość nowego paradygmatu AI: przegląd kodu wspierany przez AI wydobywa dziś ukryte błędy szybciej niż najbardziej doświadczeni ludzcy eksperci, a każdy firmware, który jest lub kiedykolwiek był publiczny, należy uznawać za poddany maszynowej lustracji — przez napastników i obrońców jednako. To twierdzenie jest sporne, a uczciwość każe to powiedzieć. Nie zidentyfikowano żadnego napastnika. Nie pojawił się żaden dowód, że wadę znalazł model — własne sformułowanie Coinkite brzmi, że „musimy założyć" („we have to assume"), iż ktoś użył AI na opublikowanym firmwarze, a w tym samym dokumencie firma ujawnia, że jej własny przegląd AI, przeprowadzony kilka tygodni wcześniej, „nie znalazł tego błędu ani niczego poważnego" („did not find this bug or anything serious"). Wcześniejsza wersja tej notatki pisała też, że specjaliści bezpieczeństwa ostro oponowali — że flaga kompilacji wyłączająca sprzętowy RNG to ludzka porażka inżynierska, którą konwencjonalny przegląd powinien był wychwycić lata wcześniej. Przy ponownym sprawdzeniu nie zdołaliśmy tego utrzymać: jedyny wpis, który wytropiliśmy, leży na zawieszonym koncie, a najbliższy komentator z nazwiskiem, jakiego znaleźliśmy, raczej przyznawał Coinkite rację, niż oponował. Argument nadal wydaje się nam słuszny — ale jest teraz nasz, a nie przypisany. W pewnym sensie spór jest jednak poboczny. Czy AI znalazła ten błąd, czy nie — ekosystem wie już, że modele potrafią dowodliwie znajdować błędy dokładnie tej klasy dokładnie w tym tempie — i zareagował, jakby zagrożenie było realne. W ciągu dni giełda Boltz wstrzymała operacje, by uprzedzić próby włamań napędzanych AI. I zebrała się wolontariacka kontrsiła.
Wzlot red teamu w Bitcoinie
Bitcoin Red Team uformował się w ciągu dni po drenażu ColdCard: awaryjna, wolontariacka kontrsiła szesnastu badaczy prowadzonych przez Calle u boku prezesa AnchorWatch Roba Hamiltona, wsparta około 40 000 dolarów mocy obliczeniowej AI i wspierana przez OpenSats, którego nowy program grantowy Code RED nagradza dziś odpowiedzialne ujawnianie podatności w całym ekosystemie. Metoda łączy analizę napędzaną AI z ludzką weryfikacją — modele przeczesują portfele, implementacje Lightning i biblioteki; badacze odtwarzają i osądzają; wiarygodne ustalenia idą prywatnie do opiekunów, zanim cokolwiek zostanie opublikowane.
Trajektoria jego liczb opowiada, co AI robi z ekonomią odkrywania podatności. Pierwszy sprint złożył 4 962 ustalenia na 390 projektach w 27,5 godziny — 85 krytycznych i 635 wysokich, co według rachunków Calle przy starcie daje rząd jednego krytycznego exploita na badacza na godzinę. Kilka dni później rozszerzone przeczesanie stało na 7 958 ustaleniach na 501 projektach. Podsumowanie Calle: podstawowy skan praktycznie całego open source’owego ekosystemu Bitcoina jest ukończony, a nisko wiszące owoce zerwane.
Ustalenia niosą fakturę, która znaczy więcej niż sumy. Podatności skupiały się w starszych i słabo przeglądanych bazach kodu. Oprogramowanie związane z Lightning — strukturalnie złożone, wrażliwe na wydajność, trudne do audytu — niosło nieproporcjonalną ekspozycję. Powszechność implementacji w C oznaczono jako trwałe ryzyko strukturalne. A szybkość, z jaką projekt odpowiadał na prywatne zgłoszenie, okazała się diagnozą samą w sobie: tempo reakcji, zauważył zespół, to widoczny wskaźnik zdrowia projektu. Projektom nieutrzymywanym, ostrzegli, nie należy ufać.
Kampania przyniosła już zweryfikowany, realny skutek. BTCPay Server — jeden z najszerzej wdrażanych samodzielnie hostowanych procesorów płatności Bitcoin — wydał 7 sierpnia wersję 2.4.2, łatającą krytyczne obejście uwierzytelniania dwuskładnikowego, przypisane częściowo badaczom Bitcoin Red Team — a następnie potwierdził, że wadę już wykorzystywano w praktyce do wykradania danych logowania portfeli Lightning. To cała teza w jednym incydencie: podatność była prawdziwa, była używana, a przegląd wspierany maszynowo dotarł do niej wcześniej, niż zrobiłaby to większość ludzi.
Warto powiedzieć wprost, ile to kosztowało. Szesnastu wolontariuszy, około 40 000 dolarów mocy obliczeniowej, kilka tygodni — i dyscyplina, na którą większość finansowanych programów bezpieczeństwa nigdy się nie zdobywa: najpierw prywatne ujawnienie, publikacja dopiero gdy opiekunowie mieli ustalenia, i własny wskaźnik reprodukcji podany publicznie, a nie zakopany. Zmapowali ekosystem, który przez dekadę pozostawał niezmapowany, i oddali wyniki za darmo. Cokolwiek nastąpi w tym artykule, to jest wzorzec prowadzenia tej pracy, a ekosystem Bitcoina jest w tym miesiącu bezpieczniejszy niż w zeszłym — dzięki nim.
Jedno ograniczenie tej pracy zasługuje na jasne wypowiedzenie, bo rutynowo bywa błędnie czytane jako wybór metodologiczny. Zespół doniósł, że ograniczenia użycia amerykańskich modeli do badań bezpieczeństwa wielokrotnie ich blokowały — pchając ich ku modelom o otwartych wagach jak Kimi K3 i GLM 5.2 od Z.ai, które można uruchamiać lokalnie bez strażników polityk. Kimi K3 nie był kompromisem; do tej pracy, w tamtej chwili, należał do najlepszych instrumentów, których faktycznie wolno im było użyć.
To porażka polityk, nie porażka badań. Dobór narzędzi w badaniach bezpieczeństwa kształtuje dziś mniej jakość modeli, a bardziej to, kto w ogóle pozwala na pracę — a zespół, który sięga po model, jaki rzeczywiście wykona zadanie, postępuje słusznie. Zachodnie laboratoria powinno to zastanowić: badania obronne i tak się odbędą. Jedyne pytanie brzmi: na czyich modelach — i czy ci, którzy je prowadzą, są wpychani w węższą skrzynkę narzędziową, niż mają napastnicy.
Co naprawdę znaczy 7 958 ustaleń
Tu należy się uczciwość — i zespół pierwszy ją oddał. Z 7 958 ustaleń 24,7 % miało odtwarzalny proof of concept — to sformułowanie samego zespołu — a 29,4 % zgłoszono upstream według ostatniej rachuby; liczby te zespół opublikował sam, zamiast je zaokrąglać w niebyt. (Wcześniejsza wersja tej notatki pisała „dynamicznie odtworzone"; to była nasza glosa, nie ich, a wskaźnik zgłoszeń oznacza ustalenia wysłane opiekunom, nie ustalenia przez opiekunów przyjęte.) Wspólna ocena brytyjskiego AI Security Institute i amerykańskiego CAISI uznała Kimi K3 za zdolnego, lecz dalekiego od nieomylności — 32 % w benchmarkach tworzenia exploitów, przed GLM-5.2, ale wyraźnie za najsilniejszymi modelami zamkniętymi, i bez osiągnięcia wykonania dowolnego kodu na żadnej z 41 testowanych próbek.
To więc nie jest lista 7 958 możliwych do wykorzystania dziur w Bitcoinie i nikt z zaangażowanych tego nie twierdził. Własne ujęcie Calle było bez ogródek: kandydaci są tani, a jeśli nie radzicie sobie z wynikającym z tego przeciążeniem informacją, użyjcie AI do sortowania. To właściwa lektura i wskazuje prawdziwe przesunięcie. AI uczyniła generowanie kandydatów niemal darmowym. Nie uczyniła darmowym osądu, który oddziela potwierdzoną, odtwarzalną, poprawnie ocenioną podatność od prawdopodobnie brzmiącej halucynacji — tego samego problemu „AI slop", w którym opiekunowie open source, od curl począwszy, toną.
Rzadki zasób w bezpieczeństwie po cichu przeniósł się z wykrywania na osąd. To właściwość technologii, nie wada czyjejkolwiek kampanii — a przeczesanie mapujące cały ekosystem i podpisana ocena pojedynczej bazy kodu to po prostu różne zawody. Pierwsze mówi, gdzie patrzeć. Druga jest tym, co regulator, nabywca albo ubezpieczyciel faktycznie przyjmie. Każdy poważny aktor w tym polu — napastnik, obrońca, opiekun, regulator — stoi już poniżej tego wąskiego gardła.
Bruksela nastawia zegar
W tę kolizję wkracza unijny Cyber Resilience Act, a jego timing trudno o ostrzejszy.
Od 11 września 2026 r. art. 14 CRA zobowiązuje producentów produktów z elementami cyfrowymi sprzedawanych w UE do zgłaszania każdej aktywnie wykorzystywanej podatności, o której się dowiedzą — w 24 godziny wczesne ostrzeżenie, w 72 godziny pełne zgłoszenie i w 14 dni raport końcowy — równocześnie do ENISA i wyznaczonego krajowego CSIRT, przez jednolitą platformę zgłoszeń. Kluczowe: dotyczy to produktów już będących na rynku, nie tylko nowych wydań. Rozporządzenie stosuje się następnie w pełni od 11 grudnia 2027 r., niosąc wiążące wymogi bezpieczeństwa w fazie projektowania, obowiązek z załącznika I przeprowadzania skutecznych i regularnych testów i przeglądów bezpieczeństwa, dokumentację techniczną zawierającą sprawozdania z tych prób oraz obowiązki przechowywania rozciągające się na dekadę. Kary z art. 64 sięgają 15 mln euro albo 2,5 % całkowitego światowego rocznego obrotu, w zależności od tego, która kwota jest wyższa.
Złóżcie teraz obie połowy tego artykułu. Kampanie wspierane przez AI wydobywają tysiące kandydackich podatności w ekosystemach open source w ciągu tygodni — a niektóre z nich, jak wada BTCPay, są aktywnie wykorzystywane, co jest dokładnie wyzwalaczem zgłoszenia z CRA. Producent, którego produkt osadza skompromitowaną zależność — albo wadę, którą przeczesanie AI wydobyło, a napastnik dopadł pierwszy — nie mierzy się już z cichą inżynierską poprawką. Mierzy się z prawnym zegarem 24 godzin. A producent bez żadnego procesu odkrywania może naruszyć art. 14 nie przez brak zgłoszenia, lecz przez to, że nigdy nie wiedział, iż było co zgłaszać.
Niewygodny wniosek: wiele kodu wysyłanego dziś w tych produktach jest pisane przez maszyny, a wiele stosowanego do niego przeglądu wykonują te same modele, które go napisały. Kod napisany przez model i przejrzany przez ten sam model nie został przejrzany przez nikogo. Regulatorzy, nabywcy, ubezpieczyciele i korporacyjne zespoły bezpieczeństwa zbiegają się w tym samym pytaniu — a „nasz model sprawdził własny wynik" nie jest odpowiedzią, którą którykolwiek z nich przyjmie.
Obalanie jako dyscyplina: metoda CounterProof
Przeczesanie i ocena odpowiadają na różne pytania, a ta druga jest miejscem naszej własnej praktyki. CounterProof nie zaprojektowano w warsztacie jako produkt; narastał, gdy zabezpieczaliśmy własną infrastrukturę płatności z kryptografią progową — tam, gdzie defekt, który się prześlizgnie, nie kosztuje relacji z klientem, lecz operatora jego własne środki.
Ograniczenie, które go ukształtowało, było odwrotnością tego z Red Teamu. Oni potrzebowali szerokości: 501 projektów, szybko, na jakimkolwiek modelu, który udźwignie pracę. My potrzebowaliśmy, by jedno ustalenie przetrwało publiczną pomyłkę — na kodzie trzymającym nasze własne pieniądze. Szerokość wybacza fałszywy alarm; podpisana ocena nie. Inny problem, inna metoda — a my mieliśmy luksus doboru instrumentów, czyli dokładnie to, czego opisane wyżej ograniczenia polityk im odmówiły.
CounterProof bierze wąskie gardło osądu na wprost, protokołem ukształtowanym przez opisane wyżej tryby awarii. Każda ocena to adwersaryjny przegląd wielu linii: niezależne rodziny modeli — nie drugi przebieg tego samego — atakują każde ustalenie i próbują je obalić, a spory rozstrzyga czytanie źródła, nie głosowanie.
Ten ostatni punkt nie jest roszczeniem do lepszych modeli. Jest twierdzeniem o zmierzonej właściwości wszystkich: werdykt recenzenta to próbka, nie pomiar. Dajcie temu samemu modelowi te same bajty dwa razy, a nie zawsze zwróci tę samą odpowiedź; dajcie pytanie kilku rodzinom, a zawiodą w różnych kierunkach — to jedyny powód, dla którego uruchamianie kilku jest warte kosztu. Widzieliśmy, jak model z pewnością siebie „poprawiał" odwołanie regulacyjne i się mylił, podczas gdy model bez dostępu do źródła słusznie odmówił odpowiedzi w ogóle. Lekcja nie brzmi, że któraś linia jest lepsza. Brzmi: pojedyncza linia — jakakolwiek — nie może sprawdzić samej siebie. Nic nie wychodzi bez próby obalenia. Każde ustalenie, które przetrwa, jest potem albo potwierdzane względem rzeczywistego źródła — dokładny plik i wiersz, ścieżka reprodukcji, klasyfikacja skutków, z odwołaniami maszynowo rozwiązanymi względem dokładnie przeglądanej rewizji — albo jawnie oznaczane jako jedynie prawdopodobne. Każde ustalenie wskazuje szczebel dowodowy, który faktycznie osiągnęło — ślad w źródle, dowód kompilacji, test albo reprodukcja na żywo — i nigdy nie sugeruje wyższego. A każdy raport niesie stały kontrakt wycofania: jeśli ustalenie okaże się błędne, zostaje wycofane na piśmie.
Innymi słowy: tam, gdzie przegląd ery AI generuje szum w skali przemysłowej, wynik CounterProof jest celowo przeciwieństwem kolejki triażu. To podpisana, stopniowana dowodowo ocena pod trwałym identyfikatorem zlecenia — zbudowana tak, by przekazać ją zespołowi due diligence czy ubezpieczycielowi albo włączyć do dokumentacji technicznej CRA jako sprawozdanie z prób w kształcie załącznika VII pkt 6, poświadczające obowiązek testowania. Niezależność jest strukturalna: nie wydajemy żadnej oceny kodu napisanego przez CounterProof ani przez jakąkolwiek spółkę naszej grupy — a nasza własna baza kodu, w dużej mierze pisana przez maszyny, nieustannie przechodzi przez ten sam adwersaryjny rejestr. Byliśmy własnym pierwszym klientem i pozostajemy najtrudniejszym.
Wkrótce uruchomimy nową usługę na CounterProof.io, rozszerzającą tę praktykę na zespoły stojące dokładnie wobec zbiegu, który opisuje ten artykuł: kod pisany przez maszyny, przeciwnicy w tempie maszyn i zegar regulatora. Więcej wkrótce.
Dokąd to zmierza
Trzy przewidywania, trzymane luźno.
Po pierwsze: luka triażu poszerzy się, zanim się zamknie. Modele o otwartych wagach będą się poprawiać, przeczesania jak to Bitcoin Red Teamu będą powtarzane w innych ekosystemach, a stosunek ustaleń kandydackich do zweryfikowanych pogorszy się, zanim narzędzia osądu i zdyscyplinowane metody nadgonią. Projekty będą coraz częściej oceniane — przez użytkowników, ubezpieczycieli i nabywców jednako — po tempie odpowiedzi na ujawnienia, dokładnie jak zauważył Calle.
Po drugie: CRA stanie się funkcją wymuszającą, którą bug bounty nigdy nie były. Dobrowolne normy ujawniania dały przez dekadę łaciate pokrycie; obowiązek zgłoszenia w 24 godziny z karami skalowanymi obrotem zrobi w osiemnaście miesięcy to, czego dobra wola nie zrobiła — a popyt na regularne, niezależne, dokumentacyjnej jakości testy bezpieczeństwa przebuduje rynek audytu wokół dowodów, a nie odznak.
Po trzecie, i najbardziej fundamentalne dla Bitcoina: ekosystem, którego model bezpieczeństwa opiera się na otwartym przeglądzie, zaraz odkryje, czy przegląd maszynowy się liczy. Uczciwa odpowiedź: liczy się tylko wtedy, gdy niezależna strona jest gotowa zweryfikować ustalenie, ocenić dowody i podpisać. Wykrywanie zautomatyzowano. Odpowiedzialności — nie, i nie da się. Tam mieszkają teraz wartość i odpowiedzialność.
CounterProof to niezależna praktyka adwersaryjnego przeglądu Clavestra Capital Limited (Malta). Proof poświadcza; CounterProof obala. counterproof.io — Ta strona jest tłumaczeniem angielskiego oryginału; w razie rozbieżności rozstrzyga oryginał.
Źródła: komunikat bezpieczeństwa Coinkite oraz doniesienia Forbes, Bloomberg, CBC i Galaxy Research o exploicie ColdCard (lip.–sie. 2026); ujawnienia Bitcoin Red Team via Bitcoin Magazine, Decrypt, crypto.news, Coinpaper i Metaverse Post (sie. 2026); nota wydania BTCPay Server 2.4.2; wspólna ocena modeli UK AISI / US CAISI; Sonatype State of the Software Supply Chain 2026; Google Threat Intelligence Group, raport o aktywności zagrożeń wspieranej AI (2026); analiza StepSecurity kompromitacji SDK Injective (lip. 2026); doniesienia o incydentach łańcucha dostaw npm (wrz. 2025 – mar. 2026); rozporządzenie (UE) 2024/2847 (Cyber Resilience Act), art. 13–14, 16, 69, załączniki I i VII.