Bitcoin-nettverket bruker rundt 900-950 EH/s regnekraft i september 2026, og vanskelighetsgraden ligger på omtrent 125-127 billioner etter en oppjustering på 1,31 % den 5. september. Bak disse tallene gjemmer det seg et problem den nyeste generasjonen mining-protokoller er bygget for å løse: for få aktører bestemmer hvilke transaksjoner som havner i neste blokk. Stratum V2 flytter den makten fra poolen og tilbake til den enkelte miner. I denne veiledningen setter vi opp et fullt fungerende Stratum V2-miljø fra bunnen av, steg for steg, med Stratum-referanseimplementasjonen (SRI) koblet mot en lokal Bitcoin Core-node.

Du trenger ingen ASIC-maskinvare for å følge med. Vi bruker SRIs innebygde miner-simulator til å teste hele kjeden, fra malforhandling til innsending av delte løsninger (shares). Når oppsettet fungerer i simulator, er veien kort til å peke en ekte Antminer eller Whatsminer mot proxyen din.

Veiledningen er bygget for tre typer lesere. Hobbymineren med et par rigger hjemme i garasjen får et praktisk oppsett som kjører gjennom en Translator Proxy uten fastvarebytte. Driftsansvarlige i mindre miningfarmer får en oversikt over hvilke pooler som faktisk tar imot V2-trafikk i dag, og hvilke som fortsatt bare snakker den gamle protokollen. Utviklere som vil forstå selve protokollen, får en gjennomgang av hver enkelt rolle i referanseimplementasjonen, fra Template Provider til Job Declarator. Uansett hvilken kategori du havner i, bygger vi oppsettet i samme rekkefølge: forstå komponentene først, test dem isolert med simulator, og koble til ekte maskinvare og en produksjonspool til slutt.

Hva er Stratum V2, og hvorfor blir det viktig nå

Stratum V2 er en fullstendig omskrevet versjon av mining-protokollen som har koblet ASIC-maskinvare til pooler siden 2012. Der den gamle protokollen kun sendte jobber én vei, fra pool til miner, åpner Stratum V2 for at miner og pool kan forhandle. Ifølge Stratum-prosjektets offisielle nettside er målet et opplegg som gjør “mining-operasjoner mer effektive, lønnsomme, sikre, private og desentraliserte”. Det er en bred ambisjon, men kjernen er enkel: miner skal kunne bygge sin egen blokkmal i stedet for å ta imot en ferdig pakke fra poolen.

Adopsjonen er fortsatt beskjeden. Ifølge en analyse fra Spark Money stod protokollen bak under 5 % av total hashrate per midten av 2026, til tross for at forskningsprosjektet startet allerede i 2020. Samtidig skjedde det noe konkret i mai 2026: sju store pooler som til sammen representerer rundt 75 % av global hashrate, blant dem Foundry USA, AntPool, F2Pool, SpiderPool, MARA Pool, Block Inc. og DEMAND Pool, meldte seg inn i Stratum V2 Working Group. Det er langt fra full utrulling, men det er et tydelig retningsskifte fra bransjens tyngste aktører.

For norske og nordiske miningoperatører, som ofte kjører rigger i kalde datahaller i Nord-Norge og Sverige, betyr dette to ting. For det første kommer flere pooler til å tilby V2-tilkobling i løpet av de neste 12-18 månedene, så det lønner seg å forstå protokollen nå. For det andre gir V2 deg som operatør reell mulighet til å velge egne transaksjoner, noe som er relevant om du kjører en sikret mining-installasjon og vil redusere avhengigheten av én enkelt pool-operatør.

Det finnes også en ren driftsmessig grunn til å bry seg om dette nå fremfor senere. Overgangen fra V1 til V2 skjer gradvis, pool for pool, og de operatørene som allerede har testet et V2-oppsett når deres foretrukne pool åpner produksjonstilgang, slipper å gjøre alt arbeidet under tidspress. Å bygge og feilsøke et nytt protokolloppsett midt i en driftsperiode med kalde vintermåneder og høy strømpris er langt mer stressende enn å teste det i ro og mak mens Stratum V1 fortsatt er hovedsporet.

Stratum V1 sine svakheter: sentralisering og sikkerhetshull

Stratum V1 ble aldri designet med sikkerhet som førsteprioritet. Protokollen sender kommandoer i klartekst over TCP, uten kryptering og uten autentisering av verken pool eller miner. En angriper som sitter mellom minerens rigg og poolens server, kan i teorien lese og endre trafikken uten at noen av partene merker det. Det gir opphav til tre kjente svakhetsklasser: hashrate-kapring, hvor trafikk omdirigeres til en annen pool, job-injeksjon, hvor falske jobber sendes til minere, og sensur av transaksjoner, fordi det er poolen, og bare poolen, som bestemmer hvilke transaksjoner som havner i blokkmalen.

Det siste punktet er det mest alvorlige i et desentraliseringsperspektiv. Når en håndfull pooler kontrollerer transaksjonsvalget for over halvparten av Bitcoins hashrate, kan de i prinsippet ekskludere bestemte transaksjoner fra blokker, enten på eget initiativ eller etter press utenfra. Stratum V2 fjerner ikke dette problemet med et trylleslag, men det fjerner den tekniske hindringen som gjorde det vanskelig for individuelle minere å bygge sine egne maler i utgangspunktet.

Konsentrasjonen i poolmarkedet illustrerer hvorfor dette betyr noe. Per data samlet inn i september 2026 kontrollerer Foundry USA alene rundt 26-27 % av global hashrate, tilsvarende 240-245 EH/s, mens AntPool og F2Pool sitter på henholdsvis rundt 150 EH/s og 127 EH/s. Tre-fire aktører kontrollerer dermed en betydelig andel av all blokkbygging på nettverket, noe som gjør spørsmålet om hvem som velger transaksjoner langt mer enn en teoretisk øvelse.

Ingen av dette betyr at de store poolene har misbrukt posisjonen sin i praksis. Poenget er strukturelt: så lenge protokollen kun tillater ett sted å bygge blokkmalen, finnes det ingen teknisk hindring mot at noen gjør det en dag. Stratum V2 fjerner den strukturelle muligheten ved å spre malbyggingen ut over tusenvis av individuelle noder i stedet for å samle den hos noen få pooloperatører. Det er samme logikk som ligger bak argumentet for å kjøre egen full node fremfor å stole blindt på en tredjeparts blokkjede-API.

Slik fungerer jobbforhandling og malbygging (Job Declaration)

Kjernefunksjonen i Stratum V2 heter Job Declaration, eller jobbforhandling. I den offisielle spesifikasjonen beskrives den som en funksjon som lar miner deklarere, altså bygge og foreslå, sin egen jobb i stedet for å motta en ferdig pakket versjon fra poolen. Ifølge Stratum-protokollens spesifikasjonsdokumentasjon er dette “en nøkkelfunksjon i Stratum V2 som forbedrer Bitcoins desentralisering”, fordi den hindrer pooler fra ensidig å påtvinge minere et bestemt sett med jobber.

I praksis fungerer det slik: minerens Job Declarator Client (JDC) kobler seg til en lokal Bitcoin-node via en Template Provider, henter en fersk blokkmal med minerens foretrukne transaksjoner, og sender kun en kompakt beskrivelse av malen (ikke hele malen) til poolens Job Declarator Server (JDS) for godkjenning. Poolen validerer at proof-of-work-arbeidet er gyldig og håndterer utbetaling, men den bestemmer ikke lenger hvilke transaksjoner som er med. Ifølge OpenSats, som finansierer deler av Stratum V2-utviklingen gjennom åpen kildekode-tilskudd, introduserer protokollen “tre nye underprotokoller som lar minere velge transaksjonssett og forbedre desentraliseringen”.

Det finnes også en lettere variant for minere som ikke ønsker å drifte egen node. Da lar man poolen fortsatt bygge malen, men all kommunikasjon går gjennom krypterte, autentiserte kanaler i stedet for klartekst. Du får dermed sikkerhetsgevinstene fra Stratum V2, kryptering, autentisering og redusert kapringsrisiko, uten selv å måtte kjøre en full node med Template Provider. I denne veiledningen bygger vi likevel den fulle varianten, siden den gir best forståelse av hvordan komponentene henger sammen.

Forutsetninger: maskinvare, programvare og versjoner

Før du starter installasjonen, sørg for at maskinen din oppfyller kravene under. Vi tester på en dedikert Linux-maskin eller VM, ettersom SRI er bygget for Linux-miljøer og Bitcoin Core krever betydelig diskplass for en full node.

KomponentMinimumskrav / versjonMerknad
OperativsystemUbuntu 24.04 LTS eller nyereDebian-baserte distroer fungerer også med mindre tilpasninger
Bitcoin Core31.1 (siste stabile per september 2026)Sjekk alltid gjeldende versjon før installasjon, versjon 32.0 er i sluttesting med planlagt stabil lansering 10. oktober 2026
Rust-verktøykjedeNyeste stabile versjon via rustupSRI er skrevet i Rust og bygges med cargo
RAMMinst 8 GB, 16 GB anbefaltBitcoin Core alene krever typisk 4-8 GB for validering
DiskplassMinst 700 GB ledig (SSD anbefalt)Full blokkjede pluss indeksering, bruk gjerne pruning i testfasen
NettverkStabil bredbåndstilkoblingInitial blokk-synk kan ta flere dager avhengig av linjehastighet
Git og build-verktøybuild-essential, pkg-config, libssl-devNødvendig for å kompilere både Bitcoin Core og SRI fra kildekode

Du trenger ikke en full, synkronisert node for å følge selve veiledningen. Du kan kjøre Bitcoin Core i regtest-modus mens du lærer deg komponentene, og først koble til mainnet når du er komfortabel med oppsettet. Det sparer deg for dagevis med synkronisering under testing.

Arkitekturen i Stratum-referanseimplementasjonen

Den offisielle referanseimplementasjonen ligger på GitHub under organisasjonen stratum-mining/stratum og er delt inn i separate roller som hver kjører som egne prosesser. Å forstå disse rollene på forhånd gjør resten av oppsettet langt enklere å følge:

  • Template Provider – kobler seg til Bitcoin Core og leverer ferske blokkmaler basert på nodens mempool
  • Job Declarator Client (JDC) – kjøres av miner, henter maler fra Template Provider og forhandler jobb med poolen
  • Job Declarator Server (JDS) – kjøres av poolen, godkjenner eller avviser jobbforslag fra JDC
  • Pool – validerer innsendte shares, fordeler belønning og kommuniserer med JDS
  • Translator Proxy – oversetter mellom eldre Stratum V1-maskinvare og Stratum V2-nettverket, slik at eksisterende ASIC-er kan delta uten fastvareoppdatering
  • Mining Device / simulator – selve ASIC-en, eller SRIs innebygde testverktøy som simulerer en miner uten fysisk maskinvare

For en operatør som allerede kjører eldre Antminer- eller Whatsminer-enheter, er Translator Proxy den viktigste komponenten. De aller fleste ASIC-er på markedet i dag snakker fortsatt kun Stratum V1 i fastvaren, og en fastvareoppgradering til V2 er verken tilgjengelig eller nødvendig for de fleste modeller ennå. Proxyen lar deg beholde eksisterende maskinvare og fastvare uendret, samtidig som trafikken mot poolen krypteres og forhandles etter V2-standard.

Legg merke til at hver rolle kjører som en selvstendig prosess med eget nettverksgrensesnitt. Det er en bevisst designbeslutning fra SRI-teamet, og den gir deg flere praktiske fordeler sammenlignet med en monolittisk mining-klient. Du kan for eksempel kjøre Template Provider og Bitcoin Core på én dedikert maskin med god diskplass, mens Translator Proxy kjører på en lettere maskin fysisk plassert nærmere riggene dine for å minimere nettverkslatens. Skulle én rolle krasje eller trenge en omstart for oppdatering, påvirker det ikke nødvendigvis de andre rollene, så lenge du har bygget inn en enkel omkoblingsmekanisme mot en reserveadresse.

Steg 1-3: Installer avhengigheter og hent kildekoden

Start med å oppdatere systemet og installere byggeverktøy, deretter Rust-verktøykjeden, og til slutt selve SRI-repoet.

# Steg 1: Oppdater systemet og installer byggeavhengigheter
sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential pkg-config libssl-dev git curl cmake

# Steg 2: Installer Rust via rustup
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
source "$HOME/.cargo/env"
rustc --version

# Steg 3: Klon Stratum-referanseimplementasjonen
git clone https://github.com/stratum-mining/stratum.git
cd stratum
git log -1 --oneline

Kjør rustc --version for å bekrefte at installasjonen fungerte. Dukker det opp en feilmelding om manglende linker, mangler du sannsynligvis build-essential-pakken. Gå tilbake til Steg 1 og installer den på nytt. Sjekk alltid README-filen i det klonede repoet for eventuelle endringer i byggeprosessen, ettersom et aktivt utviklet prosjekt som dette oppdateres jevnlig.

Steg 4-6: Bygg SRI og sett opp en Template Provider mot Bitcoin Core

Med kildekoden på plass er neste skritt å bygge prosjektet og koble det mot en Bitcoin Core-node. Vi bruker regtest-modus i denne fasen for å unngå å vente på full synkronisering.

# Steg 4: Bygg hele arbeidsområdet med cargo
cargo build --release

# Steg 5: Start Bitcoin Core i regtest-modus med RPC aktivert
bitcoind -regtest -daemon \
  -rpcuser=stratumtest \
  -rpcpassword=endre_dette_passordet \
  -rpcallowip=127.0.0.1 \
  -txindex=1

# Steg 6: Bekreft at noden kjører og svarer på RPC-kall
bitcoin-cli -regtest -rpcuser=stratumtest -rpcpassword=endre_dette_passordet getblockchaininfo

Byggeprosessen i Steg 4 tar gjerne 10-20 minutter avhengig av maskinens CPU-kraft, siden hele arbeidsområdet med alle roller kompileres samtidig. Vent til kommandoen er ferdig før du går videre. Når getblockchaininfo returnerer et JSON-svar med feltet chain: "regtest", er noden klar til å levere blokkmaler til Template Provider-komponenten i SRI-oppsettet.

Steg 7-9: Konfigurer Job Declarator Server og Client

Nå setter vi opp forhandlingslaget. JDS kjøres på poolsiden av oppsettet (i vårt tilfelle lokalt, for testformål), mens JDC kjøres på minersiden og henter maler fra Template Provider.

# Steg 7: Naviger til Job Declarator Server-rollen og kopier eksempelkonfigurasjon
cd roles/jd-server
cp config-examples/jds-config-example.toml jds-config.toml

# Steg 8: Naviger til Job Declarator Client-rollen og gjør det samme
cd ../jd-client
cp config-examples/jdc-config-example.toml jdc-config.toml

# Steg 9: Start begge rollene i separate terminalvinduer (fra prosjektroten)
cargo run --release --bin pool_sv2 -- -c roles/jd-server/jds-config.toml
cargo run --release --bin jd_client -- -c roles/jd-client/jdc-config.toml

Kontroller alltid de eksakte katalog- og filnavnene mot README-filen i repoet du klonet, ettersom navngivning kan endre seg mellom versjoner av et aktivt utviklet open source-prosjekt. Åpne konfigurasjonsfilene i en editor og pek adressefeltene mot 127.0.0.1 med portnumrene du selv velger, så lenge de samsvarer mellom filene. Lagre en kopi av original-eksemplene før du endrer noe, det gjør det enkelt å nullstille om noe går galt underveis.

Steg 10-12: Sett opp Translator-proxy for eksisterende ASIC-maskinvare

Dette er trinnet som gjør protokollen praktisk anvendelig for de fleste. Translator-proxyen tar imot vanlig Stratum V1-trafikk fra ASIC-en din på én side, og snakker Stratum V2 med resten av nettverket på den andre siden.

# Steg 10: Naviger til translator-rollen
cd ../translator
cp config-examples/proxy-config-example.toml proxy-config.toml

# Steg 11: Rediger konfigurasjonen slik at upstream peker mot din JDC/pool-oppkobling
# og downstream-porten er den ASIC-en (eller simulatoren) skal koble seg til
nano proxy-config.toml

# Steg 12: Start proxyen
cargo run --release --bin translator_sv2 -- -c proxy-config.toml

Når proxyen starter uten feilmeldinger, lytter den nå på en lokal port du selv definerte i konfigurasjonsfilen. Det er denne adressen (for eksempel stratum+tcp://192.168.1.50:PORT) du senere legger inn i mining-fanen på ASIC-ens webgrensesnitt, akkurat slik du i dag peker den mot en vanlig Stratum V1-pooladresse. Ingen fastvareoppdatering er nødvendig, siden ASIC-en fortsatt bare snakker V1 mot proxyen.

Steg 13-14: Koble til en pool og verifiser jobbforhandlingen

Siste steg er å bekrefte at hele kjeden fungerer, fra blokkmal til innsendt share. Bruk SRIs innebygde simulator før du kobler til fysisk maskinvare, slik at du kan feilsøke uten å risikere nedetid på en ekte rigg.

# Steg 13: Start miner-simulatoren mot translator-proxyens lytteport
cd ../test-utils/mining-device
cargo run --release -- --address 127.0.0.1:PORT

# Steg 14: Følg loggen til Job Declarator Client for å se forhandlingen skje
tail -f jd-client.log | grep -i "job\|template\|share"

Et vellykket oppsett gir deg logglinjer som ligner på dette eksempelet, hvor klienten henter en mal, forhandler den med poolen og mottar en godkjent jobb tilbake:

[INFO jd_client] New template received from Template Provider, height=142
[INFO jd_client] Declaring job to pool JDS endpoint
[INFO jd_client] Job declaration accepted, job_id=8f3a1c
[INFO translator_sv2] Downstream connection established from mining device
[INFO pool_sv2] Share submitted, difficulty target met, accepted=true

Ser du accepted=true på siste linje, fungerer hele kjeden: Template Provider, JDC, JDS, Translator Proxy og mining-enheten snakker sammen som de skal. Da er du klar til å bytte ut simulatoren med en fysisk ASIC og, når du er trygg på oppsettet, koble Bitcoin Core-noden til mainnet i stedet for regtest.

Sikkerhet: Noise-protokollen og kryptert kommunikasjon

Sikkerhetsgevinsten i Stratum V2 kommer i stor grad fra at all kommunikasjon mellom rollene krypteres og autentiseres ved hjelp av Noise-protokollrammeverket, det samme kryptografiske rammeverket som blant annet WireGuard bygger på. I motsetning til Stratum V1, hvor hvem som helst med nettverkstilgang kunne lese eller endre trafikken, må begge parter i en Stratum V2-tilkobling bevise sin identitet før jobbdata utveksles. Det gjør angrep som hashrate-kapring og job-injeksjon vesentlig vanskeligere å gjennomføre i praksis, siden angriperen ikke lenger kan late som om den er en gyldig pool eller miner uten riktige nøkler.

I konfigurasjonsfilene for både JDC og pool-rollen setter du opp nøkkelpar som brukes til denne autentiseringen. Behandle disse nøklene med samme aktsomhet som du ville gjort med en privat nøkkel i en hardware-lommebok: aldri i klartekst i et delt repo, aldri sendt over usikrede kanaler, og med jevnlig rotasjon om driftsmiljøet tillater det. Mister noen tilgang til proxyens nøkkelfil, kan de i prinsippet late som å være din mining-enhet overfor poolen din.

Et praktisk poeng mange overser: kryptering i Stratum V2 er ikke valgfri på samme måte som TLS ofte er det i webtrafikk. Håndtrykket mellom to roller feiler helt om nøklene ikke stemmer, i stedet for å falle tilbake til en usikret tilkobling. Det er en fordel fra et sikkerhetsperspektiv, siden det umuliggjør en stille nedgradering til klartekst, men det betyr også at en feilkonfigurert nøkkelfil stopper hele kjeden i stedet for å gi deg en svakere, men fungerende tilkobling. Test derfor alltid nøkkeloppsettet ditt i regtest-miljøet før du ruller det ut mot en produksjonspool.

Ytelse og overvåking: hva du bør måle etter oppsett

Når systemet er oppe, er det tre målepunkter som forteller deg om oppsettet faktisk fungerer godt over tid, ikke bare at det startet uten feil. Det første er tiden fra en ny blokk dukker opp i mempoolen til Template Provider har en oppdatert mal klar til JDC. Lang forsinkelse her betyr at riggene dine i praksis jobber lenger på utdaterte maler enn nødvendig, noe som stjeler litt effektiv hashrate uansett hvor kraftige ASIC-ene dine er.

Det andre målepunktet er andelen godkjente kontra avviste shares gjennom Translator Proxy, sammenlignet med samme tall fra da riggen kjørte ren Stratum V1 mot poolen direkte. En vesentlig økning i avviste shares etter overgangen peker som regel mot en nettverks- eller klokkeproblemstilling, ikke en feil i selve protokollimplementasjonen. Det tredje er responstid på Noise-håndtrykket ved oppstart av en ny tilkobling. Stiger denne markant over tid, kan det tyde på ressursmangel på maskinen som kjører proxyen, spesielt på eldre maskinvare med begrenset CPU-kapasitet.

Sett opp enkel logging til en sentral fil eller et overvåkingsverktøy du allerede bruker, i stedet for å stole på at du husker å sjekke terminalvinduer manuelt. Et rigg-parkoppsett med mer enn noen få enheter blir fort uoversiktlig uten sentralisert logging, og de fleste feil som oppstår i produksjon viser seg først som et mønster over tid, ikke som en enkelt dramatisk feilmelding.

Stratum V1 vs Stratum V2: full sammenligning

EgenskapStratum V1Stratum V2
KrypteringIngen, ren klartekst over TCPNoise-protokollen, kryptert og autentisert
Hvem bygger blokkmalenAlltid poolenMiner, via Job Declaration (valgfritt)
Motstandsdyktighet mot sensurLav, poolen velger transaksjoner aleneHøyere, individuell miner kan velge egne transaksjoner
BåndbreddebrukRelativt høy pga. verbose JSON-meldingerLavere, binært meldingsformat
Kompatibilitet med eldre ASIC-fastvareNativ støtte i all eksisterende maskinvareKrever Translator Proxy for eldre fastvare
Adopsjon blant store pooler (medio 2026)Standard hos de fleste poolerUnder 5 % av global hashrate ifølge Spark Money-analyse

Hvilke mining-pools støtter Stratum V2 akkurat nå

Adopsjonsbildet er delt i tre kategorier. Én gruppe pooler kjører allerede Stratum V2 i produksjon og tar imot ekte tilkoblinger fra minere. En annen gruppe har meldt seg inn i Stratum V2 Working Group og forbereder infrastruktur, men har ennå ikke åpnet V2-tilgang for vanlige brukere. En tredje gruppe har foreløpig ikke annonsert noen planer i det hele tatt.

PoolStatus per august/september 2026Merknad
Braiins PoolKjører Stratum V2 i produksjonProtokollens opphavspool (tidligere Slush Pool), full støtte for Job Declaration
DEMAND Pool (DMND)Kjører Stratum V2 i produksjonLansert som første V2-native pool i november 2025
ckpool / solo ckpoolStratum V2-støtte lagt tilLagt til via commit 31. juli 2026, bak byggeflagget HAVE_SV2
Foundry USAMedlem av Working Group, forbereder infrastrukturKjører fortsatt Stratum V1 i produksjon per d-Central-sammenligningen
AntPoolMedlem av Working GroupV2-tilgang ikke offentlig tilgjengelig ennå
F2PoolMedlem av Working GroupV2-tilgang ikke offentlig tilgjengelig ennå
ViaBTCIngen kjent V2-planKjører kun Stratum V1, ingen offentlig kunngjøring om V2-støtte

Merk deg spesielt OCEAN-poolens DATUM-protokoll, som er en beslektet, men separat tilnærming bygget på samme grunntanke som Stratum V2. Med DATUM kjører miner en lokal full node pluss en DATUM-gateway og velger selv sine transaksjoner, mens poolen kun leverer coinbase-strukturen for utbetaling. Det er ikke identisk med SRI-implementasjonen vi har bygget i denne veiledningen, men målet, å flytte transaksjonsvalget vekk fra poolen, er det samme.

Migrering fra et eksisterende Stratum V1-oppsett uten driftsstans

De færreste operatører bytter ut hele driftsmiljøet på én gang. Den tryggeste veien er å kjøre V1 og V2 parallelt en periode, og flytte over rigg for rigg i stedet for å slå av hele riggparken samtidig. Start med én enkelt ASIC koblet gjennom Translator Proxy mens resten av flåten fortsetter uendret mot poolen som i dag. Dette gir deg et reelt produksjonstestmiljø uten å sette hele inntekten på spill om noe skulle feile i overgangen.

La testriggen kjøre gjennom minst én full vanskelighetsjustering, altså rundt to uker, før du flytter flere enheter over. I den perioden bør du sammenligne akseptert hashrate og antall avviste shares mot søsterrigger som fortsatt kjører Stratum V1. Er tallene sammenlignbare, er det trygt å utvide utrullingen. Ser du en markant økning i avviste shares eller uventede tilkoblingsbrudd i loggene til Translator Proxy, er det et tegn på at nettverkskonfigurasjonen, ikke selve protokollen, trenger justering før du går videre.

Hold også en enkel reserveplan klar: en Stratum V1-pooladresse du kan legge inn direkte på ASIC-ens webgrensesnitt om Translator Proxy skulle krasje midt i en driftsøkt. Siden ASIC-en uansett bare snakker V1 i fastvaren, tar det under et minutt å bytte tilbake manuelt hvis proxyen faller ut, og du unngår at rigger står helt stille mens du feilsøker.

Økonomien bak overgangen: er det verdt bryet

Stratum V2 endrer ikke hvor mye du tjener per innsendt share, protokollen påvirker ikke selve utvinningsbelønningen. Gevinsten ligger andre steder: redusert risiko for at trafikken din kapres eller manipuleres, og for de som bruker Job Declaration, muligheten til selv å inkludere transaksjoner med høye gebyrer i egen blokkmal i stedet for å stole blindt på poolens utvalg. I en periode hvor hashprice ligger rundt 38-40 dollar per PH/s per døgn ifølge Hashrate Index sine tall fra begynnelsen av september 2026, er marginene stramme nok til at selv små forbedringer i gebyrfangst kan telle over tid.

Kostnaden ved å komme i gang er i hovedsak tid, ikke kroner. Selve programvaren er åpen kildekode og gratis å kjøre, og du trenger ikke ny maskinvare siden Translator Proxy håndterer eldre ASIC-fastvare. Den reelle investeringen er timene det tar å sette opp, teste og overvåke et nytt lag i infrastrukturen, pluss eventuelt en dedikert liten server til Bitcoin Core-noden om du vil kjøre Template Provider selv. For en operasjon med noen titalls rigger er dette typisk et par dagers arbeid for en driftstekniker som allerede kjenner Linux og nettverkskonfigurasjon.

Vanlige fallgruver ved Stratum V2-oppsett

De fleste problemer med et ferskt Stratum V2-oppsett skyldes noen få gjentagende feil. Her er de vi støter oftest på når nye operatører setter opp SRI for første gang:

  • Å blande porter mellom rollene. JDC, JDS, pool og translator-proxy bruker hver sin port, og en enkel skrivefeil i én konfigurasjonsfil gjør at to komponenter aldri finner hverandre. Dobbeltsjekk at portnummeret i “upstream”-feltet på én rolle er identisk med “listen”-porten på rollen den skal koble seg til.
  • Å starte rollene i feil rekkefølge. Template Provider og Bitcoin Core må være oppe og synkronisert før JDC startes, ellers feiler malhentingen stille uten en tydelig feilmelding.
  • Å glemme txindex på Bitcoin Core-noden. Uten -txindex=1 kan enkelte rolle-kombinasjoner mangle data de trenger for å bygge fullstendige blokkmaler.
  • Å bruke gamle eksempelfiler etter en oppdatering. SRI er et aktivt utviklet prosjekt, og konfigurasjonsformatet endres fra tid til annen. Kjør alltid git pull og sammenlign din config mot det ferskeste eksempelet før du rapporterer en feil som en bug.
  • Å anta at fastvaren på ASIC-en må oppgraderes. Mange nye brukere prøver å finne en Stratum V2-fastvare til sin Antminer før de innser at Translator Proxy gjør akkurat den oppgraderingen overflødig.
  • Å teste direkte mot mainnet før simulatoren fungerer. Regtest og den innebygde miner-simulatoren finnes nettopp for å isolere feil uten å vente på ekte blokktider eller risikere nedetid på produksjonsutstyr.

Feilsøking: de vanligste problemene og løsningene

Under følger de feilene og løsningene vi oftest ser i praksis, sortert etter hvor i kjeden problemet vanligvis oppstår.

  • “Connection refused” fra JDC mot Template Provider. Bitcoin Core kjører ikke, eller RPC-legitimasjonen i konfigurasjonen samsvarer ikke med det du satte i bitcoind-kommandoen. Kjør bitcoin-cli getblockchaininfo manuelt for å isolere om problemet ligger i noden eller i SRI-konfigurasjonen.
  • Cargo-bygget feiler med manglende OpenSSL-headere. Installer libssl-dev på nytt og kjør cargo clean før du bygger på nytt.
  • Translator-proxy starter, men ASIC-en kobler seg aldri til. Sjekk at brannmuren tillater trafikk på proxyens lytteport, og at ASIC-ens mining-URL bruker riktig IP-adresse for maskinen proxyen kjører på (ikke 127.0.0.1 om ASIC-en er en separat fysisk enhet på nettverket).
  • JDC henter mal, men JDS avviser jobbforslaget. Sjekk klokkesynkronisering mellom maskinene. Noise-protokollens autentisering er tidssensitiv, og et betydelig klokkeavvik kan gi avviste håndtrykk.
  • Shares sendes inn, men vises aldri som “accepted” i loggen. Kontroller at vanskelighetsgradsmålet (difficulty target) i pool-konfigurasjonen er satt lavt nok for en simulator eller testrigg. For høy vanskelighetsgrad i testmiljø gir sjelden eller aldri en godkjent share.
  • Bygget tar veldig lang tid eller går tom for minne. Reduser antall parallelle byggejobber med cargo build --release -j 2 på maskiner med begrenset RAM.
  • Regtest-noden produserer ingen nye blokker. Regtest krever manuell blokkgenerering. Bruk bitcoin-cli -regtest generatetoaddress for å simulere blokktider under testing.
  • Rollene starter, men logger ingenting. Sjekk loggnivået i konfigurasjonsfilen, standardnivået i enkelte eksempelfiler er satt til kun å vise alvorlige feil. Sett det til “info” eller “debug” mens du feilsøker.

Avanserte tips: DATUM, solo-mining og ytelsesjustering

Når grunnoppsettet fungerer stabilt, er neste steg å vurdere hvilken driftsmodell som passer din situasjon. Solo-mining via ckpool med Stratum V2-støtte er nå teknisk mulig for operatører som vil eie hele kjeden selv, fra node til blokkmal, uten å dele belønning med en pool i det hele tatt. Det krever mer teknisk overvåking og gir langt høyere varians i utbetalinger, men gir også maksimal kontroll over transaksjonsvalget.

Et alternativ er OCEAN-poolens DATUM-protokoll, verdt å sammenligne mot SRI-basert Job Declaration om målet primært er å velge egne transaksjoner uten å bygge hele infrastrukturen selv. Uansett hvilken vei du velger, bør du overvåke latensen mellom Template Provider og JDC nøye. Trege maloppdateringer betyr at minere jobber mot utdaterte maler lenger enn nødvendig, noe som i sum reduserer effektiv hashrate mot nettverket selv om ASIC-ene kjører for fullt.

Til slutt: hold et øye med utviklingen i vanskelighetsgrad og hashprice, siden lønnsomheten i mining svinger raskere enn protokollvalget ditt. Vi har tidligere dekket hvordan vanskelighetsgraden har beveget seg gjennom 2026, noe som er nyttig kontekst når du vurderer om en overgang til Stratum V2 og eventuelt solo-mining er økonomisk fornuftig for din installasjon akkurat nå. Om du driver mining-virksomhet i Norge, bør du også ha oversikt over det regulatoriske bildet, se vår gjennomgang av status for kryptomining-regulering i Norge.

Komplett prosjekt: docker-compose for et fullt Stratum V2-oppsett

For et mer reproduserbart testmiljø kan du samle alle komponentene i en enkelt docker-compose-fil. Under er et fungerende utgangspunkt du kan bygge videre på, tilpasset for lokal testing med regtest.

version: "3.9"
services:
  bitcoind:
    image: bitcoin/bitcoin:latest
    command: >
      -regtest -daemon=0 -txindex=1
      -rpcuser=stratumtest -rpcpassword=endre_dette_passordet
      -rpcallowip=0.0.0.0/0 -rpcbind=0.0.0.0
    ports:
      - "18443:18443"
    volumes:
      - bitcoin-data:/home/bitcoin/.bitcoin

  jd-server:
    build: ./stratum/roles/jd-server
    depends_on:
      - bitcoind
    volumes:
      - ./stratum/roles/jd-server/jds-config.toml:/app/jds-config.toml
    ports:
      - "34264:34264"

  jd-client:
    build: ./stratum/roles/jd-client
    depends_on:
      - jd-server
      - bitcoind
    volumes:
      - ./stratum/roles/jd-client/jdc-config.toml:/app/jdc-config.toml

  translator:
    build: ./stratum/roles/translator
    depends_on:
      - jd-client
    volumes:
      - ./stratum/roles/translator/proxy-config.toml:/app/proxy-config.toml
    ports:
      - "34255:34255"

volumes:
  bitcoin-data:

Kjør docker compose up --build fra prosjektroten for å starte alle fire komponentene samtidig. Legg til en femte tjeneste for miner-simulatoren om du vil automatisere hele testløpet i én kommando. Tilpass portnumrene i eksempelet til det som faktisk står i dine egne konfigurasjonsfiler, ettersom dette er verdier du selv definerer og som må samsvare på tvers av filene.

Denne containeroppskriften er ment som et startpunkt, ikke et ferdig produksjonsoppsett. Før du kjører noe tilsvarende mot mainnet og ekte inntekter, bør du legge til helsesjekker (healthchecks) på hver tjeneste, begrense hvilke porter som eksponeres utenfor det interne nettverket, og flytte passord og nøkler ut av kommandolinjen og inn i en egen secrets-fil som ikke havner i versjonskontroll. Samme prinsipp gjelder her som ellers i infrastrukturarbeid: det som er godt nok til lokal testing, er sjelden godt nok til en produksjonsrigg som håndterer ekte verdier.

Ofte stilte spørsmål

Må jeg oppgradere fastvaren på ASIC-en min for å bruke Stratum V2?
Nei. Translator Proxy oversetter mellom Stratum V1-maskinvare og Stratum V2-nettverket, så eksisterende Antminer- og Whatsminer-enheter kan kobles til uten fastvareendringer.

Hvilke pooler kan jeg faktisk koble til med Stratum V2 i dag?
Braiins Pool og DEMAND Pool kjører begge V2 i produksjon per august 2026, i tillegg til ckpool og solo ckpool som fikk støtte lagt til i slutten av juli 2026. Store pooler som Foundry, AntPool og F2Pool forbereder fortsatt infrastruktur og kjører i praksis Stratum V1.

Trenger jeg en full Bitcoin-node for å bruke Stratum V2?
Kun om du vil bruke Job Declaration og bygge dine egne blokkmaler. Vil du bare ha sikkerhetsgevinstene fra kryptert kommunikasjon, kan du koble deg til en pool som håndterer malbyggingen selv, uten å drifte egen node.

Er Stratum V2 tregere enn Stratum V1 på grunn av forhandlingen?
Nei, protokollen bruker et binært meldingsformat som i praksis reduserer båndbreddebruken sammenlignet med V1s verbose JSON-meldinger. Forhandlingen skjer i bakgrunnen og påvirker ikke innsendingen av shares i sanntid.

Kan jeg kjøre Stratum V2 og Stratum V1 samtidig på samme rigg?
Ja. Du kan la deler av riggen din kjøre gjennom Translator Proxy mot Stratum V2, mens andre enheter fortsetter direkte mot en pool over Stratum V1, så lenge poolen støtter begge tilkoblingsmåtene.

Hva skjer om Job Declarator Server hos poolen avviser malen min?
Da faller oppsettet vanligvis tilbake til en pool-generert mal, avhengig av hvordan JDC er konfigurert. Sjekk loggene for årsak, vanligvis handler det om ugyldige transaksjoner eller en mal som er for gammel i forhold til nettverkets nåværende høyde.

Er DATUM det samme som Stratum V2?
Nei, men de deler samme mål. DATUM er OCEAN-poolens egen protokoll for desentralisert transaksjonsvalg, mens Stratum V2 er en bredere, separat spesifikasjon med egen referanseimplementasjon (SRI) som flere pooler bygger støtte for.

Er det lovlig å drive Bitcoin-mining i Norge?
Reguleringsbildet har vært i bevegelse. Sjekk alltid gjeldende regelverk før du setter opp driftskraft i større skala, siden krav til strømavtaler og rapportering kan variere mellom kommuner og har endret seg gjennom 2026.

Hvor lang tid tar det å bygge og teste hele SRI-oppsettet fra bunnen?
Regn med en arbeidsdag om du allerede er komfortabel med Linux og Rust-verktøykjeden. Selve kompileringen tar 10-20 minutter, mens konfigurering, testing mot simulator og feilsøking av portoppsett typisk fyller resten av tiden for et førstegangsoppsett.

Må Template Provider-noden være synkronisert med hele blokkjeden for å fungere?
Ja, om du vil bygge maler mot mainnet, siden en delvis synkronisert node ikke har et komplett og oppdatert bilde av mempoolen. Under testing i regtest-modus er dette ikke et problem, ettersom kjeden starter tom og vokser lokalt.