Bitcoin-fundamenten

Hoe Bitcoin-transactiekosten werken

Bitcoin-kosten zijn afhankelijk van de virtuele grootte van de transactie, het tarief en de veranderende vraag naar blokruimte—niet simpelweg van het verzonden bedrag.

Direct antwoord

Bitcoin-kosten zijn afhankelijk van de virtuele grootte van de transactie, het tarief en de veranderende vraag naar blokruimte—niet simpelweg van het verzonden bedrag.

Twee Bitcoin-betalingen kunnen hetzelfde bedrag verzenden en zeer verschillende netwerkkosten betalen. Het verschil zit niet in de waarde die wordt overgedragen. Het zit in de transactie die de wallet moet opbouwen: welke ongebruikte outputs inputs worden, hoeveel nieuwe outputs worden gecreëerd, welke scripttypen erbij betrokken zijn, hoeveel geserialiseerde gegevens de ondertekende transactie bevat, en welk kostentarief de wallet toepast op die virtuele grootte.

Dit is de reden waarom een wallet vóór de muntselectie één kost kan tonen en na het kiezen van de uiteindelijke inputs een andere. Het is ook de reden waarom het verzenden van 0,01 BTC meer kan kosten dan het verzenden van 1 BTC. Bitcoin rekent geen percentage van de betaling aan. Het prijst blokruimte.

De berekening volgt één doorlopend pad:

Inputs and outputs
→ serialized transaction data
→ transaction Weight
→ virtual size in vB
→ fee rate in sat/vB
→ total fee in sats

Als u dat pad begrijpt, kunt u een kostenvoorbeeld van een wallet lezen zonder het betalingsbedrag, het kostentarief en de uiteindelijke kosten te verwarren.

De kosten zijn geen percentage

Een Bitcoin-transactiekost is het verschil tussen de totale waarde van de inputs en de totale waarde die aan de outputs wordt toegewezen:

Transactiekosten
=
Totale inputwaarde
−
Totale outputwaarde

Stel dat een wallet één input uitgeeft ter waarde van 120.000 sats. Het creëert een betalingsoutput van 100.000 sats en een wisseloutput van 18.500 sats. De resterende 1.500 sats zijn de transactiekosten:

120.000 sats
− 100.000 sats
− 18.500 sats
= 1.500 sats kosten

Het netwerk haalt die kosten niet apart van een account af. De kosten zijn de inputwaarde die de transactie niet aan een nieuwe output toewijst.

Een wallet kan verschillende gerelateerde cijfers op hetzelfde scherm tonen. Ze beschrijven verschillende delen van de transactie en mogen niet worden vergeleken zonder hun eenheden.

Weergegeven waarde	Wat het betekent	Voorbeeld
Ontvangen bedrag	Bitcoin toegewezen aan de uitvoer van de beoogde ontvanger	100.000 sats
Totale vergoeding	Invoerwaarde niet toegewezen aan enige uitvoer	1.500 sats
Vergoedingstarief	Prijs toegepast per virtuele byte	10 sat/vB
Virtuele grootte	Weight-transactiegrootte gebruikt voor vergelijking van kosten	150 vB
Totale portemonnee-debet	Ontvangen bedrag plus de vergoeding wanneer de afzender deze apart betaalt	101.500 sats

Het betalingsbedrag en de totale vergoeding worden gemeten in sats of BTC. Het vergoedingstarief wordt gemeten in sat/vB. Virtuele grootte wordt gemeten in vB. Als deze labels onbekend zijn, lees eerst wat een satoshi betekent in portemonnees en vergoedingsweergaven.

Invoer en Uitvoer Bepalen de Grootte

Invoer besteedt bestaande UTXO's

Bitcoin-portefeuilles besteden niet vanuit één accountsaldo. Ze besteden bestaande ongebruikte transactie-outputs, gewoonlijk UTXO's genoemd. Elke geselecteerde UTXO wordt een invoer in de nieuwe transactie.

Een invoer identificeert een eerdere output en levert de gegevens die nodig zijn om aan de bestedingsvoorwaarden van die output te voldoen. Afhankelijk van het scripttype verschijnt sommige autorisatiegegevens in de basis transactieserialisatie en sommige in de witness.

Een weergegeven saldo kan de structuur verbergen die van belang is voor vergoedingen. Een portefeuille die 500.000 sats toont, kan controle hebben over:

één UTXO ter waarde van 500.000 sats;
vijf UTXO's ter waarde van elk 100.000 sats;
of vijftig UTXO's ter waarde van elk 10.000 sats.

Alle drie de portefeuilles tonen hetzelfde totale saldo. Besteding ervan creëert niet dezelfde transactie. Meer geselecteerde UTXO's betekenen over het algemeen meer invoeren, en elke extra invoer brengt een extra outpoint, sequentieveld, script- of witnessgegevens en lengtevoorvoegsel in de geserialiseerde transactie.

Een 50.000-sat-betaling gefinancierd door één geschikte UTXO kan daarom kleiner zijn dan dezelfde betaling gefinancierd door acht kleine UTXOs. Muntselectie verandert ook de privacy en de toekomstige UTXO-set van de wallet. Om de kosten van het nu consolideren van UTXOs te vergelijken met het later afzonderlijk uitgeven ervan, gebruik de Bitcoin UTXO-consolidatiecalculator.

Ontvanger- en wisseloutputs

Een transactie-output bevat een integerwaarde in satoshis en een vergrendelingsscript. De betaling aan de ontvanger is één output. Wisselgeld dat naar de afzender wordt teruggestuurd, is meestal een andere.

Als een wallet een 120.000-sat UTXO selecteert om een 100.000-sat-betaling te doen, kan deze normaal gesproken niet slechts een deel van die UTXO uitgeven. De nieuwe transactie verbruikt de volledige output. Nadat de vergoeding is verrekend, gaat de ongebruikte waarde naar een door de wallet gecontroleerde wisseloutput.

Een typische betaling kan daarom één of meer inputs, een ontvangeroutput, een wisseloutput en vaste velden zoals versie en locktime bevatten. Het bevat ook input- en outputtellingen, en elke input heeft zijn eigen sequentiewaarde.

Het toevoegen van een extra ontvanger voegt een output toe. Het toevoegen van wisselgeld voegt er ook één toe. Elke output vergroot de transactiegrootte, hoewel een gewone single-signature input meestal meer virtuele grootte toevoegt dan een gewone output.

Een portemonnee kan wisselgeld vermijden wanneer de geselecteerde inputwaarde nauw aansluit bij de betaling plus vergoeding. Het kan ook een zeer klein restant aan de vergoeding toevoegen in plaats van een oneconomische wisseloutput te creëren. Die beslissing hangt af van de muntselectie en beleidsregels van de portemonnee, daarom is “één betaling” niet voldoende informatie om een vergoeding te reproduceren.

Bytes, Weight en vSize

Bitcoin-transacties worden geserialiseerd in bytes. De ruwe structuur omvat een versie, inputtelling, inputs, outputtelling, outputs en locktime. SegWit-transacties bevatten ook een marker, flag en witness-velden.

Vóór SegWit verwezen kostenvergelijkingen vaak rechtstreeks naar transactiebytes. BIP 141 introduceerde transactie-Weight zodat witnessgegevens anders konden bijdragen dan niet-witnessgegevens.

BIP 141 definieert Weight als:

Transaction Weight
=
Base transaction size × 3
+
Total transaction size

Dezelfde relatie kan worden geschreven als:

Transaction Weight
=
Non-witness bytes × 4
+
Witness bytes

Een niet-witnessbyte draagt vier gewichtseenheden bij. Een witnessbyte draagt er één bij. De lagere weging maakt witnessgegevens niet gratis; het verbruikt nog steeds blok-Weight en verhoogt nog steeds de voor de vergoeding relevante grootte.

Portemonnees en vergoedingsmarkten drukken het resultaat gewoonlijk uit in virtuele bytes, afgekort vB:

vSize
=
ceil(Transaction Weight ÷ 4)

De deling wordt naar boven afgerond naar een geheel virtueel byte. Basismaat, totale geserialiseerde maat, Weight en vSize zijn gerelateerde metingen, maar ze zijn niet onderling uitwisselbaar. Basismaat sluit getuigenis-gerelateerde gegevens uit. Totale maat omvat de volledige serialisatie. Weight past de vier-op-een-regel toe. vSize zet die Weight om in de gehele maat die wordt gebruikt voor gangbare vergoedingstariefberekeningen.

sat/vB Prijst de Transactie

De gangbare Bitcoin-vergoedingstariefeenheid is satoshis per virtueel byte, geschreven als sat/vB. Zodra de transactiestructuur een vSize heeft opgeleverd, is de vereenvoudigde vergoedingsberekening:

Geschatte vergoeding in sats
=
Transactie vSize
×
Vergoedingstarief in sat/vB

De eenheden vallen netjes weg: virtuele bytes vermenigvuldigd met satoshis per virtuele byte laten een totaal aantal satoshis over.

Het tarief en de totale vergoeding beantwoorden verschillende vragen:

Vergoedingstarief: hoeveel de transactie betaalt voor elke eenheid virtuele grootte.
Totale vergoeding: hoeveel satoshis de volledige transactie betaalt.

Een grote transactie kan een hoge totale vergoeding betalen tegen een gematigd tarief. Een compacte transactie kan een lagere totale vergoeding betalen, zelfs tegen een hoger tarief. Alleen de totale vergoeding vergelijken verbergt het verschil tussen transactiegrootte en de urgentie van de vergoedingsmarkt.

Zodra de definitieve ondertekende transactie bekend is, kan het effectieve vergoedingstarief worden berekend uit de werkelijke vergoeding en werkelijke vSize:

Effectief vergoedingstarief
=
Werkelijke vergoeding in sats
÷
Werkelijke vSize in vB

Het effectieve tarief kan een decimaal bevatten, ook al is de transactievergoeding zelf een geheel aantal satoshis.

Een portemonnee of rekenmachine kan ook een decimaal vergoedingstariefdoel accepteren. De transactievergoeding zelf wordt nog steeds een geheel aantal sats, omdat invoer- en uitvoerwaarden gehele getallen zijn. Wanneer de vermenigvuldiging een fractionele satoshi oplevert, moet de implementatie een hele-satoshi-vergoeding kiezen. Naar boven afronden voorkomt dat het gevraagde doeltarief wordt onderschreden, waardoor het uiteindelijke effectieve tarief iets hoger kan zijn dan de ingevoerde waarde.

Een Reproduceerbare Vergoedingsberekening

Het volgende voorbeeld modelleert een veelvoorkomende ondertekende transactiestructuur:

2 Native SegWit P2WPKH-invoeren;
1 P2WPKH-ontvangeruitvoer;
1 P2WPKH-wisseluitvoer;
CompactSize-tellingen die elk in één byte passen;
72-byte geserialiseerde ECDSA-handtekeningen in de witness;
en een geselecteerd vergoedingstarief van 12 sat/vB.

Dit is een illustratief technisch model, geen gebruikers transactie record of een claim over een specifieke wallet. De uiteindelijke ECDSA handtekeninglengte kan variëren, dus een wallet kan een iets ander maximaal invoer Weight reserveren vóór het ondertekenen.

Van serialisatie tot de uiteindelijke vergoeding

De twee P2WPKH invoeren dragen elk 41 basisbytes bij. De twee P2WPKH uitvoeren dragen elk 31 bytes bij. Vaste velden en één-byte invoer- en uitvoertellingen dragen nog eens 10 basisbytes bij. Elke gemodelleerde invoer draagt 108 witness bytes: één stack-item telbyte, één handtekeninglengtebyte, een 72-byte geserialiseerde handtekening, één openbare-sleutellengtebyte, en een 33-byte gecomprimeerde openbare sleutel.

Component	Basisbytes	Witnessbytes	Weight-bijdrage
Versie, tellingen en locktime	10	0	40 WU
Twee P2WPKH invoeren	82	216	544 WU
Twee P2WPKH outputs	62	0	248 WU
SegWit marker en vlag	0	2	2 WU
Totaal	154	218	834 WU

Weight
= (154 base bytes × 4) + 218 witness bytes
= 834 WU

vSize
= ceil(834 ÷ 4)
= 209 vB

Fee
= 209 vB × 12 sat/vB
= 2,508 sats

Elke aanname is zichtbaar. Wijzig het aantal inputs, het aantal outputs, het scripttype, de witnessgrootte of het tarief, en het resultaat verandert. Om gemengde input- en outputtypen te modelleren, open je de Bitcoin-transactiekostencalculator, voer de structuur in zoals weergegeven door de wallet, en vergelijk de schatting met de definitieve transactievoorbeeld.

Zelfde betaling, ander bedrag

Overweeg twee wallets die elk dezelfde 100.000-sat-betaling sturen, één P2WPKH-wisseloutput creëren en een vergoedingentarief van 12 sat/vB gebruiken. Het enige verschil is het aantal P2WPKH-inputs.

Met hetzelfde model van 72-byte-handtekeningen als in het uitgewerkte voorbeeld:

Gemodelleerde transactie	Invoer	Uitvoer	Weight	vSize	Kosten bij 12 sat/vB
Portemonnee A	1 P2WPKH	2 P2WPKH	562 WU	141 vB	1.692 sats
Portemonnee B	8 P2WPKH	2 P2WPKH	2.466 WU	617 vB	7.404 sats

De ontvanger ontvangt hetzelfde bedrag. Het tarief is hetzelfde. Wallet B betaalt meer omdat het meer inputs verbruikt en een grotere transactie creëert.

Het bedrag kan ongewijzigd blijven. De transactiestructuur niet.

Een tariefschatting die de werkelijke UTXO's van de wallet niet kent, is daarom een scenario, niet de definitieve transactie. De wallet moet echte inputs selecteren voordat het de waarschijnlijke omvang en het tarief kan bepalen.

Inputtype verandert de kosten

Het aantal inputs is niet de enige structurele variabele. De bestedingsvoorwaarden van de geselecteerde outputs bepalen wat elke input moet serialiseren.

Veelvoorkomende enkelvoudige handtekeningprofielen zijn Legacy P2PKH, geneste SegWit P2SH-P2WPKH, Native SegWit P2WPKH en Taproot key-path P2TR. Ze voegen niet hetzelfde Weight toe.

Veelvoorkomend inputprofiel	Waar autorisatiegegevens verschijnen	Illustratieve marginale grootte	Belangrijke grens
P2PKH	Basis transactie scriptSig	Ongeveer 148 vB	ECDSA-handtekeninglengte kan variëren
P2SH-P2WPKH	Inwisselprogramma in scriptSig plus witness	Ongeveer 91 vB	Genest SegWit omvat wrappergegevens
P2WPKH	Witness	Ongeveer 68 vB	ECDSA-handtekeninglengte kan variëren
P2TR-sleutelpad	Enkele Schnorr-handtekening in witness	Ongeveer 58 vB	Een niet-standaard sighash-byte voegt één byte toe

Deze cijfers beschrijven gangbare single-signature-uitgavenpaden, niet elke mogelijke transactie. Multisig, P2WSH, Taproot-scriptpaden, inscripties, complexe scripts en niet-standaard constructies kunnen zeer verschillende witnessgegevens bevatten.

Outputtype doet er ook toe, hoewel een ontvangstadres in elk geval niet de exacte toekomstige inputkosten onthult. Voor een gerichte vergelijking van adrescoderingen, compatibiliteit en gangbare scriptfamilies, lees Bitcoin-adrestypen en hun implicaties voor wallets.

Waarom walletschattingen veranderen

Een walletschatting van de vergoeding kan veranderen tussen het betalingsformulier en het ondertekeningsscherm, zelfs wanneer het ontvangen bedrag hetzelfde blijft. Verschillende beslissingen bij het bouwen van de transactie kunnen nog onopgelost zijn wanneer de eerste schatting verschijnt.

Muntselectie en wissel zijn voorlopig

De wallet kan aanvankelijk één inputtelling modelleren en vervolgens een andere set selecteren na overweging van bevestigingsstatus, muntcontrole-instellingen, privacyregels, het vermijden van wissel of de noodzaak om de vergoeding te dekken. Zodra de inputs bekend zijn, kan het een wisseloutput toevoegen, verwijderen of het type ervan wijzigen.

Bitcoin Core's fundrawtransaction documentatie weerspiegelt deze keuzes: een wallet kan inputs toevoegen, maximaal één wisseloutput creëren, een wisseltype selecteren, een vergoedingentarief in sat/vB gebruiken of de vergoeding aftrekken van gespecificeerde outputs. Het toevoegen van een input verhoogt Weight. Het toevoegen van wissel vergroot de outputgrootte. Het aftrekken van de vergoeding verandert het ontvangen bedrag. Het vermijden van een kleine wisseloutput kan het restant naar de vergoeding verplaatsen.

Handtekeningen en vergoedingstarieven worden geschat

ECDSA-handtekeningen hebben niet gegarandeerd identieke geserialiseerde lengtes. Bitcoin Core's documentatie over transactiefinanciering adviseert om de maximale geserialiseerde DER-handtekeninggrootte te gebruiken wanneer een externe input-Weight-schatting wordt verstrekt. Een wallet kan daarom een veilig maximum reserveren voordat de werkelijke handtekeningen bestaan.

Het tarief kan ook vernieuwen vóór het ondertekenen. Als de wallet een nieuwere schatting ontvangt of de gebruiker het bevestigingsdoel wijzigt, verandert het geselecteerde sat/vB-tarief, zelfs als de transactiestructuur niet verandert.

Dit zijn geen willekeurige verschillen. Een gewijzigd tarief moet overeenkomen met een gewijzigde invoerset, uitvoerstructuur, aanname over handtekeninggrootte, schatting van het tarief, of een combinatie daarvan.

Netwerkvraag bepaalt het tarief

De transactiestructuur bepaalt vSize. Netwerkomstandigheden beïnvloeden het tarief dat een wallet kiest voor een bevestigingsdoel.

Bitcoin-blokruimte is beperkt. Onbevestigde transacties concurreren om opname, en het tarief is een van de belangrijkste signalen om te vergelijken hoeveel elke transactie betaalt ten opzichte van de virtuele grootte. Een wallet kan een hoger tarief selecteren voor een agressiever doel of een lager tarief wanneer de gebruiker meer vertraging accepteert.

Bitcoin Core's estimatesmartfee RPC retourneert een geschat tarief voor een transactie om binnen een gevraagd aantal blokken te beginnen met bevestiging wanneer voldoende gegevens beschikbaar zijn. Het gebruikt de virtuele transactiegrootte en biedt twee schattingsmodi:

Economisch reageert sneller op kortetermijndalingen van het tarief en kan een lagere schatting retourneren.
Conservatief gebruikt een langere geschiedenis, reageert langzamer op kortetermijndalingen en kan een hogere schatting retourneren.

Geen van beide modi reserveert blokruimte. De schatting is gebaseerd op waargenomen gedrag, niet op een belofte dat een miner de transactie in een bepaald blok zal opnemen.

Wallets, explorers en diensten kunnen verschillende tijdvensters, mempool-weergaven, veiligheidsmarges en doellabels gebruiken. Twee interfaces kunnen daarom op hetzelfde moment verschillende tarieven aanbevelen zonder verschillende Bitcoin-consensusregels toe te passen.

Er is geen enkele wereldwijde mempool-wachtrij die elke node in exact dezelfde volgorde ziet. Nodes ontvangen transacties op verschillende tijdstippen en passen hun eigen beleidsinstellingen toe. Een wallet-schatting beschrijft de gegevens die beschikbaar zijn voor de tariefbron; een miner selecteert uiteindelijk uit de transacties en het beleid dat beschikbaar is voor die mijnbouwoperatie.

De definitieve ondertekende transactie

Voordat wordt ondertekend, schat een wallet de autorisatiegegevens die nodig zijn voor elke invoer. Na het ondertekenen bevat de transactie de werkelijke handtekeningen en getuigenis-stacks. De uiteindelijke serialisatie onthult de echte Weight, vSize, totale vergoeding en effectief vergoedingstarief.

Het ondertekeningsscherm moet daarom als meer gezaghebbend worden beschouwd dan een vroege schatting bij het invoeren van het bedrag. Het kan onthullen dat de wallet meer inputs heeft geselecteerd dan verwacht, wisselgeld heeft toegevoegd, een ander outputtype heeft gebruikt, een andere handtekeninggrootte heeft geproduceerd, of het vergoedingstarief heeft ververst vóór autorisatie.

De betalingsgegevens kunnen correct zijn terwijl de transactiestructuur nog een extra controle verdient. Controleer beide vóór het uitzenden.

Tariefwijzigingen na uitzending

Het uitzenden verzendt de transactie naar peers. Het garandeert niet dat elke node deze accepteert en bewaart of dat deze in het volgende blok verschijnt. Nieuwe transacties kunnen na de uwe de tariefmarkt betreden, waardoor het oorspronkelijke tarief minder concurrerend wordt.

Sommige wallets kunnen een vervanging met een hogere vergoeding creëren wanneer een onbevestigde transactie in aanmerking komt voor fee bumping. De workflow van Bitcoin Core's bumpfee kan wisselgeld verminderen of invoeren toevoegen wanneer nodig, wat betekent dat de grootte en de totale vergoeding van de vervangende transactie beide kunnen verschillen van het origineel.

Lees de definitieve wallet-preview

Controleer vóór het ondertekenen de cijfers die de vergoeding bepalen in plaats van te vertrouwen op een enkele regel “netwerkvergoeding”.

Ontvangerbedrag: Bevestig het bedrag dat aan de beoogde ontvanger is toegewezen en of de vergoeding van die uitvoer wordt afgetrokken.
Geselecteerde invoeren: Een groter dan verwacht aantal invoeren verklaart veel vergoedingsstijgingen.
Uitvoeren en wisselgeld: Bevestig de uitvoeren van de ontvanger, de wisselgeld-uitvoer en de bestemming van het wisselgeld.
Virtuele grootte: Controleer het vB-cijfer wanneer de wallet dit blootlegt.
Vergoedingstarief: Onderscheid een tarief in sat/vB van de absolute vergoeding in sats.
Totale vergoeding: Bevestig het totale aantal satoshis dat de volledige transactie betaalt.
Bevestigingsdoel: Behandel het als een schatting en noteer of de wallet later de vergoeding kan verhogen.

De meest nuttige kruiscontrole is rekenkundig:

Komt de weergegeven vSize × weergegeven sat/vB
ongeveer overeen met de weergegeven vergoeding in sats?

Een klein verschil kan komen van een decimaal tarief, afronding op hele satoshis of afgeronde weergavewaarden. Een groot onverklaard verschil verdient een extra controle vóór het ondertekenen.

Voor bredere context over UTXOs, bevestigingen, miners en validatie, ga verder naar de Bitcoin-netwerk- en transactiereferentie.

Wat de schatting niet kan garanderen

Een volledige kostenraming kan de transactie en het geselecteerde tarief beschrijven. Het kan niet garanderen:

bevestiging in het volgende blok of op een exact tijdstip;
acceptatie en voortdurende retentie door elk knooppunt;
ongewijzigde netwerkvraag nadat de transactie is ondertekend;
of dat de wallet de meest private en economische inputs heeft gekozen of nooit een fee-verhoging nodig zal hebben.

De reproduceerbare vraag is smaller: gegeven deze transactiestructuur en dit feestarief, hoeveel satoshis betaalt de transactie? Bevestigingstijd blijft probabilistisch.

Bitcoin Transactiefee FAQ

Zijn Bitcoin transactiefees gebaseerd op het verzonden bedrag?

Nee. Bitcoin transactiefees zijn voornamelijk gebaseerd op de virtuele grootte van de transactie en het geselecteerde feestarief. Het verzonden bedrag kan beïnvloeden welke UTXOs een wallet nodig heeft, maar een grotere betaling creëert niet automatisch een hogere fee.

Wat betekent sat/vB?

Sat/vB betekent satoshis per virtuele byte. Het is een feestarief dat wordt toegepast op de virtuele grootte van een transactie. Het vermenigvuldigen van vSize met het feestarief geeft een gemodelleerde totale fee in satoshis.

Waarom veranderde mijn Bitcoin walletfee voordat ik ondertekende?

De wallet kan verschillende inputs selecteren, wisselgeld toevoegen of verwijderen, het wisselgeldtype bijwerken, een andere handtekeninggrootte reserveren of het feestarief verversen. Elk van deze wijzigingen kan de uiteindelijke fee veranderen.

Waarom kunnen twee wallets verschillende fees in rekening brengen voor dezelfde betaling?

De wallets kunnen verschillende UTXOs beheren, verschillende inputs kiezen, verschillende wisselgeldoutputs creëren, verschillende feestarieven gebruiken of verschillende veiligheidsmarges toepassen. Het ontvangen bedrag kan hetzelfde zijn terwijl de transactiestructuren verschillen.

Garandeert een hogere Bitcoin fee snellere bevestiging?

Nee. Een hoger feestarief kan de relatieve prioriteit van een transactie verbeteren, maar het kan geen specifiek blok garanderen. Toekomstige vraag, miner-selectie, mempool-beleid en blokontdekking blijven buiten de controle van de wallet.

Kan een Bitcoin fee worden verhoogd na uitzending?

Sommige wallets kunnen een vervanging met hogere fee creëren wanneer de oorspronkelijke transactie in aanmerking komt voor fee-verhoging. De vervanging kan wisselgeld verminderen of inputs toevoegen, dus de transactiegrootte en totale fee kunnen beide veranderen.

Technische bronnen

De formules en transactiebouwgrenzen in deze gids zijn gebaseerd op primaire Bitcoin-specificaties en Bitcoin Core-documentatie.

BIP 141: Segregated Witness — definieert transactie Weight, basisgrootte, totale grootte en virtuele transactiegrootte.
Bitcoin Ontwikkelaar Transactie Referentie — documenteert geserialiseerde inputs en outputs en legt uit dat outputwaarden worden vastgelegd in satoshis.
Bitcoin Core 31.0 estimatesmartfee RPC — documenteert schatting van feestarieven op basis van bevestigingsdoel, gebruik van virtuele grootte en economische en conservatieve modi.
Bitcoin Core 31.0 fundrawtransaction RPC — documenteert automatische inputselectie, creatie van wisselgeld, feestarieven, fee-aftrek en aannames over input-Weight.
Bitcoin Core 31.0 bumpfee RPC — documenteert wallet-fee-vervanging en hoe een transactie met hogere fee wisselgeld kan verminderen of inputs kan toevoegen.
BIP 341: Taproot — definieert Taproot key-path-handtekeningen en witness-gedrag dat wordt gebruikt in het gangbare P2TR inputgrootte-model.

Bronnen

Een fout gevonden? Meld een inhoudsprobleem of lees onze Correctiebeleid.