Når en utvinner finner en blokk, teller hastighet. Jo lenger en blokk bruker på å nå andre utvinnere, desto mer sannsynlig er det at to blokker konkurrerer, og treg propagering favoriserer store, godt tilknyttede utvinnere. Likevel er de fleste transaksjoner i en ny blokk allerede i hver nodes mempool. BIP152, av Matt Corallo, unngår å sende dem to ganger. Bitcoin Core har støttet det siden versjon 0.13.0 i 2016.
Hva som sendes
En kompakt blokk inneholder 80-byte-headeren, en tilfeldig nonce, en liste med 6-byte korte transaksjons-ID-er og noen få «forhåndsfylte» fulle transaksjoner, i det minste coinbase-transaksjonen. Korte ID-er kommer fra SipHash-2-4, nøklet med et hash av headeren og noncen, så en angriper ikke kan forutsi dem på forhånd for å lage kollisjoner.
Gjenoppbygging av blokken
Mottakeren beregner korte ID-er for egne mempool-transaksjoner og matcher dem. Hvis noe mangler, spør den med getblocktxn og mottar en blocktxn. En kort-ID-kollisjon er mulig, men sjelden. Når den skjer, faller noden tilbake til å laste ned hele blokken.
To modi
- Lav båndbredde: peeren kunngjør blokken som vanlig, etter å ha validert den, og mottakeren ber om den kompakte versjonen. Dette tar 1,5 rundturer, eller 2,5 hvis transaksjoner mangler, men bruker langt mindre båndbredde enn før.
- Høy båndbredde: peeren pusher den kompakte blokken med en gang, selv før den er fullt validert. Hvis ingenting mangler, trengs ingen ekstra rundtur i det hele tatt. Bitcoin Core velger opptil 3 peere for denne modusen.
Versjoner
Versjon 1 bruker txid-er. Versjon 2 bruker wtxid-er, så de korte ID-ene dekker også witness-data. Moderne noder bruker versjon 2.
Hvorfor det betyr noe
Raskere, lettere blokkvideresending senker andelen utdaterte blokker og gjør det billigere å kjøre en fullnode. Det reduserer også fortrinnet store utvinnere får fra raske relay-nettverk.