Topic: Transazioni lente: come scegliere le fee prima, o come sbloccarle dopo - page 4. (Read 62881 times)

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-cm717300

e un altro più tecnico/generale:  https://gist.github.com/roybadami/7bd2ea56a06984fedace#user-content-stuck-transactions


Un 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:

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-parent

Alcune osservazioni sulle motivazioni:

https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/

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-fee


Riassumendo 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).

Premetto che per dare consigli pratici bisognerebbe aver provato almeno una volta ad utilizzare uno di questi metodi, e io non ne ho utilizzato finora neanche uno.

Guardando alla sezione internazionale, ci sono vari suggerimenti:

1) aspettare che la rete si dimentichi della tx e poi reinviarla normalmente con fee maggiorate
-->  https://bitcointalk.org/index.php?topic=232979.0  (strategia Wait & Resend)

2) Replace By Fee (RBF) (ogni miner poi la utilizza come vuole, mi pare di aver capito che di default Bitcoin Core richieda che solo le transazioni marcate in modo speciale possono essere sostituite: "A transaction must be marked replaceable (sequence number below MAX-1) in order for the opt-in RBF implementation to treat it as replaceable." , quindi se uno ha inviato in modo "normale" una transazione che poi si blocca, come fa poi a sostituirla? Non mi è chiaro)

3) Child Pays for Parent (CPFP)  (Already implemented in Android Wallet and Eligius mining pool): mai usata

Da notare comunque che si può sempre creare una seconda transazione (deve farlo il ricevente) a mano, senza bisogno di altro:

"You can create a transaction which spends the output to yourself, attaching a fee to that transaction. In order for miners to grab the transaction fee on that transaction, they would have to also mine the original transaction. Likely, you'd have to do this by hand, but software could be written to simplify doing it. No protocol changes needed"

4) Qui si trova un programmino open source che permette di creare una transazione sfruttando RBF o CPFP (Bitcoin Transaction Fee Booster - mai usato)

5) se proprio si è disperati si può contattare qualcuno come macbook-air che ha accesso a una pool --> https://bitcointalksearch.org/topic/f2pool-700411 pregandolo (dietro compenso immagino) di includere la propria tx in un blocco

La cosa più semplice a livello pratico sarebbe l'opzione 5) (ma anche la meno pulita), anche la 3) non è male, ma deve essere il ricevente che si occupa di rendere effettivo il pagamento che riceve in modo "non confermato".
Per dare consigli più pratici, ripeto, bisognerebbe avere usato in prima persona uno di questi metodi e fare un piccolo how-to, altrimenti rimangono ragionamenti un po' teorici e poco utili soprattutto per i nuovi arrivati.

Alcune considerazioni teoriche su CPFP : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008232.html

hai ragione, questo link non funziona... probabilmente e' ora di dare
una rinfrescata a questo post.

Hai suggerimenti sul come migliorarlo e integrare (in modo pratico) le nozioni di CPFP ?

L'idea era di inviare in questo post gli utenti che sono rimasti impantanati in una transazione "endless"
e come vedi ce ne sono sempre di piu' !

Data una transazione bloccata a causa di fee insufficienti che sposti fondi da A --> B (indirizzo di partenza e indirizzo di arrivo), ci sono almeno due modi previsti per sbloccarla:

1)RBF -  replace by fee : ho pagato troppo poco, aggiungo altri soldi

2)CPFP - Child pays for parent: ho pagato troppo poco, paga per me colui che è destinatario della transazione

Oltre a RBF di cui si è parlato nel primo post esiste quindi un altro metodo, CPFP,  per sbloccare delle transazioni, supportato da Core 0.13.0 in poi  --> http://bitcoin.stackexchange.com/questions/49723/replace-by-fee-vs-child-pays-for-parent
https://bitcoincore.org/en/faq/optin_rbf/#what-is-child-pays-for-parent-cpfp

Questo metodo è utile nel caso in cui, dopo aver inviato la transazione che rimane bloccata, si perda la chiave privata relativa all'indirizzo A di partenza. In questo caso infatti non è più possibile rifare un'altra transazione da A a B con più fee e firmarla (metodo RBF). In questa particolare situazione i fondi rimarrebbero vincolati per sempre all'indirizzo A, senza poter essere più spesi, pur esistendo una tx regolarmente firmata che potrebbe sbloccarli (se solo un miner decidesse di includerla in un blocco).

Con CPFP si può creare allora una seconda transazione da B -> C che muove i btc dall'indirizzo B fornendo fee sufficienti a indurre i miner a includere nel blocco sia la transazione bloccata A -> B che la successiva B -> C (che da sola ovviamente non sarebbe valida senza la prima transazione).
L'onere dello sbloccaggio quindi ricade su colui che possiede la chiave dell'indirizzo di arrivo B della prima tx.



A me questo link non funziona, non so se sia solo una questione temporanea. Sulla situazione di diffusione di questa patch (la cui adozione è quantificata a maggio scorso nel 20% dell'hash power) qui c'è un articolo fatto molto bene (non parla solo di GreenAddress)-> https://bitcoinmagazine.com/articles/greenaddress-is-first-bitcoin-wallet-to-launch-replace-by-fee-bitcoin-transactions-miner-adoption-slow-1463516896.



Ma mi pare ci sia comunque un minimo di fee, sarebbe bello se ci fosse invece un modo per indirizzare direttamente ai miner qualche tx con fee insufficienti per sbloccarle, non mi sembra questo il caso.

ho inserito il sistema viabtc qui, penso potrebbe essere utile come
ulteriore via di fuga da una transazione "Impantanata"

sapete darmi una descrizione di come funziona la RPC abandontransaction ?

sto cercando di accumulare i consigli che ho letto questi giorni...
devo dire che mi sembra una cosa che puo' essere interessante.

il giorno in cui qualcuno adotterà un calendario basato sul numero di blocchi, il bitcoin avrà definitivamente vinto

ah interessante, scusate se ho aperto un doppione, andiamo pure su quello.

non l'avevo visto !

C'era anche questo thread a riguardo:  https://bitcointalksearch.org/topic/m.13232406

Argomento interessante.

merita solo per questo

"Predicting Bitcoin fees for transactions since 1759"

aggiungerei anche questo link....per controllare che fee usano e tempo stimato


http://bitcoinfees.21.co/

...

In questo periodo di rete intasata, capita sovente di leggere post di gente che  ha problemi con i tempi delle transazioni.
Cerco di dare alcuni consigli su come comportarsi.

Ovviamente il metodo migliore e' scegliere una fee adeguata prima di fare la transazione,
in modo da avere massima probabilita' che la transazione venga inclusa velocemente in un blocco.

Ma anche nel caso abbiate gia' effettuato una transazione che rimane appesa per troppo tempo
(fee troppo bassa, transazione particolarmente "sfortunata" ...) si puo' fare qualcosa.

Come comportarsi Prima di fare la transazione:

usare un wallet come electrum che indica che fee usare per avere
la transazione confermata entro un certo tempo (statisticamente)

verificare lo stato di "intasamento" della rete:
http://blockspeed.info

un link interessante ad un sito che visualizza l'andamento delle fee per decidere un fee consona
alla propria transazione e al probabile tempo di esecuzione:
http://bitcoinfees.21.co/

Come comportarsi Dopo, ossia quando sia ha una transazione ferma da troppo tempo:

novita'

usare questi tools online:

https://www.viabtc.com/tools/txaccelerator/


Oppure  dalla console di bitcoin core (versione 0.12 o maggiore), usare l'api

abandontransaction

permette di annullare (localmente!) la transazione e rifarne un'altra. attenzione, per tutti gli
altri membri della rete, risultera' una double-spending, e probabilmente verra' inclusa  in un prossimo
blocco quella con la fee piu' alta.

Oppure se sapete forgiare una transazione per creare una "double spending" e usare un attrezzo tipo questo per iniettarla in rete:

https://coinb.in/
Un wallte scritto in javascript che gira sul browser, e che permette di gestire le raw trasaction