Gangsta, double spend con replace-by-fee

[arulbero]

L' input di un address è l' output di un altro no ? L' input è certo (se hai bitcoin nel wallet), l' output non è detto, finchè non le spendi.



FaSan

Sono output della tx precedente. Diciamo che tutte le banconote sono prima output e se spese input della tx successiva.

Si, stiamo confondendo TX e address, vedi la mia correzione sopra. Arulbero diceva in entrata riferendosi all' address. Chiaramente l' entrata di un address è l' output di una TX



FaSan

Esattamente quello che volevo dire, in entrata dal punto di vista dell'address.

Credo che alla transazione si possano aggiungere dati che sono degli script nei quali puoi codificare informazioni, nella blockchain ci sono vari documenti inseriti nelle tx quindi la dimensione dipende da cosa ci metti come info accessorie. Ad esempio puoi mettere l'hash di un documento per dimostrare che lo possedevi alla data nella quale la tx viene inserita.

Ma se faccio una transazione "normale", senza script particolari o informazioni codificate nascoste da qualche parte, la dimensione della transazione di fatto dipende solo dal numero di input e di output? Ogni banconota ha lo stesso peso in byte, indipendentemente dalla storia che ha alle spalle?

[picchio]

(...)
Ma se faccio una transazione "normale", senza script particolari o informazioni codificate nascoste da qualche parte, la dimensione della transazione di fatto dipende solo dal numero di input e di output? Ogni banconota ha lo stesso peso in byte, indipendentemente dalla storia che ha alle spalle?

Prova a guardare qui': https://en.bitcoin.it/wiki/Protocol_documentation#tx a naso direi che circa meno quasi la dimensione è quella, il problema e' che a volte per spedire x BTC devi raggruppare n "banconote" e generarti il resto. Mi pare che il client nuovo stimi la dimensione e pertanto le fee da pagare.
EDIT: mi sa che la dimensione dipende dalla lunghezza della signature e in TxIn compare un ?, quindi non e' fissa.

[arulbero]

(...)
Ma se faccio una transazione "normale", senza script particolari o informazioni codificate nascoste da qualche parte, la dimensione della transazione di fatto dipende solo dal numero di input e di output? Ogni banconota ha lo stesso peso in byte, indipendentemente dalla storia che ha alle spalle?

Prova a guardare qui': https://en.bitcoin.it/wiki/Protocol_documentation#tx a naso direi che circa meno quasi la dimensione è quella, il problema e' che a volte per spedire x BTC devi raggruppare n "banconote" e generarti il resto. Mi pare che il client nuovo stimi la dimensione e pertanto le fee da pagare.
EDIT: mi sa che la dimensione dipende dalla lunghezza della signature e in TxIn compare un ?, quindi non e' fissa.

Dal sito che mi hai linkato ricavo (se ho capito bene):

una transazione contiene 2 campi fissi da 4 byte ciascuno, uno per la versione e uno per il locktime. Poi contiene 2 campi variabili, uno per tutti gli input e uno per tutti gli output.
Ogni input è costituito da una parte fissa di 36 byte per il riferimento all'output della transazione precedente da cui proviene e da una parte di 4 byte per il sequence number, + una parte variabile per lo script che firma la transazione (ma perchè variabile? Forse perchè ci sono diversi modi di firmare una transazione, tipo multisig?)
Ogni output (sono più piccoli) occupa 8 byte per il valore della transazione + una parte variabile per lo script che controlla la chiave pubblica.

Quindi in sostanza la dimensione occupata da una transazione dipende dal numero degli input e degli output, con la complicazione della lunghezza variabile dei due script (come osservato già in un post precedente da picchio).

Da queste informazioni si può ricavare qualche indicazione pratica per la gestione del proprio portafoglio (quante banconote tenere in quante tasche)?
Per contenere le dimensioni di una transazione bisognerebbe effettuare transazioni con un unico input e due output (uno per il resto), ma per avere un solo input bisognerebbe periodicamente raggruppare le proprie banconote in un'unica e quindi sarebbe necessario fare in aggiunta delle transazioni periodiche di "riordino" da n banconote a una all'interno del proprio portafoglio. Non so se ne valga la pena.



Riporto qui sotto l'esempio della tx preso dal sito:
EDIT: su 282 byte totali, 139 byte sono occupati dallo script relativo all'unico input, 50 byte dai due script relativi ai due output, in totale 249 byte sono occupati dall'input e dai due output ( 180 byte dall'input e 69 byte dall'output). Inoltre ci sono i 24 byte dall'header del messaggio.

Code:

000000	F9 BE B4 D9 74 78 00 00  00 00 00 00 00 00 00 00   ....tx..........
000010	02 01 00 00 E2 93 CD BE  01 00 00 00 01 6D BD DB   .............m..
000020	08 5B 1D 8A F7 51 84 F0  BC 01 FA D5 8D 12 66 E9   .[...Q........f.
000030	B6 3B 50 88 19 90 E4 B4  0D 6A EE 36 29 00 00 00   .;P......j.6)...
000040	00 8B 48 30 45 02 21 00  F3 58 1E 19 72 AE 8A C7   ..H0E.!..X..r...
000050	C7 36 7A 7A 25 3B C1 13  52 23 AD B9 A4 68 BB 3A   .6zz%;..R#...h.:
000060	59 23 3F 45 BC 57 83 80  02 20 59 AF 01 CA 17 D0   Y#?E.W... Y.....
000070	0E 41 83 7A 1D 58 E9 7A  A3 1B AE 58 4E DE C2 8D   .A.z.X.z...XN...
000080	35 BD 96 92 36 90 91 3B  AE 9A 01 41 04 9C 02 BF   5...6..;...A....
000090	C9 7E F2 36 CE 6D 8F E5  D9 40 13 C7 21 E9 15 98   .~.6.m...@..!...
0000A0	2A CD 2B 12 B6 5D 9B 7D  59 E2 0A 84 20 05 F8 FC   *.+..].}Y... ...
0000B0	4E 02 53 2E 87 3D 37 B9  6F 09 D6 D4 51 1A DA 8F   N.S..=7.o...Q...
0000C0	14 04 2F 46 61 4A 4C 70  C0 F1 4B EF F5 FF FF FF   ../FaJLp..K.....
0000D0	FF 02 40 4B 4C 00 00 00  00 00 19 76 A9 14 1A A0   ..@KL......v....
0000E0	CD 1C BE A6 E7 45 8A 7A  BA D5 12 A9 D9 EA 1A FB   .....E.z........
0000F0	22 5E 88 AC 80 FA E9 C7  00 00 00 00 19 76 A9 14   "^...........v..
000100	0E AB 5B EA 43 6A 04 84  CF AB 12 48 5E FD A0 B7   ..[.Cj.....H^...
000110	8B 4E CC 52 88 AC 00 00  00 00                     .N.R......


Message header:
 F9 BE B4 D9                                       - main network magic bytes
 74 78 00 00 00 00 00 00 00 00 00 00               - "tx" command
 02 01 00 00                                       - payload is 258 bytes long
 E2 93 CD BE                                       - checksum of payload

Transaction:
 01 00 00 00                                       - version

Inputs:
 01                                                - number of transaction inputs

Input 1:
 6D BD DB 08 5B 1D 8A F7  51 84 F0 BC 01 FA D5 8D  - previous output (outpoint)
 12 66 E9 B6 3B 50 88 19  90 E4 B4 0D 6A EE 36 29
 00 00 00 00

 8B                                                - script is 139 bytes long

 48 30 45 02 21 00 F3 58  1E 19 72 AE 8A C7 C7 36  - signature script (scriptSig)
 7A 7A 25 3B C1 13 52 23  AD B9 A4 68 BB 3A 59 23
 3F 45 BC 57 83 80 02 20  59 AF 01 CA 17 D0 0E 41
 83 7A 1D 58 E9 7A A3 1B  AE 58 4E DE C2 8D 35 BD
 96 92 36 90 91 3B AE 9A  01 41 04 9C 02 BF C9 7E
 F2 36 CE 6D 8F E5 D9 40  13 C7 21 E9 15 98 2A CD
 2B 12 B6 5D 9B 7D 59 E2  0A 84 20 05 F8 FC 4E 02
 53 2E 87 3D 37 B9 6F 09  D6 D4 51 1A DA 8F 14 04
 2F 46 61 4A 4C 70 C0 F1  4B EF F5

 FF FF FF FF                                       - sequence

Outputs:
 02                                                - 2 Output Transactions

Output 1:
 40 4B 4C 00 00 00 00 00                           - 0.05 BTC (5000000)
 19                                                - pk_script is 25 bytes long

 76 A9 14 1A A0 CD 1C BE  A6 E7 45 8A 7A BA D5 12  - pk_script
 A9 D9 EA 1A FB 22 5E 88  AC

Output 2:
 80 FA E9 C7 00 00 00 00                           - 33.54 BTC (3354000000)
 19                                                - pk_script is 25 bytes long

 76 A9 14 0E AB 5B EA 43  6A 04 84 CF AB 12 48 5E  - pk_script
 FD A0 B7 8B 4E CC 52 88  AC

Locktime:
 00 00 00 00                                       - lock time

EDIT: altro esempio di transazione preso da questo interessantissimo sito  http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html

Code:

-------------------------------------------------------------------------------------------------------------------------------------------
version	                                      01 00 00 00
-------------------------------------------------------------------------------------------------------------------------------------------
input count	                              01
-------------------------------------------------------------------------------------------------------------------------------------------
                    previous output hash      48 4d 40 d4 5b 9e a0 d6 52 fc a8 25 8a b7 ca a4 25 41 eb 52 97 58 57 f9 6f b5 0c d7 32 c8 b4 81
                    ------------------------------------------------------------         
                    previous output index     00 00 00 00
input               ---------------------------------------------------------------------------------------------------------------------------  
                    script length	
                    ----------------------------------------------------------------------------------------------------------------------------
                    scriptSig	              script containing signature
                    ----------------------------------------------------------------------------------------------------------------------------
                    sequence	              ff ff ff ff
-------------------------------------------------------------------------------------------------------------------------------------------
output count	                              01
-------------------------------------------------------------------------------------------------------------------------------------------
                    value	              62 64 01 00 00 00 00 00
                    ----------------------------------------------------------------------------------------------------------------------------
output              script length	
                    ---------------------------------------------------------------------------------------------------------------------------
                    scriptPubKey	      script containing destination address
-------------------------------------------------------------------------------------------------------------------------------------------
block lock time	                              00 00 00 00
-------------------------------------------------------------------------------------------------------------------------------------------

[Anon39]

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, e considerando che ha il 7% del net hashrate direi che la probabilità di effettuare una doppia spesa non è così irrilevante anche con fee standard nella prima tx.
La seconda tx l'ho lanciata con un delay variabile a partire da pochi secondi, a qualche minuto, fino ad arrivare a circa 45 minuti da una tx all'altra.
per ora sono a 9 su 9, nei prossimi giorni farò qualche altro test, direi comunque che al momento considerare come buona una tx in ingresso a zero o basse fee è assolutamente da evitare.

[arulbero]

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

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?

[Anon39]

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

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?

sì intendo che la transazione di doppia spesa (la seconda transazione immessa nel network con gli stessi input della prima) ha ricevuto una conferma, e quando questo succede la prima non potrà più essere immessa nella blockchain (a meno che non ci sia un fork).
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à).

[arulbero]

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

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?

sì intendo che la transazione di doppia spesa (la seconda transazione immessa nel network con gli stessi input della prima) ha ricevuto una conferma, e quando questo succede la prima non potrà più essere immessa nella blockchain (a meno che non ci sia un fork).
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

[Anon39]

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

[arulbero]

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"? 

[Anon39]

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"? 

solo se anche il client di blockchaininfo fosse patchato

[arulbero]

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"?  

solo se anche il client di blockchaininfo fosse patchato

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?

[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

[arulbero]

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.

[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.

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

[arulbero]

Grazie a tutti per le risposte! 

[gdassori]

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

[alexrossi]

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

Complimenti! Adesso c'è solo da capire quanti minatori adottino il rbf. Da quanto ho capito di ufficiale e provato c'è solo btchina

[gdassori]

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

[HostFat]

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/

[Stemby]

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!

Ciao!