Penso che si stia creando un po' di confusione
Se trasmetti una 0-fee tx la politica del relaying non è sempre uguale, dipende dal nodo (implementazione, versione, etc).
Le tx in attesa di conferma vengono tenute nella mempool, la soluzione che suggerisce bitcoinplaza è quindi "parziale" nel senso che risolve la cosa solo localmente (la elimini dal tuo storico, ma è già stata trasmessa, quindi qualche altro nodo potrebbe averla ritrasmessa).
In ogni caso ad oggi la maggior parte dei nodi non tiene nella mempool le 0-fee tx e quindi non si propagherà molto nella rete (oltre ad avere priorità bassissima, ma questo dipende anche dall'input script age!).
La soluzione proposta sopra è comoda perchè permette di broadcastare una transazione con gli stessi input script (cosa normalmente non possibile ovviamente, per prevenire i double spend) ma con fee più alta. Questa nuova transazione verrà quindi ben propagata nella rete, nei mempool e poi inclusa in un blocco.
Anche il "double-spending" quindi è un concetto abbastanza relativo e non definitivo. I miner sono quelli che devono decidere se includere una tx nel blocco o meno, ma poi i nodi rioperano una verifica dei blocchi contro il double-spending. Se ci pensate un attimo siamo in una botte di ferro!
e si, oltrettutto se il client rimane aperto rifa il broadcast della trasazione ad intervallo regolare, mi sembra 30 minuti
per tentare double spending devi per forza esportare la PRiKey in formato Base58 creare un nuovo wallet, aprirlo, importare la PriKey da console, uscire, e fare rescan, poi puoi rimandare l'importo con fee superiore
c'è anche un online tool per forzare il double spending se volete posto link, ma io non fido ad usarlo
