Du kender sikkert følelsen: Du sender en Bitcoin-betaling, men minuten bliver til timer, og blok efter blok glider forbi uden et eneste “ding” i din wallet. Netværket er proppet, gebyrerne stikker af – og din transaktion hænger fast i limbo.
I de situationer kan Replace-by-Fee (RBF) være redningsplanken, der hiver din betaling op af mempool-dyndet og skubber den forrest i køen. Med et enkelt klik – eller et par linjer i en avanceret wallet – kan du “overbyde” dig selv og sende en ny version af transaktionen med højere gebyr. Lyder det næsten for godt til at være sandt? Det er det ikke, men der er både regler, risici og smarte tricks at kende.
I denne artikel går vi i dybden med spørgsmålet: “Hvad er RBF i Bitcoin, og hvornår bør du bruge det?” Vi starter med den grundlæggende idé, dykker ned i de tekniske detaljer, gennemgår de mest almindelige anvendelser – og slutter af med konkrete trin-for-trin-instruktioner, så du selv kan tage kontrollen over dine gebyrer.
Læn dig tilbage, fyr op for din foretrukne Bitcoin-wallet, og læs med, når vi afslører, hvordan du gør ventetid til fortid med RBF.
Hvad er RBF i Bitcoin?
Når du sender en Bitcoin-transaktion, ender den først i netværkets mempool, hvor den venter på at blive samlet op af en miner og lagt i en blok. Her konkurrerer den med tusindvis af andre transaktioner om den begrænsede plads i næste blok, og konkurrencen afgøres hovedsageligt af gebyrsatsen (satoshis pr. vbyte). Er gebyret sat for lavt, kan transaktionen “sidde fast” i timer eller dage, hvis netværket pludselig bliver belastet.
Replace-by-Fee (RBF) er en funktion, der løser netop dette problem ved at give afsenderen mulighed for at erstatte en endnu ikke bekræftet transaktion med en ny version, der har et højere gebyr. Minere vil naturligt prioritere den dyrere transaktion, og chancen for hurtig inkludering stiger markant.
Hvorfor eksisterer rbf?
- Dynamisk gebyrjustering: Bitcoin-feemarkedet kan ændre sig hurtigt. RBF lader afsenderen reagere, hvis gebyret pludselig er for lavt.
- Tidskritiske betalinger: For handlende eller brugere, der har brug for en bekræftelse inden for et bestemt tidsvindue, er RBF ofte den hurtigste løsning.
- Netværksfleksibilitet: Ved at tillade erstatninger øges den samlede effektivitet; minere kan fylde blokke med transaktioner, der samlet set betaler højere gebyrer.
Sådan hjælper rbf dig
- Du sender en transaktion med RBF-markeret input (opt-in).
- Hvis transaktionen ikke bekræftes hurtigt nok, laver du en ny transaktion med samme inputs, men højere gebyr.
- Netværkets noder erstatter den gamle version i mempoolen, fordi den nye betaler mere.
- Minere inkluderer den dyrere transaktion i næste blok, og dine mønter når frem hurtigere.
Hvad kan rbf ikke?
| Myte | Virkelighed |
|---|---|
| “Med RBF kan jeg ændre en allerede bekræftet transaktion.” | Nej. Når en transaktion er inkluderet i en blok, er den final; RBF virker kun på transaktioner i mempoolen. |
| “Jeg kan ændre modtageren efter første bekræftelse.” | Heller ikke muligt. RBF kan kun anvendes, før transaktionen er kommet i en blok. |
| “RBF kan tvinge alle wallets til at acceptere erstatningen.” | Kun noder og wallets, der følger BIP125 eller en mere permissiv RBF-politik, vil acceptere erstatningen. Nogle services fravælger bevidst RBF. |
Sammenfattet er RBF et nyttigt redskab, når du vil sikre hurtigere bekræftelse af en transaktion, der ellers låser sig fast på grund af et for lavt gebyr. Det er ikke en måde at omgøre eller ændre historikken på Bitcoin-blockchainen – kun en mekanisme til at finjustere transaktioner, før de bliver permanente.
Sådan fungerer RBF teknisk
I Bitcoin-netværket konkurrerer transaktioner om pladsen i den næste blok ud fra hvor meget gebyr pr. vbyte de betaler. RBF gør det muligt for afsenderen at gensende en endnu ikke bekræftet transaktion med et højere gebyr, så miners har større incitament til at inkludere den hurtigt. Selve “erstatningen” sker før transaktionen er kommet på blockchainen – allerede bekræftede transaktioner kan altså ikke ændres med RBF.
Opt-in rbf via nsequence (bip-125)
RBF er defineret i BIP-125. Funktionen er opt-in: Afsenderen signalerer, at netværket må acceptere en fremtidig erstatning, ved at sætte nSequence-feltet i alle input til en værdi mindre end 0xffffffff - 1 (normalt bare 0 eller 1).
| nSequence-værdi | Signal |
|---|---|
| < 0xffffffff – 1 | Transaktionen er RBF-kompatibel (opt-in) |
| = 0xffffffff – 1 | Transaktionen er låst og kan ikke erstattes |
Regler for en gyldig erstatning i mempoolen
Når en node modtager en mulig erstatning, tjekker den fem hovedkrav fra BIP-125:
- Højere samlet gebyr – den nye transaktion (plus eventuelle afhængige child-transaktioner) skal betale mindst det totale gebyr den erstatter plus et minimalt relaygebyr.
- Højere fee-rate – gebyr pr. vbyte skal være højere end for den/de transaktioner der ligger i konflikt.
- Maks. 100 konflikter – en erstatning må ikke røre ved mere end 100 eksisterende transaktioner i mempoolen.
- Ingen ekstra sigter på samme UTXO-sæt – den nye transaktion må ikke introdusere yderligere konflikter udover dem, den allerede erstatter.
- Alle inputs signeret af afsenderen – selvsagt skal den nye transaktion være gyldigt signeret.
Overholder erstatningen alle kravene, smides de gamle versioner ud af mempoolen, og kun den nyeste – med det højere gebyr – videresendes til andre noder og miners.
Opt-in rbf vs. Fuld rbf-policy
I dag er de fleste Bitcoin-noder sat op med opt-in RBF, dvs. de erstatter kun transaktioner, der selv har signaleret RBF. Siden efteråret 2022 har der dog været diskuteret (og eksperimenteret med) en “full RBF”-policy, hvor noder accepterer enhver transaktion med højere gebyr, uanset nSequence-flaget. Argumenter for fuld RBF er bl.a.:
- Ensartet politik, der reducerer kompleksitet i mempool-koden.
- Bedre markedseffektivitet: transaktioner med højere gebyr slår altid lavere gebyr.
Kritikere påpeger øget zero-conf-risiko for handlende, der stoler på ubekræftede transaktioner. Indtil videre kører mainnet-release af Bitcoin Core stadig med opt-in som standard, mens enkelte miners og services eksperimenterer med fuld RBF.
Hvordan noder håndterer erstatninger
Når en node ser en erstatning, gør den følgende:
- Checker BIP-125-reglerne.
- Fjerner de gamle transaktioner + deres children fra mempoolen.
- Lægger den nye transaktion (og dens eventuelle nye children) i mempoolen.
- Videresender kun den nye til sine peers.
Vigtige detaljer:
- Noder kan have forskellige
mempoolminfee, så en erstatning der accepteres ét sted, bliver måske afvist et andet. - Hvis en node mangler et child i kæden af konflikter, kan den afvise erstatningen. Derfor sender de fleste wallets hele “gruppen” samlet.
Wallet-implementeringer
En moderne wallet giver dig typisk to valgmuligheder:
- Sæt RBF-flaget ved afsendelse (“Enable fee bump” i Bitcoin Core, “RBF” i f.eks. Sparrow). Så kan du senere trykke “Increase fee” hvis transaktionen sidder fast.
- Udskift manuelt: Konstruer en helt ny transaktion med samme inputs, højere gebyr og udvalgte outputs. Wallet’en signer og broadcaster den for dig.
Enkelte wallets (typisk mobile) understøtter stadig ikke RBF, mens andre kører med fuld RBF (fx Electrum i “advanced mode”). Sørg for, at modtagerens wallet også kan håndtere RBF, hvis de ønsker at blive notificeret om erstatningen.
Opsummering
RBF er i bund og grund et sæt mempool-regler, der tillader en afsender at “overbyde sig selv” gennem et højere gebyr. Teknikken bygger på nSequence (opt-in) og BIP-125’s fem krav. Forskellen mellem opt-in og fuld RBF ligger i, om transaktioner skal signalere RBF eller ej. Praktisk set betyder det, at du – med den rette wallet – kan redde en fastlåst transaktion på få sekunder ved simpelthen at betale lidt mere.
Hvornår bør du bruge RBF?
Selvom Replace-by-Fee i praksis blot er et værktøj til at hæve gebyret på en allerede udsendt transaktion, gør fleksibiliteten i RBF, at den kan løse flere forskellige problemer. Nedenfor finder du de mest almindelige situationer, hvor funktionen giver mening – sammen med en kort sammenligning med det klassiske alternativ Child-Pays-For-Parent (CPFP).
1. Når din transaktion “sidder fast” på grund af for lavt gebyr
- Du har sendt en betaling, men valgte et gebyr baseret på den daværende netværksbelastning.
- Siden da er mempoolen blevet fyldt, og miners vælger transaktioner med højere fee-rate.
- Hvis transaktionen er markeret som opt-in RBF, kan du blot sende en erstatning med højere gebyr. Den gamle transaktion kastes ud af mempoolen på de fleste noder, og den nye har større sandsynlighed for at komme med i næste blok.
2. Ved tidskritiske betalinger
Skal du lukke en arbitragemulighed, betale en børsoverførsel inden en tidsfrist eller sende midler, der skal være bekræftet før en bestemt deadlines, kan RBF fungere som en forsikringsmekanisme:
- Send transaktionen med et moderat gebyr.
- Hold løbende øje med mempoolen.
- Hvis blokintervallet trækker ud, eller gebyrerne stiger, “bumper” du gebyret, så betalingen glider forrest i køen.
3. Ved pludselige spikes i netværksbelastning
Bitcoin-netværket kan opleve kortvarige perioder, hvor gebyrerne mangedobles (fx efter store NFT-drops eller ordinals). Har du udsendt en transaktion kort tid før et sådan spike, risikerer den at blive overset i flere timer eller helt droppet, hvis mempoolen når den konfigurerede max-størrelse på enkelte noder.
I stedet for blot at vente, kan du:
- Beregne den nuværende anbefalede fee-rate (se fx mempool.space).
- Erstatte den gamle transaktion via RBF med en gebyrsat rate, der matcher eller overgår det nye niveau.
4. “annullering” af en uafklaret betaling
Så længe en transaktion ikke er bekræftet, kan du i princippet erstatte hele den oprindelige betaling med en transaktion, der sender midlerne tilbage til dig selv (eller til en tredje part). Scenariet bruges typisk:
- Når du har indtastet en forkert adresse eller beløb og opdager det med det samme.
- Hvis en modtager ikke leverer den aftalte vare/tjeneste inden for den tid, I havde aftalt at transaktionen skulle bekræftes.
Vær dog opmærksom på, at modtageren kan have beskyttet sig mod sådanne forsøg ved at vente på et vist antal bekræftelser, før varen leveres. RBF er derfor ikke et juridisk værktøj til at trække en betaling tilbage – blot en teknisk mulighed så længe transaktionen er zero-conf.
Sammenligning med cpfp
| RBF (Replace-by-Fee) | CPFP (Child-Pays-For-Parent) | |
|---|---|---|
| Initiativtager | Afsenderen af den originale transaktion | Typisk modtageren (eller en tredjepart) af en udgående UTXO |
| Kræver opt-in? | Ja, nSequence < 0xfffffffe (BIP125) | Nej, fungerer på alle ikke-spendede UTXO’er |
| Gebyrstigning | Den nye transaktion erstatter og betaler hele gebyret | Barnetransaktionen betaler “manglende” gebyr – samlet pakke skal overstige mindstekrav |
| Mulighed for at ændre outputs | Ja, du kan ændre adresser og beløb | Nej, original transaktion forbliver uændret |
| Annulleringseffekt | Mulig (erstat med transaktion til dig selv) | Ikke mulig |
Hvornår vælger man hvad?
- Du er afsender og vil have kontrol ➜ Brug RBF.
- Du er modtager og afsenderen støtter ikke RBF ➜ Overvej CPFP.
- Begge parter har travlt ➜ En kombination (RBF fra afsender + CPFP fra modtager) kan give maksimal lovende fee-rate.
Praktisk tommelfingerregel
Hvis du har mulighed for at aktivere RBF, så gør det som standard – du giver dig selv en “fortrydelses- og turbo-knap”, hvis netværket opfører sig uforudsigeligt. Og husk: Efter én bekræftelse kan hverken RBF eller CPFP ændre den oprindelige transak tion; herefter er det kun dig virksomhedens revisor og Block Explorers, der kan følge sporet.
Risici, faldgruber og bedste praksis
Der er gode grunde til at have Replace-by-Fee som værktøj i værktøjskassen, men funktionen kræver omtanke fra både afsender og modtager. Nedenfor gennemgår vi de vigtigste risici og bedste praksisser, så du kan anvende RBF uden ubehagelige overraskelser.
Zero-conf og risikoen for dobbeltforbrug
- Ingen garanteret endelighed før første blok: Når en transaktion er markeret som RBF-mulig, kan den erstattes helt frem til den bliver inkluderet i en blok. Modtager du en zero-confirmation betaling, kan afsenderen derfor i princippet omdirigere midlerne til en ny adresse eller blot hæve gebyret.
- Dobbeltforbrug er lettere: En angriber kan sende en lav-gebyr-betaling til en butik, få varen udleveret, og umiddelbart efter udsende en erstatningstransaktion til egen adresse med højere gebyr. Hvis butikken ikke venter på mindst én bekræftelse, risikerer den tab.
- “Opt-in” vs. “full” RBF: De fleste noder accepterer kun erstatninger hvis originalen var markeret som RBF (opt-in). Kører du selv node, kan du dog vælge en “full RBF”-policy, der tillader erstatning af alle uafklarede transaktioner – endnu en grund til at være forsigtig med zero-conf.
Privatlivsfaldgruber
- Flere versioner, mere metadata: Hver erstatning offentliggør nye transaktions-id’er (txid). Analysefirmaer kan korrelere disse og få stærkere indblik i din coin-kontrol.
- Timing-angreb: Hvis du gentagne gange bumper gebyret i trin, kan observatører udlede din hastighedspræference og eventuelt koble det til tidspunkter eller geografiske oplysninger.
- Brug coin control: Overvej at sende eventuelle ændringsoutputs til nye, ikke-linkede adresser for at begrænse sporbarhed.
Forskelle i wallet- og node-politikker
| Wallet | Standardindstilling | Kan ændres? | Særlige bemærkninger |
|---|---|---|---|
| Electrum | RBF on | Ja | Mulighed for “Cancel transaction” ved erstatning til dig selv |
| Bitcoin Core | RBF off | Ja (-walletrbf) | Vises som “(bumpable)” i transaktionslisten |
| Ledger Live | RBF on | Delvist | Barebones interface – ingen manuel fee-kontrol |
| Mycelium | RBF on | Nej | Kan ikke slås fra, så modtager bør vente på bekræftelse |
Selv om en afsender-wallet tillader RBF, er det op til netværket af noder, om de accepterer erstatningen. Kører du egen node, kan du vælge politik, men som udgangspunkt følger de fleste noder BIP125-reglerne.
Bedste praksis for afsendere
- Planlæg gebyret fra starten: Brug mempool-data og fee-estimater; så undgår du overhovedet at skulle erstatte.
- Sæt altid
nSequence < 0xfffffffe, hvis du forventer at kunne rette gebyret senere. - Bump tidligt, ikke sent: Jo hurtigere du reagerer på netværksbelastning, desto færre versioner havner i mempoolen, og desto mindre privacy-støj skaber du.
- Hold øje med mempoolen: Brug værktøjer som mempool.space eller Johoe’s Bitcoin Mempool til at følge status.
Bedste praksis for modtagere
- Anerkend zero-conf-risiko: Skal varen forlade butikken med det samme, kræv enten en transaktion uden RBF-flag eller vent på mindst én bekræftelse.
- Tjek
nSequence-feltet: Er mindre end0xfffffffe, er transaktionen RBF-mulig. - Overvåg mempoolen aktivt: Brug en betroet node eller egen node til at fange erstatninger i realtid.
- Tilpas bekræftelseskrav efter beløb:
| Beløb (DKK-værdi) | Minimum bekræftelser | Zero-conf acceptabel? |
|---|---|---|
| < 100 kr. | 0-1 | Kun hvis ikke RBF-flag |
| 100 – 5.000 kr. | 1-3 | Som hovedregel nej |
| > 5.000 kr. | > 3 | Aldrig |
Ved store transaktioner (on-chain obligationer, fast ejendom, OTC-handler) bør du vente på 6+ bekræftelser uanset RBF.
Opsummering
For afsenderen er RBF en fleksibel måde at sikre hurtig bekræftelse til en fair pris. For modtageren øger samme fleksibilitet risikoen for tab, hvis man godkender uafklarede transaktioner. Kender du forskellene i wallet-politik, forstår mempool-signalerne og har klare krav til bekræftelser, kan RBF bruges sikkert og effektivt.
Trin-for-trin: Sådan bruger du RBF i praksis
Replace-by-Fee lyder teknisk, men i praksis kræver det kun få klik – forudsat at du bruger den rette wallet og forstår de enkelte trin. Guiden nedenfor tager dig hele vejen fra valg af software til opfølgning på blockchainen.
- Vælg en wallet der understøtter RBF
De fleste moderne Bitcoin-punge har nu indbygget RBF, men det skal som regel slås til manuelt.
Wallet Desktop Mobile RBF-opsætning Electrum ✔ ✖ ‘Replace by fee’ afkrydsningsfelt under Tools → Preferences → Transactions Sparrow ✔ ✖ Standard aktiveret for nye transaktioner BlueWallet ✖ ✔ Aktiver “Enable RBF” i wallet-indstillinger Samourai ✖ ✔ Tryk “Opt-in RBF” før afsendelse Tip: Hardware-punge som Trezor eller Ledger kan også sende RBF-transaktioner, hvis du bruger dem via en desktop-wallet (fx Electrum eller Sparrow).
- Sæt RBF-flaget ved første afsendelse
Ved oprettelse af transaktionen skal du markere feltet “Allow fee bump” eller tilsvarende. Uden dette flag kan transaktionen ikke erstattes senere. - Bump gebyret, når/hvis transaktionen sidder fast
- Automatisk fee-bump: Nogle wallets viser en “Increase fee”-knap ved transaktioner der endnu ikke er bekræftet.
- Manuel erstatning: Du kan lave en ny transaktion med samme inputs men højere fee-rate og – hvis du ønsker det – ændrede outputs (fx sende tilbage til dig selv for reelt at annullere betalingen).
- Vælg en passende fee-rate
30-50 sat/vB Normal netværksbelastning, forvent 1-2 blokke 10-30 sat/vB Lav belastning, 3-6 blokke > 60 sat/vB Spidsbelastning eller tidskritisk betaling Se aktuelle priser på mempool.space eller Jochen’s Mempool Stats.
- Broadcast og overvåg status
Når erstatningen er sendt, bør din wallet vise den som “Unconfirmed (replaced)” eller lignende. Følg dens TX-id på en block explorer med RBF-markering, fx:- mempool.space (viser “Replaced Transaction” banner)
- Blockstream.info
Når første confirmation lander, kan transaktionen ikke længere erstattes.
- Hvis RBF ikke er muligt: brug Child-Pays-For-Parent (CPFP)
Har du sendt uden RBF-flag, kan du stadig få transaktionen ind i en blok ved at:- Lave en ny transaktion (child) der forbruger et output fra den fastlåste (parent).
- Sætte et højt gebyr på barnet, så minearbejdere vælger begge.
Nogle wallets (fx Electrum, Phoenix) har en “CPFP”-funktion direkte i UI’et.
Opsummering: Aktivér RBF, send – og stol på, at du til enhver tid kan hæve gebyret, indtil første blok rammer. Det giver fleksibilitet, sparede nerver og lavere omkostninger over tid.
