BIP324 opisuje szyfrowanie wiadomości wymienianych między węzłami Bitcoina. Węzeł to program, który sprawdza transakcje i bloki oraz wymienia dane z innymi uczestnikami sieci. Takie bezpośrednie połączenia między uczestnikami sieci nazywa się P2P, a ich szyfrowany wariant — v2 transport. Osoba jedynie podsłuchująca połączenie nie powinna móc łatwo odczytać jego treści. Samo szyfrowanie nie potwierdza jednak, z którym węzłem naprawdę rozmawiasz. Publiczny łańcuch bloków i reguły poprawności transakcji pozostają bez zmian.
Blok to pakiet transakcji dołączany do wspólnej historii Bitcoina. Bloki są publiczne, ale obserwowanie ich rozchodzenia się to nie to samo co czytanie gotowego łańcucha. Obserwator nieszyfrowanego połączenia widzi też kolejność wiadomości, zapytania i chwilę przekazania transakcji przez węzeł. To może pomóc powiązać ruch z konkretnymi osobami. BIP324 ogranicza takie łatwe odczytywanie treści przez biernego obserwatora. [1] [2] [7]
Dwa obsługujące je węzły uzgadniają klucze przy nawiązaniu połączenia, po czym komunikują się w sposób szyfrowany. Nie muszą wcześniej znać swojej tożsamości ani mieć certyfikatu centralnego organu. Właśnie dlatego szyfrowany nie znaczy godny zaufania. Drugi węzeł oczywiście odczytuje wiadomości i nadal może należeć do napastnika. [1]
Przy nawiązywaniu połączenia, podczas procedury handshake, oba węzły tworzą tymczasowe klucze. Klucz prywatny jest tajną wartością liczbową; odpowiadający mu klucz publiczny można udostępniać innym. Dzięki ECDH każdy oblicza ten sam wspólny sekret bez przesyłania kluczy prywatnych. Z tego sekretu wyprowadzane są klucze chroniące transmisję. ElligatorSwift koduje klucze publiczne tak, by ta część wymiany przypominała losowe dane i trudniej było rozpoznać ją po stałym wzorcu. Są to wyłącznie klucze połączenia sieciowego. Nie są kluczami prywatnymi do wydawania bitcoinów ani seedem, czyli tajną wartością początkową służącą do wyprowadzania kluczy portfela. Włączenie szyfrowanej transmisji nie wymaga ujawnienia kopii zapasowej portfela. [1] [8]
Wyobraź sobie, że ktoś przechwytuje wiadomość po drodze i zmienia jej treść. BIP324 używa ChaCha20Poly1305: szyfrowania z kontrolą, czy wiadomość odpowiada kluczowi połączenia i nie została zmieniona. Bez tego klucza atakujący nie może po prostu przepisać danych i utworzyć poprawnej wiadomości. Kontrola nie dowodzi jednak, że masz wspólny klucz właśnie z zamierzonym węzłem. Aktywny pośrednik może podczas nawiązywania połączeń podawać się wobec każdej strony za jej rozmówcę. Ma wtedy dwa osobne szyfrowane połączenia, czyta wiadomości i przekazuje je między nimi. Ochrona wiadomości i weryfikacja drugiej strony są więc różnymi zadaniami. [1]
Klucze zmieniają się podczas komunikacji. Jeśli stare sekrety są prawidłowo usuwane, późniejsze zdobycie aktualnych kluczy nie otwiera automatycznie całego wcześniejszego zapisu. Ta właściwość to forward secrecy. Nie chroni jednak wiadomości, które drugi węzeł już przeczytał lub zapisał. Nie pomaga też przeciwko atakującemu, który stale kontroluje komputer; najnowsza grupa wiadomości może ponadto pozostać możliwa do odczytania. [1]
Starszy v1 transport pozostaje dostępny dla zgodności. Gdy połączenie v2 zawiedzie, program może spróbować v1. Aktywny napastnik może więc blokować szyfrowane połączenia, próbując wymusić nieszyfrowany powrót. BIP324 podnosi koszt biernej inwigilacji, ale nie obiecuje ogólnej odporności na downgrade ani dostępności połączenia. [1] [4]
BIP324 nie ukrywa adresu IP ani wszystkich wzorców czasu i objętości ruchu. Adres IP to adres sieciowy, którego urządzenie używa do komunikacji przez internet. Tor może rozwiązywać inną część problemu, lecz ich połączenie również nie gwarantuje anonimowości. Niezależnie od drogi wiadomości Full Node musi sprawdzić transakcje, podpisy i bloki. Samo szyfrowanie nie rozwiązuje Eclipse Attack, w którym napastnicy otaczają węzeł. [1] [6]
Bitcoin Core 26.0 dodał obsługę v2 w 2023 roku, początkowo domyślnie wyłączoną. Wersja 27.0 włączyła ją domyślnie. Rok tego hasła oznacza zatem pierwszą obsługę w Bitcoin Core, nie powstanie propozycji. Transport jest negocjowany osobno dla każdego połączenia; zgodność programu nie oznacza, że wszyscy jego peers używają v2. [3] [4]
Operator Bitcoin Core może odczytać stan poleceniem bitcoin-cli getpeerinfo. Jest to zapytanie przez RPC, interfejs do sterowania węzłem i pobierania informacji; to polecenie nie rozgłasza transakcji w sieci Bitcoin ani nie zmienia ustawień. Wynik przedstawia każde połączenie osobno. W transport_protocol_type wartość v2 oznacza transmisję szyfrowaną, v1 starszą nieszyfrowaną, a detecting jeszcze nierozstrzygnięty wybór. Pole session_id zawiera identyfikator połączenia v2; w pozostałych przypadkach jest puste. Sama jego obecność nie weryfikuje drugiej strony. Dwaj operatorzy mogą porównać identyfikator swojego wzajemnego połączenia innym zaufanym kanałem, aby wykryć pośrednika; zwykłe połączenia nie robią tego automatycznie. Wynik opisuje to łącze, nie całą drogę transakcji przez sieć. Zawiera też dane sieciowe, których nie trzeba publikować. [5] [1]
BIP324 wymienia autorów: Dhruv Mehta, Tim Ruffing, Jonas Schnelli i Pieter Wuille. Numer przydzielono w 2019 roku; przy sprawdzeniu 17 października 2026 roku status brzmi Deployed. Wdrożenie nie wymaga Soft Fork ani zmiany podaży bitcoinów. Stopniowo ulepsza komunikację, a korzyści zależą od poprawnej implementacji i rzeczywiście używanych połączeń. [1]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Full Node, Eclipse Attack, Prywatność w Bitcoinie, Bitcoin Core. Do tego hasła prowadzą również odsyłacze z Mix Network.