Grazie Dusty, nel frattempo ho riflettuto che:
il CON dell'utente non si applica, ma piuttosto il suo wallet potrebbe vedere un mucchio di double spends.
Infatti se il wallet del ricevente è un po' ingenuo, vedrà un mucchio di incoming txs.
Una possibilità dovrebbe essere quella del parser intelligente di transazioni da parte del wallet (e vista la non uniformità del codice, lì fuori, questa cosa forse necessiterebbe di una BIP), che capisce che quel giro di double spends è fatto a questo scopo, e quindi:
a) riconosce gli input
b) annota il txhash
c) vede la nuova tx, controlla gli input, è un double spend? è RBF è una safe di tipo first seen? fa sparire dalla lista di incoming txs la vecchia tx, rimpiazzandola con la nuova, magari notifica la cosa, ma tendenzialmente potrebbe anche essere totalmente trasparente, sono scelte.
d) scarta il vecchio txhash, rimpiazza il txhash valido
e) l'utente non subisce il flood di incoming txs
Inoltre, parlavo di age, ma forse sarebbe più corretto dire che si riduce la frammentazione.
Topic: Gangsta, double spend con replace-by-fee (Read 9499 times)
Brainstorming \ FSS RBF USE CASE:
[...]
[...]
Mi sembra uno use case eccellente, ottima idea!
Quote
L'ho buttata lì, non so se ci siano problemi tecnici
Non è passeggiata l'implementazione, ma mi pare che da un punto di vista teorico stia tutto perfettamente in piedi.
Brainstorming \ FSS RBF USE CASE:
E' un discorso interessante per chi ha piattaforme gestite, puoi continuare a rimpiazzare la stessa TX con nuovi outputs fintanto che tu ne abbia bisogno (o finché questi non vengano inclusi). In questo modo, se ben configurato, mi pare si possa impostare un risparmio sulla transazione:
Utente 1 della mia piattaforma richiede un withdrawal, io gestore lo emetto, ho dei coins con tx age alta, che mi permettono buona priority a basse fees.
5 secondi dopo: Utente 2 della mia piattaforma richiede un withdrawal, io gestore rimpiazzo la tx precedente con questa, pagando entrambi.
Utente 3, utente 4, utente 5, richiedono un withdrawal, proseguo fin quando non ci sia un nuovo blocco a rimpiazzare la transazione, grazie a tx age e priority alta risparmio sulle tx fees, se invece avessi fatto una tx per utente, a prescindere da tutto avrei probabilmente dovuto impostare 0.1 mBTC di fee minimo per ogni withdrawal.
Arriva il blocco, verifico quale tx è stata inclusa, colmo l'eventuale gap con le tx che non sono state incluse.
PRO: Risparmio in fees, riduzione dello spreco di utxo con alta age
CONS: Delay sull'utenza
L'ho buttata lì, non so se ci siano problemi tecnici
E' un discorso interessante per chi ha piattaforme gestite, puoi continuare a rimpiazzare la stessa TX con nuovi outputs fintanto che tu ne abbia bisogno (o finché questi non vengano inclusi). In questo modo, se ben configurato, mi pare si possa impostare un risparmio sulla transazione:
Utente 1 della mia piattaforma richiede un withdrawal, io gestore lo emetto, ho dei coins con tx age alta, che mi permettono buona priority a basse fees.
5 secondi dopo: Utente 2 della mia piattaforma richiede un withdrawal, io gestore rimpiazzo la tx precedente con questa, pagando entrambi.
Utente 3, utente 4, utente 5, richiedono un withdrawal, proseguo fin quando non ci sia un nuovo blocco a rimpiazzare la transazione, grazie a tx age e priority alta risparmio sulle tx fees, se invece avessi fatto una tx per utente, a prescindere da tutto avrei probabilmente dovuto impostare 0.1 mBTC di fee minimo per ogni withdrawal.
Arriva il blocco, verifico quale tx è stata inclusa, colmo l'eventuale gap con le tx che non sono state incluse.
PRO: Risparmio in fees, riduzione dello spreco di utxo con alta age
CONS: Delay sull'utenza
L'ho buttata lì, non so se ci siano problemi tecnici
Beh, comunque anche un RBF che funziona solo se gli output sono uguali è infinitamente meglio di niente. Magari diventasse lo standard per i wallet!
Ciao!
Cambia però radicalmente dalla prima opzione, perchè non incentiva più il double spending. Ciao!
Eh infatti poco dopo hanno cambiato idea una volta adeguatamente informati 
https://www.reddit.com/r/Bitcoin/comments/3aejmu/f2pool_we_recognize_the_problem_we_will_switch_to/
Beh, comunque anche un RBF che funziona solo se gli output sono uguali è infinitamente meglio di niente. Magari diventasse lo standard per i wallet!https://www.reddit.com/r/Bitcoin/comments/3aejmu/f2pool_we_recognize_the_problem_we_will_switch_to/
Ciao!
Eh infatti poco dopo hanno cambiato idea una volta adeguatamente informati
https://www.reddit.com/r/Bitcoin/comments/3aejmu/f2pool_we_recognize_the_problem_we_will_switch_to/
https://www.reddit.com/r/Bitcoin/comments/3aejmu/f2pool_we_recognize_the_problem_we_will_switch_to/
OLD di 3 settimane, ma causa lavoro non ho davvero avuto tempo di seguire gli sviluppi dei miei progetti, fra cui gangsta:
https://www.reddit.com/r/Bitcoin/comments/3ae2e1/peter_todd_f2pool_enabled_full_replacebyfee_rbf/
Con F2Pool che entra in RBF e altri che già c'erano, possiamo dire che la possibilità di successful doublespend sale da una media di 1 su 10 (mie rilevazioni precedenti) a 1 su 3 (non confutata, ma l'hashingpower in questo caso parla al posto mio).
Visto l'evolversi della vicenda, se qualcuno volesse discutere con me la possibilità di trasformare Gangsta in un vero e proprio wallet mobile con RBF potremmo stabilire una roadmap :>
https://www.reddit.com/r/Bitcoin/comments/3ae2e1/peter_todd_f2pool_enabled_full_replacebyfee_rbf/
Con F2Pool che entra in RBF e altri che già c'erano, possiamo dire che la possibilità di successful doublespend sale da una media di 1 su 10 (mie rilevazioni precedenti) a 1 su 3 (non confutata, ma l'hashingpower in questo caso parla al posto mio).
Visto l'evolversi della vicenda, se qualcuno volesse discutere con me la possibilità di trasformare Gangsta in un vero e proprio wallet mobile con RBF potremmo stabilire una roadmap :>
replaced txs: http://pastebin.com/qiVScbWL
replaced via gangsta api: 379
replaced via gangsta: 109
1200 totali
~900 al mese
gangsta app hosted ha fatto il 9% delle rbf
gangsta api il 25%
in totale gangsta home ha fatto hits:
6791 61.53% http://gangsta.strangled.net/
per un totale di 1374 unici
replaced via gangsta api: 379
replaced via gangsta: 109
1200 totali
~900 al mese
gangsta app hosted ha fatto il 9% delle rbf
gangsta api il 25%
in totale gangsta home ha fatto hits:
6791 61.53% http://gangsta.strangled.net/
per un totale di 1374 unici
Complimenti! Adesso c'è solo da capire quanti minatori adottino il rbf. Da quanto ho capito di ufficiale e provato c'è solo btchina
replaced txs: http://pastebin.com/qiVScbWL
replaced via gangsta api: 379
replaced via gangsta: 109
1200 totali
~900 al mese
gangsta app hosted ha fatto il 9% delle rbf
gangsta api il 25%
in totale gangsta home ha fatto hits:
6791 61.53% http://gangsta.strangled.net/
per un totale di 1374 unici
replaced via gangsta api: 379
replaced via gangsta: 109
1200 totali
~900 al mese
gangsta app hosted ha fatto il 9% delle rbf
gangsta api il 25%
in totale gangsta home ha fatto hits:
6791 61.53% http://gangsta.strangled.net/
per un totale di 1374 unici
Grazie a tutti per le risposte! 
le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce
Succede perchè il client ha la TX precedente nella mempool. Basta riavviarlo
FaSan
Quindi il controllo viene fatto dal client solo in locale, la mempool è una memoria locale relativa a un singolo nodo? In tal caso la funzione di questa patch é solo evitare il riavvio del client.
La patch permettere di sostituire una TX già presente in mempool con una nuova, nel caso in cui la nuova abbia una fee più alta. Senza di questa vale la prima arrivata.
FaSan
le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce
Succede perchè il client ha la TX precedente nella mempool. Basta riavviarlo
FaSan
Quindi il controllo viene fatto dal client solo in locale, la mempool è una memoria locale relativa a un singolo nodo? In tal caso la funzione di questa patch é solo evitare il riavvio del client.
le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce
Succede perchè il client ha la TX precedente nella mempool. Basta riavviarlo
FaSan
Non si potrebbe fare una doppia spesa semplicemente creando due raw transaction come ha suggerito FaSan? Forse mi sfugge il senso di questa patch 
le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce
Non basta copiare qui le transazioni firmate e poi premere il tasto "Fornisci transazione"?
Quindi se ho ben capito il client bitcoin-core, che sia installato sul mio pc o su blockchainfo o da qualsiasi altra parte, ha tra le altre cose il compito di controllare, prima di immettere in rete una transazione, di non averne immessa già un'altra prima che utilizzi gli stessi input.
La mia domanda é: il controllo é "locale" o su tutta la rete? Mi spiego: il mio client controlla tutte le transazioni che ha giá immesso in rete prima di inviare una nuova, ma come può sapere se più o meno contemporaneamente tu dal tuo client stai cercando di spendere gli stessi input?
E una volta che due transazioni relative agli stessi input sono state immesse in qualche modo nella rete tutti i client e soprattutto tutti i client dei miner le devono inserire nella lista delle transazioni non confermate?
Oppure é necessario avere almeno due client patchati: quello da cui immettere la transazione in rete e quello di un miner che deve provare a convalidare un blocco?
Non si potrebbe fare una doppia spesa semplicemente creando due raw transaction come ha suggerito FaSan? Forse mi sfugge il senso di questa patch
le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce
Non basta copiare qui le transazioni firmate e poi premere il tasto "Fornisci transazione"?
Non si potrebbe fare una doppia spesa semplicemente creando due raw transaction come ha suggerito FaSan? Forse mi sfugge il senso di questa patch
le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce
Non basta copiare qui le transazioni firmate e poi premere il tasto "Fornisci transazione"?
1) una transazione a "zero fee" non dovrebbe neanche essere inserita tra le "transazioni non confermate" o sbaglio? -->
In realtà dalla versione 0.9 la fee minima è di 1000 satoshi (al di sotto la tx non viene registrata in mempool, quindi rischia di non essere propagata correttamente nel network)
una transazione a zero fee è legittima e viene propagata e se rispetta le regole:
- size minore di 1kb
- amount superiore a 0,01 btc
- ha abbastanza priorità (quasi sempre ce l'ha)
quindi se rispetta questi punti viene visualizzata come transazione in arrivo non confermata da tutti i wallet, almeno io ho provato con greenaddress, electrum e mycelium e tutti visualizzavano la transazione in arrivo come se fosse una normalissima transazione in arrivo (in effetti lo è).
2) hai usato il core patchato, quindi hai applicato la patch al sorgente di bitcoin-core e poi lo hai compilato? È un'operazione lunga/complicata sotto Linux ?
io ci ho messo un bel po' perchè sono imbranato, ma se sai compilarti core correttamente non è tanto difficile.
Non si potrebbe fare una doppia spesa semplicemente creando due raw transaction come ha suggerito FaSan? Forse mi sfugge il senso di questa patch
le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce
Ho giocato un po' anche io con core patchato replace by fee negli scorsi giorni, in particolare ho tentato 9 double spend con somme da 0,01 a 1,11 btc mettendo zero fee nella prima tx.
Ebbene: 9 double spend riusciti su 9 tentativi.
Ho notato che quasi tutti sono stati confermati da btc china, il che penso indichi che ha adottato RBF
Ebbene: 9 double spend riusciti su 9 tentativi.
Ho notato che quasi tutti sono stati confermati da btc china, il che penso indichi che ha adottato RBF
Quando dici che i tentativi di double spend sono stati "confermati", intendi che per ogni doppia spesa 1 transazione é finita in un blocco e l'altra é stata rifiutata?
Per farti un esempio pratico: io ti mando 1 btc a zero fee e tu lo vedi in ricezione nel tuo wallet, mezzora dopo mando una seconda transazione con lo stesso btc verso un mio address, se quest'ultima riceve una conferma a te quel btc non arriverà mai ma "tornerà" nel mio wallet (e la transazione in ingresso nel tuo scomparirà).
Ok capito.
Altre due domande:
1) una transazione a "zero fee" non dovrebbe neanche essere inserita tra le "transazioni non confermate" o sbaglio? -->
In realtà dalla versione 0.9 la fee minima è di 1000 satoshi (al di sotto la tx non viene registrata in mempool, quindi rischia di non essere propagata correttamente nel network)
2) hai usato il core patchato, quindi hai applicato la patch al sorgente di bitcoin-core e poi lo hai compilato? È un'operazione lunga/complicata sotto Linux ?
Non si potrebbe fare una doppia spesa semplicemente creando due raw transaction come ha suggerito FaSan? Forse mi sfugge il senso di questa patch
Oppure bisogna utilizzare bitcoin-core via riga di comando?
Si fà con le RAWTX via riga di comando. Nella blockchain la TX è valida solo dopo aver ricevuto la prima conferma dai nodi, prima di allora tutto può succedere
FaSan
Ho giocato un po' anche io con core patchato replace by fee negli scorsi giorni, in particolare ho tentato 9 double spend con somme da 0,01 a 1,11 btc mettendo zero fee nella prima tx.
Ebbene: 9 double spend riusciti su 9 tentativi.
Ho notato che quasi tutti sono stati confermati da btc china, il che penso indichi che ha adottato RBF
Ebbene: 9 double spend riusciti su 9 tentativi.
Ho notato che quasi tutti sono stati confermati da btc china, il che penso indichi che ha adottato RBF
Quando dici che i tentativi di double spend sono stati "confermati", intendi che per ogni doppia spesa 1 transazione é finita in un blocco e l'altra é stata rifiutata?
Per farti un esempio pratico: io ti mando 1 btc a zero fee e tu lo vedi in ricezione nel tuo wallet, mezzora dopo mando una seconda transazione con lo stesso btc verso un mio address, se quest'ultima riceve una conferma a te quel btc non arriverà mai ma "tornerà" nel mio wallet (e la transazione in ingresso nel tuo scomparirà).
Ho giocato un po' anche io con core patchato replace by fee negli scorsi giorni, in particolare ho tentato 9 double spend con somme da 0,01 a 1,11 btc mettendo zero fee nella prima tx.
Ebbene: 9 double spend riusciti su 9 tentativi.
Ho notato che quasi tutti sono stati confermati da btc china, il che penso indichi che ha adottato RBF
Ebbene: 9 double spend riusciti su 9 tentativi.
Ho notato che quasi tutti sono stati confermati da btc china, il che penso indichi che ha adottato RBF
Quando dici che i tentativi di double spend sono stati "confermati", intendi che per ogni doppia spesa 1 transazione é finita in un blocco e l'altra é stata rifiutata?
Jump to: