Una transazione Bitcoin non confermata non si “sblocca” pagando una seconda commissione a caso. Occorre capire chi controlla gli input o gli output, quale policy applicano i nodi e quale feerate serve ai miner. RBF e CPFP Bitcoin sono i due strumenti principali: Replace-by-Fee sostituisce la transazione, mentre Child Pays for Parent aggiunge una transazione figlia abbastanza remunerativa da rendere interessante l’intero pacchetto. Nessuno dei due garantisce il prossimo blocco e nessuno modifica una transazione già confermata.
Questa guida parte da un presupposto pratico: la transazione è valida, ancora nel mempool e bloccata per una fee troppo bassa. Prima di intervenire, controlla txid, stato, fee totale, virtual size e feerate con il wallet, il tuo nodo o un explorer indipendente. La nostra guida alle fee Bitcoin spiega perché contano sat/vB e spazio occupato, non il valore trasferito.
RBF e CPFP Bitcoin: differenza in una frase
Con RBF il mittente crea una nuova transazione che spende almeno uno degli stessi input della precedente, paga una fee adeguatamente superiore e quindi entra in conflitto con l’originale. Se i nodi accettano il replacement, rimuovono dal proprio mempool la vecchia transazione e propagano la nuova. La txid cambia; anche output e resto possono cambiare. Non si “aggiungono satoshi” alla vecchia tx.
Con CPFP, invece, chi controlla un output non confermato lo spende in una nuova transazione con fee elevata. Un miner deve confermare prima il parent per poter includere il child: valuta perciò il ricavo combinato. Il parent resta identico e conserva la txid. CPFP è utile quando il destinatario controlla già l’output ricevuto oppure quando il mittente può spendere il proprio output di resto.
| Domanda | RBF | CPFP |
|---|---|---|
| Chi agisce? | Di norma il mittente che controlla gli input | Chi controlla un output del parent |
| Cosa cambia? | La transazione originale viene sostituita; nuova txid | Si crea un child; il parent non cambia |
| Fee valutata | Replacement e regole di relay | Feerate aggregata del pacchetto parent-child |
| Scelta tipica | Wallet offre “aumenta fee” | RBF non disponibile ma esiste un output spendibile |
Opt-in RBF, full RBF e campo nSequence
RBF è una policy di mempool e relay, non una regola di consenso Bitcoin. Nella forma opt-in descritta da BIP125, una transazione segnala esplicitamente la sostituibilità quando almeno un input ha nSequence inferiore a 0xfffffffe. Un valore inferiore a 0xffffffff rende inoltre disponibile nLockTime; valori particolari possono attivare i relative locktime di BIP68. Un wallet non dovrebbe cambiare questi numeri manualmente senza comprenderne gli effetti.
“Opt-in” non vieta la doppia spesa in assenza del segnale: indica solo che i nodi con quella policy valuteranno un replacement conforme. Con full RBF un nodo può farlo anche senza segnale. Supporto e relay dipendono da software, versione e configurazione; due nodi possono quindi avere mempool diversi.
Le regole di fee per una sostituzione
Un replacement non viene accettato solo perché mostra più sat/vB. Le policy derivate da BIP125 e implementate dai nodi impongono condizioni anti-spam e anti-DoS. In termini pratici, la nuova transazione deve confliggere con una transazione presente nel mempool del nodo; deve pagare almeno la fee assoluta complessiva delle transazioni che provoca la rimozione; e deve aggiungere una fee sufficiente a coprire la propria banda secondo l’incremental relay fee. Perciò aumentare appena la feerate può non bastare se il replacement è più piccolo, più grande o trascina discendenti.
La formulazione classica limita nuovi input non confermati e pone un tetto alle transazioni rimosse, normalmente 100 inclusi i discendenti. Le implementazioni moderne possono applicare varianti; Bitcoin Optech su RBF ne segue l’evoluzione.
Come funziona CPFP e la feerate del pacchetto
CPFP sfrutta la dipendenza tra transazioni. Il child spende un output del parent non confermato; il miner non può includerlo senza includere anche il parent. Per un parent e un child semplici, la feerate economica del pacchetto è (fee parent + fee child) / (vsize parent + vsize child). Non è la media aritmetica delle due feerate.
Supponiamo un parent da 200 vB con fee 1.000 sat, quindi 5 sat/vB. Vuoi portare il pacchetto a 30 sat/vB e il child occuperà 110 vB. La fee totale target è 30 × 310 = 9.300 sat; il child deve pagare circa 8.300 sat, cioè oltre 75 sat/vB. Una fee child di 30 sat/vB sarebbe insufficiente perché dovrebbe compensare anche il deficit del parent.
Con altri antenati, il calcolo include tutto ciò che il miner deve confermare. Il child deve superare la minimum relay fee e rispettare le policy di catena. Valori Bitcoin Core storicamente comuni sono 25 transazioni e 101.000 virtual byte, ma versioni e configurazioni differiscono. Package relay e mining aiutano alcuni casi; si veda Bitcoin Optech su CPFP.
Chi ha davvero il controllo: mittente, destinatario e resto
Il mittente può usare RBF solo se il wallet conserva le chiavi degli input, riconosce la transazione e sa costruire un replacement valido. Un prelievo da exchange custodial non offre questo controllo: solo l’exchange può sostituire la propria transazione. Importare una txid in un altro wallet non conferisce le chiavi.
Il destinatario può usare CPFP se il wallet consente di spendere l’output ricevuto prima della conferma. Alcuni wallet lo nascondono, bloccano le monete non confermate o non offrono coin control. Il mittente può fare CPFP sul change solo se esiste un output di resto, è riconosciuto come proprio e ha valore sufficiente per la fee e per evitare un output antieconomico o dust.
Il destinatario non può fare RBF sulla transazione altrui solo perché ne riceve un output; il mittente non può fare CPFP senza resto. Per distinguere input, output e change, consulta la spiegazione degli UTXO Bitcoin.
Tabella decisionale: RBF, CPFP o attesa
| Situazione | Scelta preferibile | Motivo |
|---|---|---|
| Sei il mittente, il wallet offre fee bump e la tx è sostituibile | RBF | È diretto e non crea una catena aggiuntiva |
| Sei il destinatario e puoi spendere l’output | CPFP | Non dipendi dal wallet del mittente |
| Sei il mittente, niente RBF, ma controlli il change | CPFP | Il child può alzare la feerate del pacchetto |
| La fee è già vicina alla stima e non c’è urgenza | Attesa | Evita sovrappagamento e complessità |
| Prelievo custodial senza output controllabile | Contattare il servizio/attendere | Non possiedi le chiavi necessarie |
| Parent assente dal mempool del tuo nodo | Diagnosticare prima | Potrebbe servire rebroadcast o una strategia diversa |
Se entrambe le opzioni sono disponibili, RBF è in genere più efficiente perché non aggiunge una seconda transazione. CPFP serve quando controlla il destinatario o RBF non è praticabile. Attendere resta valido, ma una tx sotto la min relay fee può non propagarsi.
Scenario pratico con numeri e vincoli
Alice invia 0,01 BTC a Bob. La transazione è 180 vB, paga 1.800 sat (10 sat/vB) e segnala opt-in RBF. Dopo un aumento della domanda, i blocchi includono transazioni intorno a 35 sat/vB. Alice ha urgenza e il wallet propone un replacement da 185 vB a 40 sat/vB, fee totale 7.400 sat. Verifica destinatario, importo, change e nuova fee, poi firma. Il replacement usa almeno un input confliggente, paga molto più dell’originale e, se accettato, riceve una nuova txid.
Se Alice non interviene, Bob può spendere il proprio output con un child da 120 vB. Parent più child occupano 300 vB; per 40 sat/vB servono 12.000 sat totali. Sottratti i 1.800 sat del parent, il child deve pagare circa 10.200 sat. Bob deve però avere un output abbastanza grande e un wallet capace di spendere fondi non confermati.
Se il parent ha altri antenati a bassa fee, 10.200 sat potrebbero non bastare. Se Alice ha già creato discendenti dal change, il replacement può doverli rimuovere e rispettare soglie più alte. Entrambi devono controllare la propagazione su più nodi: vedere la tx nel solo explorer del wallet non prova che l’intera rete la accetti.
Workflow nel wallet senza pagare due volte
- Conferma che la transazione sia non confermata e identifica la txid corretta. Se è già in un blocco, RBF e CPFP non possono modificarla.
- Leggi fee, vsize, feerate, input, output e presenza di antenati o discendenti. Non confondere BTC inviati con commissione.
- Stima una feerate coerente con l’urgenza usando più fonti o il tuo nodo. Un target di un blocco costa più di un target flessibile.
- Per RBF usa la funzione nativa “aumenta fee” o
bumpfee, non una seconda transazione indipendente. Bitcoin Core documenta l’RPC bumpfee. - Controlla sul dispositivo di firma destinatario, importo, change, fee assoluta e feerate. Un replacement può ridurre il change per finanziare l’aumento.
- Per CPFP seleziona espressamente l’output del parent con coin control. Calcola la fee sul pacchetto completo e crea un output finale non dust.
- Dopo il broadcast verifica che il replacement o la coppia parent-child siano accettati da fonti indipendenti. Conserva entrambe le txid.
Con hardware wallet, la schermata può mostrare solo la nuova transazione: confronta gli output, non firmare affidandoti all’etichetta “fee bump”. La checklist per inviare crypto aiuta a separare controllo dell’indirizzo e controllo della fee.
Rischi e limiti che l’interfaccia può nascondere
Una stima aggressiva può sovrappagare. Modificare output, change o txid può inoltre rompere contabilità e sistemi che seguono soltanto l’identificativo originale. Una promessa zero-conf resta provvisoria fino alle conferme richieste.
RBF può produrre replacement concorrenti visibili a sottoinsiemi diversi della rete. L’originale potrebbe confermarsi prima se raggiunge un miner che non ha ricevuto o accettato il replacement. CPFP può fallire perché il miner non valuta il pacchetto come previsto, perché un antenato manca, perché sono superati i limiti di catena o perché il child non si propaga.
Pinning e griefing permettono talvolta a una controparte di creare strutture che rendono la sostituzione costosa o difficile. Le policy riducono alcuni problemi, ma per somme elevate o transazioni multi-party serve un wallet avanzato, idealmente con nodo proprio.
Errori comuni da evitare
- Inviare di nuovo l’intero pagamento: due transazioni indipendenti possono confermarsi entrambe. Usa un replacement confliggente, non un duplicato.
- Guardare solo sat/vB del child: CPFP funziona sulla feerate aggregata di tutti gli antenati necessari.
- Credere che “RBF disattivato” significhi finale: full RBF e doppie spese restano possibili prima della conferma.
- Alzare la fee di un importo minimo: il replacement deve superare fee assoluta, costo incrementale e altre policy.
- Spendere change inconsapevolmente: discendenti non confermati complicano il replacement e possono essere eliminati dal mempool.
- Usare acceleratori che chiedono seed: nessun servizio legittimo necessita seed phrase o private key per ritrasmettere una tx.
- Confondere rebroadcast con fee bump: ritrasmettere la stessa tx non cambia fee né priorità economica.
Checklist finale e conclusione
- La transazione è davvero non confermata?
- Controlli gli input per RBF o un output per CPFP?
- Il wallet segnala opt-in RBF? Hai considerato la possibile policy full RBF?
- Hai calcolato fee assoluta, vsize e feerate, non soltanto una percentuale?
- Per CPFP hai incluso tutti gli antenati necessari?
- Il replacement rispetta incremento minimo, conflitti e limiti del mempool?
- Hai verificato destinatario, importo, change e nuova txid prima e dopo la firma?
- La spesa urgente giustifica la fee oppure puoi aspettare?
RBF e CPFP Bitcoin risolvono lo stesso problema da lati diversi. RBF è normalmente la scelta del mittente e sostituisce la transazione; CPFP è la leva di chi controlla un output e remunera il pacchetto. La decisione corretta nasce da controllo delle chiavi, struttura UTXO, policy dei nodi e calcolo della fee. Se uno di questi dati manca, diagnosticare e attendere è più sicuro che firmare una seconda operazione alla cieca.
