Segnalo questo articolo su come fare a sbloccare una transazione bloccata:
http://www.nasdaq.com/article/what-to-do-if-your-bitcoin-transaction-gets-stuck-cm717300e un altro più tecnico/generale:
https://gist.github.com/roybadami/7bd2ea56a06984fedace#user-content-stuck-transactionsUn grosso ruolo lo svolge il proprio wallet, se infatti esso:
1) consente di controllare quali output si spendono
2) consente di (ri)spendere output non confermati
allora in questo caso si può tentare a mano sia la strategia RBF** che la strategia CPFP;
per quest'ultima, si può anche fare a meno della collaborazione del ricevente qualora nella transazione originale almeno un output sia stato indirizzato di ritorno al proprio wallet (indirizzo del resto). In tal caso infatti basta tentare di rispendere quell'output non ancora confermato reindirizzandolo di nuovo verso il proprio wallet con delle fee adeguate a coprire sia la nuova tx che quella precedente, in modo da invogliare i miner a inserire entrambe le transazioni in un blocco.
NB: si dice che CPFP sia nata per difendere il ricevente dalla nuova possibilità di essere defraudato fornita al mittente da RBF:
CPFP relates to RBF as a way for a merchant to fight fraud. If a merchant detects that a payment they were expecting has been rerouted, they can raise the priority of their preferred transaction using CPFP. This is a
contentious solution to make RBF acceptable.
Alcuni wallet come Electrum e GreenAddress dovrebbero avere una specifica opzione "Opt-In RBF" che segnala ai miner che una certa transazione potrebbe essere sostituita in futuro con una che paga più fee; ecco un'
analisi di Peter Todd sulla situazione dei wallet riguardo questa opzione e su come fosse facile effettuare una doppia spesa a insaputa del destinatario (l'articolo è del gennaio scorso)
**Oggettivamente c'è molta confusione attorno a queste nuove possibilità di formare transazioni, per esempio RBF può significare:
a) posso sostituire
una transazione qualsiasi solo con un'altra quasi uguale per quanto riguarda input/output (in sostanza si possono aggiungere input e output, ma non togliere gli output precedenti nè diminuirne il valore assegnato --> "higher fee with superset of outputs of first spend")
e con fee maggiorate (first seen safe replace-by-fee
"FSS-RBF")
b) posso sostituire
solo una specifica transazione che ho precedentamente flaggato con "
Opt-In RBF"
con un'altra qualsiasi (anche cambiando gli address destinatari) (questa dovrebbe essere l'opzione con più chance di successo perchè adottata ufficialmente in Core); il flag (che si può anche attivare a mano modificando il campo nSequence della tx -->
"Transactions opt-in to transaction replacement by setting nSequence < maxint-1 on at least one input" ) permette da una parte al miner di sapere che chi ha creato la transazione era già disposto ad "aggiornarla" ed eventualmente a sostituirla sin dal momento della sua creazione, dall'altra permette a colui che riceve il pagamento di ricevere un segnale (dovrebbe visualizzare un messaggio di allerta sul pericolo di una doppia spesa e quindi dovrebbe aspettare che la tx sia inclusa in un blocco prima di considerarla come un pagamento effettivo).
"Opt-in" da "Option In" vuol dire in inglese: "Express permission by a customer, or a recipient of a mail, email, or other direct message to allow a marketer to send a merchandise, information, or more messages". E' una specie di assenso firmato che in questo caso rende una tx ufficialmente sostituibile con il permesso del proprietario.c) posso sostituire
una transazione qualsiasi con un'altra che spende gli stessi input ma
con output completamente differenti (
"full RBF", e Core dovrebbe indirizzarsi in futuro verso questa possibilità)
Core per adesso ha scelto la seconda opzione, Opt-In RBF + CFPC :
https://github.com/bitcoin/bitcoin/blob/fc23fee690477828e84a7886dbf208e9a96e82e2/doc/release-notes/release-notes-0.12.0.md#opt-in-replace-by-fee-transactions
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.0.md#user-content-mining-transaction-selection-child-pays-for-parentAlcune osservazioni sulle motivazioni:
https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/
The Core devs want to use Opt-in RBF to "compress" transactions and FSS-RBF Doesn't allow that.
FSS-RBF (1) results in larger transactions because you must add a new input rather than just adjust your change output, and (2) is a wallet implementor's nightmare to get right because it involves merging coins to update a fee. If you care about privacy and/or keeping sources of coins separate to defeat block chain analysis, FSS-RBF requires keeping pools of UTXOs available to update fees
I critici di FSS-RBF affermano inoltre che non è scontato stabilire cosa vuol dire "vista per prima" (dopotutto la blockchain nasce proprio per stabilire un ordine temporale in una serie di eventi che avvengono a distanza, mentre le transazioni in mempool non hanno una cronologia definita e univoca per tutti i nodi della rete), ma questo succede già di norma con tutte le transazioni (solo quelle viste per prima vengono accettate da un nodo, le altre che tentano di spendere gli stessi output non vengono accettate).
Peter Todd, che ha creato la patch con Opt-in RBF per Core, sostiene comunque FSS-RBF, qui spiega come funziona FSS-RBF e quali sono i vantaggi:
http://bitcoin-development.narkive.com/NgSiQBmM/bitcoin-development-first-seen-safe-replace-by-feeRiassumendo ci sono almeno 3 variabili di cui tener sempre conto:
1) bisogna conoscere a fondo il proprio wallet e come esso si regola con le transazioni non confermate (e come si fa ad esempio a far sì che la smetta di continuare a ritrasmettere una tx che si è appurato che nessun miner intende includere in un blocco)
2) bisogna sapere quali sono le condizioni del mercato per le fee per "indovinare" una fee adeguata
3) bisogna conoscere quali sono le esatte regole utilizzate dai miner (FSS-RBF, Opt-in RBF, Full RBF, CPFP) per poter costruire una seconda tx che abbia successo nell'annullare/sbloccare la prima
Da osservare che queste policy riguardanti la sostituzione di una tx nella mempool non fanno parte delle regole del consenso, cioè è a discrezione dei full node e dei miner impostare la propria politica, e tutto questo rende più difficile e fumosa l'intera questione.
Il grosso problema che vedo in mezzo a tutto questo tecnicismo è che è facile che in queste situazioni incappino soprattutto i nuovi arrivati nel mondo bitcoin, e non è un bel modo di conoscere il btc, dall'altra parte quelli un po' più "esperti" in generale non sono per nulla esperti in problemi di questo tipo perchè magari sono più attenti con le fee e quindi alla fine non sono in grado di dare consigli pratici non essendo mai capitati in situazioni del genere.
Faccio infine notare che inviare una transazione non vuol dire pagare, ma al massimo si dimostra l'intenzione di effettuare un pagamento, quindi si tratta a tutti gli effetti di una "proposta" di pagamento alla rete che deve poi accettarla.
Finchè un pagamento non è confermato i bitcoin rimangono in possesso di chi detiene le chiavi private (anche se momentaneamente potrebbero apparire come "congelati"), ed è sua responsabilità far in modo che questo pagamento arrivi in qualche modo al destinatario (penso soprattutto alla situazione in cui uno ha dei btc depositati presso un exchange/siti vari e deve ricevere un pagamento in sospeso).
