Een Bitcoin-node kan tegelijk een versleutelde en een onversleutelde verbinding hebben. In de documentatie van Bitcoin Core staat het gebruikte transport daarom bij iedere verbonden peer afzonderlijk. Wie wil controleren of BIP324 wordt gebruikt, heeft meer aan die verbindingsgegevens dan aan de algemene vaststelling dat zijn software versleuteling ondersteunt.
| Wat je moet weten |
|---|
| BIP324 beschrijft versleuteling van verbindingen tussen Bitcoin-nodes. |
| Bitcoin Core vermeldt het transporttype afzonderlijk voor iedere verbonden peer. |
| Het oorspronkelijke v1-transport is onversleuteld; v2 gebruikt BIP324-versleuteling. |
| BIP324 bevat geen mechanisme dat de verwachte identiteit van de andere node bevestigt. |
De specificatie van BIP324 richt zich onder meer op passief afluisteren. Bitcoin-transacties zijn publiek, maar het moment waarop een node een transactie doorgeeft kan ook informatie prijsgeven. Versleuteling moet het voor een afluisteraar lastiger maken om de inhoud van verbindingen rechtstreeks mee te lezen. Bitcoin Optech beschrijft v2-transport eveneens als communicatie tussen nodes via versleutelde verbindingen.
Twee peers, twee transporttypes
Het RPC-commando getpeerinfo geeft informatie over verbonden peers. In de documentatie voor Bitcoin Core 30.0 heet het relevante veld transport_protocol_type. De mogelijke waarden zijn detecting, v1 en v2. Bij detecting is nog niet vastgesteld welk van beide transportprotocollen de peer gebruikt. Deze documentatie is op 20 oktober 2026 geraadpleegd.
Neem als denkvoorbeeld een node met twee verbindingen. Bij peer A staat v2, bij peer B v1. Dan gebruikt de verbinding met A BIP324-versleuteling, terwijl die met B het oorspronkelijke onversleutelde transport gebruikt. De v2-regel bij A zegt dus niets over de bescherming van de verbinding met B. Dit is een uitleg van de gedocumenteerde velden, geen meting aan een draaiende node.
Het naastgelegen veld session_id beschrijft de sessie van die specifieke verbinding. Volgens de RPC-documentatie is dit veld alleen voor v2 van toepassing en is het anders leeg. Een sessienummer helpt daarmee om een versleutelde sessie te onderscheiden; het is geen identiteitsbewijs van de beheerder aan de overkant.
Wat een sessie-ID laat controleren
BIP324 maakt expliciet onderscheid tussen versleuteling en authenticatie. Het protocol bevat geen mechanisme dat via een publieke sleutel bevestigt dat de gesprekspartner de verwachte identiteit heeft. De specificatie noemt daarom ook actieve aanvallen: een aanvaller kan bijvoorbeeld tussen twee nodes gaan zitten of een verbinding laten terugvallen naar v1. De beoogde bescherming tegen passief afluisteren maakt zulke actieve aanvallen niet onmogelijk.
Voor bewust gekozen, handmatig gemaakte verbindingen noemt BIP324 wel een controle: de beheerders kunnen de protocolversie en sessie-ID’s met elkaar vergelijken. Volgens de specificatie dwingt een tussenliggende aanvaller daarmee een risico op ontdekking af. Dat vergt een vergelijking tussen beide uiteinden; alleen een sessie-ID in de eigen uitvoer lezen voert die controle nog niet uit.
