Een
Bitcoin-analyse over bescherming tegen quantumcomputers rekent met de verkeerde NIST-waarden. De Btrust-publicatie koppelt een handtekening van 2.420 bytes aan ML-DSA-65, terwijl de officiële standaard voor die variant 3.309 bytes voorschrijft.
CryptoBenelux controleerde
de tabel op 13 oktober rechtstreeks tegen FIPS 204. De kleinere waarden blijken bij ML-DSA-44 te horen. Voor Bitcoin maakt dat verschil uit, omdat duizenden extra bytes rechtstreeks raken aan de hoeveelheid ruimte die een eventuele quantumveilige handtekening vraagt.
Btrust zet twee ML-DSA-varianten door elkaar
De
Btrust-analyse over quantumrisico voor Bitcoin vergelijkt onder meer ML-DSA en SLH-DSA als mogelijke post-quantumhandtekeningen.
Bij ML-DSA-65
noemt de tabel een publieke sleutel van ongeveer 1.312 bytes en een handtekening van ongeveer 2.420 bytes.
Juist daar zit de fout.
| Variant | Publieke sleutel | Handtekening |
| ML-DSA-44 | 1.312 bytes | 2.420 bytes |
| ML-DSA-65 | 1.952 bytes | 3.309 bytes |
| ML-DSA-87 | 2.592 bytes | 4.627 bytes |
| Variant | Handtekening | Extra geïsoleerd budget tegenover 64 bytes |
| ML-DSA-44 | 2.420 bytes | 5.890 satoshi |
| ML-DSA-65 | 3.309 bytes | 8.120 satoshi |
| ML-DSA-87 | 4.627 bytes | 11.410 satoshi |
| SLH-DSA-SHA2-128s | 7.856 bytes | 19.480 satoshi |
| SLH-DSA-SHA2-256s | 29.792 bytes | 74.320 satoshi |
De Btrust-cijfers voor ML-DSA-65 zijn dus de waarden van ML-DSA-44.
Handtekening blijkt 36,74% groter
Het verschil is niet klein.
Een ML-DSA-65-handtekening telt volgens NIST 3.309 bytes in plaats van 2.420 bytes.
Dat is 889 bytes extra.
Gerekend als:
3.309 ÷ 2.420 − 1 = 36,74%
De correcte ML-DSA-65-handtekening is daarmee ruim een derde groter dan de waarde die in de Btrust-tabel staat.
Bij de publieke sleutel loopt het verschil nog sterker op: 1.952 bytes tegenover 1.312 bytes.
Dat betekent niet dat een toekomstige Bitcoin-transactie automatisch 36,74% duurder wordt. De vergelijking gaat uitsluitend over de handtekening zelf.
Bitcoin gebruikt nu handtekeningen van 64 bytes
De schaal van het verschil wordt duidelijk naast de huidige techniek.
BIP 340 definieert Schnorr-handtekeningen voor Bitcoin met een vaste lengte van 64 bytes. Publieke sleutels binnen die standaard gebruiken 32 bytes.
Een ML-DSA-65-handtekening van 3.309 bytes is dus meer dan vijftig keer zo groot als de ruwe 64-byte Schnorr-handtekening.
ML-DSA-87 komt op 4.627 bytes.
Dat is precies waarom een overstap naar quantumveilige cryptografie niet neerkomt op het simpelweg vervangen van één algoritme door een ander. De hoeveelheid data kan sterk toenemen.
Meer bytes kunnen meer blockruimte kosten
Bitcoin behandelt witnessdata anders dan gewone transactiedata.
Onder
BIP 141 telt witnessdata voor de blockweging lichter mee. Vier weight units vormen één virtuele byte, waarna de virtuele transactiegrootte naar boven wordt afgerond.
Daarmee kan een eenvoudig rekenmodel worden gemaakt.
Stel hypothetisch dat een toekomstige post-quantumhandtekening dezelfde witnessweging krijgt als huidige handtekeningdata. Neem alleen de handtekening mee en laat publieke sleutels, scripts en alle andere transactiedata buiten beschouwing.
Bij 10 satoshi per virtuele byte ontstaat dan:
| Variant | Publieke sleutel | Handtekening |
| ML-DSA-44 | 1.312 bytes | 2.420 bytes |
| ML-DSA-65 | 1.952 bytes | 3.309 bytes |
| ML-DSA-87 | 2.592 bytes | 4.627 bytes |
| Variant | Handtekening | Extra geïsoleerd budget tegenover 64 bytes |
| ML-DSA-44 | 2.420 bytes | 5.890 satoshi |
| ML-DSA-65 | 3.309 bytes | 8.120 satoshi |
| ML-DSA-87 | 4.627 bytes | 11.410 satoshi |
| SLH-DSA-SHA2-128s | 7.856 bytes | 19.480 satoshi |
| SLH-DSA-SHA2-256s | 29.792 bytes | 74.320 satoshi |
De gebruikte SLH-DSA-groottes komen uit
NIST FIPS 205. De standaard geeft 7.856 bytes voor SLH-DSA-SHA2-128s en 29.792 bytes voor de 256s-variant.
Dit zijn geen voorspelde Bitcoin-fees
Die satoshi-bedragen moeten strak worden afgebakend.
Het zijn geen gemeten transactiekosten en ook geen voorspelling van wat gebruikers na een quantumupgrade zouden betalen.
Het model doet slechts drie dingen: het zet de handtekening hypothetisch in witnessruimte, rekent vier witnessbytes als één virtuele byte en vergelijkt dat geïsoleerde budget met een Schnorr-handtekening van 64 bytes.
Een echte transactie bevat veel meer gegevens.
Publieke sleutels, scripts, inputs, outputs en aanvullende velden tellen eveneens mee. Ook kan de afronding van de complete transactie anders uitpakken dan wanneer één onderdeel los wordt berekend.
Een kleinere variant kiezen lost niet alles op
De fout kan ook niet worden gerepareerd door simpelweg overal ML-DSA-44 in te vullen.
ML-DSA-44, ML-DSA-65 en ML-DSA-87 zijn verschillende parameterkeuzes binnen dezelfde familie. Hun verschillende afmetingen hangen samen met verschillende beveiligingsniveaus en parameters.
Een technisch debat over Bitcoin moet daarom twee vragen tegelijk beantwoorden.
Hoe groot mag een quantumveilige handtekening worden? En welk beveiligingsniveau wil het netwerk daar tegenover zetten?
Alleen naar bytes kijken levert geen volledige keuze op.
Bitcoin ondersteunt deze handtekeningen nu niet
Er zit nog een grotere grens om de hele berekening.
Bitcoin accepteert ML-DSA en SLH-DSA niet zomaar als transactiesignaturen. Daarvoor zou protocolondersteuning nodig zijn.
De tabellen beschrijven dus geen transactietype dat iemand vandaag naar het Bitcoin-netwerk kan sturen.
Ook toekomstige ontwerpkeuzes kunnen de ruimtekosten veranderen. Ontwikkelaars kunnen bijvoorbeeld zoeken naar constructies waarbij niet iedere grote post-quantumhandtekening volledig op dezelfde manier op de blockchain terechtkomt.
De Btrust-publicatie bespreekt zelf zulke technische afwegingen.
De fout verandert wel het vertrekpunt van de discussie
De claimcheck blijft desondanks concreet.
Wie de ruimte-impact van ML-DSA-65 voor Bitcoin
bespreekt, kan niet beginnen met 2.420 bytes en een publieke sleutel van 1.312 bytes.
NIST zet daar 3.309 en 1.952 bytes tegenover.
De 2.420 en 1.312 bytes bestaan wel degelijk, maar horen bij ML-DSA-44.
Dat lijkt een klein labelprobleem in een technische tabel. Voor een netwerk waar iedere byte uiteindelijk meeweegt in schaarse blockruimte, is 889 extra bytes per handtekening een heel andere rekensom.