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 10110 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?
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.
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.
(...)
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.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?
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 [email protected]....
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
-------------------------------------------------------------------------------------------------------------------------------------------
(...)
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.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?
EDIT: mi sa che la dimensione dipende dalla lunghezza della signature e in TxIn compare un ?, quindi non e' fissa.
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.FaSan
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?
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
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.FaSan
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
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.FaSan
Ok se parliamo di TX si parla di input e di output, se si parla di address allora in entrata ci stà.
FaSan
(...)
Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata )
Premesso che non mi piace parlare di banconote ma se aiuta a capire meglio ....Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata
)Banconota: un input oppure un output di una transazione TX.
NB: ci sono transazioni senza input e sono le revenue per la generazione del blocco https://blockchain.info/it/tx/5f2a72ad2dc4d189742db3d686742d2b4caa8c7b53d3463c217d10bd11309a11
Tasca: indirizzo BTC direi che puo' andare ...
Per questo preferisco la definizione di banconota come output di una transazione TX, proprio perchè ci sono banconote che non hanno un indirizzo di provenienza.
Avrei altre due domande:
1) quando si effettua una transazione si pagano delle fee che dipendono da alcuni parametri (ad esempio da quanto tempo quei bitcoin non vengono spostati, ...) e in particolare dipendono anche dalla dimensione della transazione. La mia domanda è: la dimensione della transazione è determinata solo dal numero di input e numero di output (cioè dal numero di banconote che prende in input e dal numero di banconote che restituisce in output)? Cioè in pratica ogni banconota occupa lo stesso spazio in byte?
(...)
(...)
Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata )
Premesso che non mi piace parlare di banconote ma se aiuta a capire meglio ....Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata
)Banconota: un input oppure un output di una transazione TX.
NB: ci sono transazioni senza input e sono le revenue per la generazione del blocco https://blockchain.info/it/tx/5f2a72ad2dc4d189742db3d686742d2b4caa8c7b53d3463c217d10bd11309a11
Tasca: indirizzo BTC direi che puo' andare ...
Per questo preferisco la definizione di banconota come output di una transazione TX, proprio perchè ci sono banconote che non hanno un indirizzo di provenienza.
Avrei altre due domande:
1) quando si effettua una transazione si pagano delle fee che dipendono da alcuni parametri (ad esempio da quanto tempo quei bitcoin non vengono spostati, ...) e in particolare dipendono anche dalla dimensione della transazione. La mia domanda è: la dimensione della transazione è determinata solo dal numero di input e numero di output (cioè dal numero di banconote che prende in input e dal numero di banconote che restituisce in output)? Cioè in pratica ogni banconota occupa lo stesso spazio in byte?
2) questa domanda è più attinente all'argomento di questo thread: la questione del "double spending".
Finora ho sempre sentito parlare di questo argomento come di un problema da cui difendersi, ma non ho mai capito come sia possibile poi nella pratica effettuare una doppia spesa.
Mi spiego: se uso un client come Armory o GreenAddress, non appena comunico alla rete una transazione da un mio indirizzo bitcoin il client segnala come non più disponibili per la spesa i btc inviati (anche se la transazione deve essere ancora confermata ovviamente). A questo punto come sarebbe possibile (senza utilizzare la web app "gangsta") effettuare una doppia spesa degli stessi input?
Dovrei forse importare le chiavi private del mio indirizzo in due client diversi, e quasi contemporaneamente effettuare la spesa della stessa banconota dai due diversi client (in modo che nessuno dei due "sappia" cosa sta facendo l'altro)? Oppure bisogna utilizzare bitcoin-core via riga di comando?
Cercate di non essere eccessivamente tecnici nelle risposte
(...)
Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata )
Premesso che non mi piace parlare di banconote ma se aiuta a capire meglio ....Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata
)Banconota: un input oppure un output di una transazione TX.
NB: ci sono transazioni senza input e sono le revenue per la generazione del blocco https://blockchain.info/it/tx/5f2a72ad2dc4d189742db3d686742d2b4caa8c7b53d3463c217d10bd11309a11
Tasca: indirizzo BTC direi che puo' andare ...
Questo modo di vedere le cose é corretto?
E' corretto. Il mio "Transazione=Banconota" era da intendersi TX in entrata. Una TX in entrata è una banconota, se poi in origine fosse sempre una o mille è del tutto irrilevante dal tuo punto di vista.
FaSan
Bene, grazie mille! Finalmente ( dopo solo 1 anno e mezzo che uso i bitcoin ) penso di aver capito!
Allora perfeziono la mia definizione di banconota:
Banconota: transazione + indirizzo d'arrivo ( o più semplicemente TX in entrata
)Questo modo di vedere le cose é corretto?
E' corretto. Il mio "Transazione=Banconota" era da intendersi TX in entrata. Una TX in entrata è una banconota, se poi in origine fosse sempre una o mille è del tutto irrilevante dal tuo punto di vista.
FaSan
(...)
nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
(..)
Non necessariamente, quello che devi immaginare che ogni transazione ha n input e k output, quelle due transazioni potrebbero arrivare da 100 input che danno luogo 300 output due dei quali sono le due alle quali tu ti riferisci. nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
(..)
Ad esempio: https://blockchain.info/it/tx/eaf0404075adb9c9f10d4640affa368bcb44ebb9af3e7b2966c104e77ed46b6c ha parecchi input e parecchi output.
Lì infatti stavo usando la similitudine di FaSan "transazione=banconota" che però secondo me risulta ambigua.
Allora ripropongo la mia pseudodefinizione:
"banconota": "coppia formata da una transazione e un indirizzo (
In una transazione con n input e k output, vengono prelevate n banconote ( da n address o meno, posso prelevare 2 banconote diverse dalla stessa tasca/address) e convertirle in k banconote ( che finiscono in k address o meno, 2 banconote diverse possono finire nella stessa tasca/address ).
Ognuna delle n banconote di partenza sono costituite da una transazione precedente a quella attuale e da un indirizzo di partenza, ognuna delle k banconote di output sono costituite ( cioé univocamente determinate ) dalla transazione attuale e dall'indirizzo d'arrivo.
In linea di massima tutte le banconote di partenza provengono da address di un unico wallet ( tasche di un unico portafoglio ) in modo che sia possibile firmare la transazione per ogni banconota di partenza. Il caso a cui allude FaSan di transazioni che possono mettere insiemi indirizzi di partenza di più wallet non lo conosco, ma immagino che il concetto sia che ci deve essere un modo di importare le chiavi giuste relative ai vari address per poter firmare la transazione.
Riscrivo allora il caso 2)
Ho una banconota da 2 BTC nella tasca A e una da 3 BTC nella tasca B, le ho ottenute mettendo insieme delle banconote provenienti da un'unica transazione ( quindi la banconota da 2 BTC e quella da 3 BTC condividono solo uno dei due elementi che le caratterizza, la transazione che le ha prodotte, ma non l'indirizzo d'arrivo). Quindi essendo due banconote distinte posso spenderle separatamente.
Ma a questo punto un'altra osservazione: nel caso 3), in cui ho due banconote, una da 2 BTC e una da 3 BTC entrambe nella tasca A, se le spedissi entrambe a un indirizzo C, avrei generato da due banconote distinte una sola banconota da 5 BTC ( univocamente determinata dalla nuova transazione e dall'indirizzo d'arrivo C ).
Per concludere il ruolo di una transazione allora é duplice:
- da una parte cambiare il "proprietario" di bitcoin ( spostare i bitcoin da delle tasche ad altre tasche )
- dall'altra parte é quella di prendere una quantitá totale x di bitcoin e trasformarla in una quantitá x (- fees) cambiando peró il numero di banconote, cioè la distribuzione dei tagli mantenendo costante la quantità totale x; in questo senso una transazione "distrugge" delle banconote e ne "ricrea" altre al loro posto in tagli più adeguati all'utilizzo che si deve fare di quella quantità di bitcoin in quel dato momento
Questo modo di vedere le cose é corretto?
(...)
nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
(..)
Non necessariamente, quello che devi immaginare che ogni transazione ha n input e k output, quelle due transazioni potrebbero arrivare da 100 input che danno luogo 300 output due dei quali sono le due alle quali tu ti riferisci. nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
(..)
Ad esempio: https://blockchain.info/it/tx/eaf0404075adb9c9f10d4640affa368bcb44ebb9af3e7b2966c104e77ed46b6c ha parecchi input e parecchi output.
Quindi più precisamente si potrebbe dire che una transazione non è una banconota, ma lo è l'accoppiata transazione-indirizzo di destinazione (mentre mi pare di aver capito che gli indirizzi d'origine non contino in questo tipo di ragionamento).
Così è tutto corretto?
Così è tutto corretto?
E' sempre una banconota, indipendentemente da dove la metti. Quando è il momento di pagare puoi mettere la mano in una sola tasca, ma anche metterle in più tasche se con la prima non copri l' importo che intendi muovere. Se usi un wallet le tasche (address) devono essere nello stesso wallet, ma ci sono sistemi un pelino più complessi che ti cito appena per non incasinarti ulteriormente, che ti permettono di usare anche address che hai altrove.
FaSan
Se metti una banconota in due tasche non é piú una banconota, ma sono almeno due!
Da come ho capito io una transazione unisce piú input ( piú banconote ) in un'unica banconota solo per poi risuddividerle di nuovo in altre banconote ( una per ogni indirizzo di output ), o no?
Quindi più precisamente si potrebbe dire che una transazione non è una banconota, ma lo è l'accoppiata transazione-indirizzo di destinazione (mentre mi pare di aver capito che gli indirizzi d'origine non contino in questo tipo di ragionamento).
Così è tutto corretto?
Così è tutto corretto?
E' sempre una banconota, indipendentemente da dove la metti. Quando è il momento di pagare puoi mettere la mano in una sola tasca, ma anche metterle in più tasche se con la prima non copri l' importo che intendi muovere. Se usi un wallet le tasche (address) devono essere nello stesso wallet, ma ci sono sistemi un pelino più complessi che ti cito appena per non incasinarti ulteriormente, che ti permettono di usare anche address che hai altrove.
FaSan
(...)
caso 2) se ho 2 BTC sul mio indirizzo A e 3 BTC sul mio indirizzo B provenienti dalla stessa transazione x, allora se voglio spendere 2 BTC posso spendere i 2 BTC dell'indirizzo A senza toccare i 3 BTC dell'indirizzo B (non importa che tutti e 5 provengano dalla stessa transazione, sono in qualche modo "separati" dagli indirizzi su cui sono stati "indirizzati")
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
caso 2) se ho 2 BTC sul mio indirizzo A e 3 BTC sul mio indirizzo B provenienti dalla stessa transazione x, allora se voglio spendere 2 BTC posso spendere i 2 BTC dell'indirizzo A senza toccare i 3 BTC dell'indirizzo B (non importa che tutti e 5 provengano dalla stessa transazione, sono in qualche modo "separati" dagli indirizzi su cui sono stati "indirizzati")
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
Secondo me il 3) è sbagliato. Puoi spendere sia i 2 che i 4 proprio perche' di due transazioni differenti anche se dirette allo stesso indirizzo.
Esatto. Vedi le singole TX come singole banconote a cui chiaramente non puoi strappare pezzi, ma devi darla intera e ricevere un resto.
FaSan
Certo che la distinzione è sottile. A prima vista mi sembrava che i casi 2) e 3) dovessero essere per forza o entrambi giusti o entrambi sbagliati.
Se sono le transazioni che contano, come dice FaSan, non dovrei poter spendere separatamente i 2 BTC dell'indirizzo A e i 3 BTC dell'indirizzo B, in quanto provenienti da una stessa transazione (ma questo sarebbe illogico, in quanto se l'indirizzo A e l'indirizzo B appartenessero a due persone diverse, una delle due potrebbe spendere i btc dell'altra). Da questa ovvia considerazione avevo erroneamente dedotto che "contassero" di più gli address che le transazioni.
Quindi riassumendo le singole TX sono le singole banconote e gli address sono le tasche, quindi:
nel caso 3) ho una banconota da 2 BTC e una da 3 BTC entrambe nella tasca A, e quindi posso spenderle separatamente
nel caso 2) ho una banconota da 2 BTC nella tasca A e 3 BTC nella tasca B (che sono il frutto però del cambio di un'unica banconota da 5 BTC, visto che provengono da un'unica transazione), e quindi posso ancora spenderli separatamente
Quindi più precisamente si potrebbe dire che una transazione non è una banconota, ma lo è l'accoppiata transazione-indirizzo di destinazione (mentre mi pare di aver capito che gli indirizzi d'origine non contino in questo tipo di ragionamento).
Così è tutto corretto?
(...)
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
Secondo me il 3) è sbagliato. Puoi spendere sia i 2 che i 4 proprio perche' di due transazioni differenti anche se dirette allo stesso indirizzo.
Esatto. Vedi le singole TX come singole banconote a cui chiaramente non puoi strappare pezzi, ma devi darla intera e ricevere un resto.
FaSan
(...)
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
Secondo me il 3) è sbagliato. Puoi spendere sia i 2 che i 4 proprio perche' di due transazioni differenti anche se dirette allo stesso indirizzo.
In ogni caso quando esegui una transazione l'indirizzo mittente viene interamente "svuotato", ed eventualmente (bad practice: address reusing, gli indirizzi BTC debbono essere pensati come "usa e getta") riempito di nuovo dal resto, ma se tu volessi effettuare una nuova transazione, non potresti usare gli stessi input della precedente.
Un input è composto, oltre che dalle sue componenti crittografiche e dalle istruzioni di esecuzione, dall'id transazione di provenienza dei fondi (è questa la cosa importante: ID transazione, non indirizzo).
All'interno della composizione di una transazione l'indirizzo sorgente non appare affatto!
Quindi, anche in presenza di "fondi sufficienti" (perché hai usato come change address della prima tx l'indirizzo stesso) la seconda tx non sarà valida, perché l'id transazione specificato nella precedente sarà già stato "impegnato" per il blocco successivo.
Un input è composto, oltre che dalle sue componenti crittografiche e dalle istruzioni di esecuzione, dall'id transazione di provenienza dei fondi (è questa la cosa importante: ID transazione, non indirizzo).
All'interno della composizione di una transazione l'indirizzo sorgente non appare affatto!
Quindi, anche in presenza di "fondi sufficienti" (perché hai usato come change address della prima tx l'indirizzo stesso) la seconda tx non sarà valida, perché l'id transazione specificato nella precedente sarà già stato "impegnato" per il blocco successivo.
Vediamo se ho capito bene il meccanismo transazione/indirizzi :
caso 1) se ho 2 BTC su un mio indirizzo A provenienti da una transazione x, allora devo spenderli tutti (non posso spenderne solo una parte, quindi si crea un resto)
caso 2) se ho 2 BTC sul mio indirizzo A e 3 BTC sul mio indirizzo B provenienti dalla stessa transazione x, allora se voglio spendere 2 BTC posso spendere i 2 BTC dell'indirizzo A senza toccare i 3 BTC dell'indirizzo B (non importa che tutti e 5 provengano dalla stessa transazione, sono in qualche modo "separati" dagli indirizzi su cui sono stati "indirizzati")
caso 3) se ho 2 BTC sul mio indirizzo A provenienti dalla transazione x e se ho altri 4 BTC sempre sul mio indirizzo A provenienti da un'altra transazione y, allora sono obbligato a spendere tutti i 6 BTC in blocco (non posso ad esempio spendere solo i 2 BTC provenienti dalla transazione x, dal momento che i 2 BTC della transazione x e i 4 BTC della transazione y sono "legati" perchè sono finiti nell'indirizzo A, quindi anche qui si crea un resto)
E' tutto giusto?
Diciamo che pero un retweet di Peter Todd può aiutare molto ad accorgersi "spontaneamente" della cosa 
Alla fine però, quando un piccolo script viene apprezzato e se ne parla in giro, penso sia la cosa migliore che un dev possa volere
Alla fine però, quando un piccolo script viene apprezzato e se ne parla in giro, penso sia la cosa migliore che un dev possa volere
Ad un mese dal rilascio, la rete si è *spontaneamente* resa conto di gangsta!
A parte che in questo thread e in firma non l'avevo pubblicizzato da nessuna parte, e non sono un grande frequentatore delle altre sezioni, dubito di avere anche solo un post in intl. sect nell'ultimo mese.
http://reddit.com/r/Bitcoin/comments/2z7y0d/gangsta_replace_by_fee_double_spend_tool/
https://twitter.com/petertoddbtc/status/577534426004897792
Sono un sacco divertito
<- io, adesso, molto divertito
A parte che in questo thread e in firma non l'avevo pubblicizzato da nessuna parte, e non sono un grande frequentatore delle altre sezioni, dubito di avere anche solo un post in intl. sect nell'ultimo mese.
http://reddit.com/r/Bitcoin/comments/2z7y0d/gangsta_replace_by_fee_double_spend_tool/
https://twitter.com/petertoddbtc/status/577534426004897792
Sono un sacco divertito
<- io, adesso, molto divertito Non mi quadra:
d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9 (sembra + corto ma dovrebbe avere 64 caratteri pure lui) comunque e' differente. L0ho calcolato sia con sha256sum da linea di comando che con una estensione per libre (open) office. In entrambi i casi ottengo lo stesso risultato differente da quello della pagina ...
Il secondo passaggio va fatto sui byte del primo risultato, non sulla sua rappresentazione esadecimale, che è quello che fai tu se usi sha256sum.Quote
Example of double-SHA-256 encoding of string "hello":
hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)
A me il secondo hash viene:hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)
d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9 (sembra + corto ma dovrebbe avere 64 caratteri pure lui) comunque e' differente. L0ho calcolato sia con sha256sum da linea di comando che con una estensione per libre (open) office. In entrambi i casi ottengo lo stesso risultato differente da quello della pagina ...
Come spiegato qui, se usi un tool che produce output binario potrai verificare che il risultato è corretto:
Code:
echo -n hello |openssl dgst -sha256 -binary |openssl dgst -sha256
In effetti ha senso, pirla io ... grazie.
Non mi quadra:
d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9 (sembra + corto ma dovrebbe avere 64 caratteri pure lui) comunque e' differente. L0ho calcolato sia con sha256sum da linea di comando che con una estensione per libre (open) office. In entrambi i casi ottengo lo stesso risultato differente da quello della pagina ...
Il secondo passaggio va fatto sui byte del primo risultato, non sulla sua rappresentazione esadecimale, che è quello che fai tu se usi sha256sum.Quote
Example of double-SHA-256 encoding of string "hello":
hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)
A me il secondo hash viene:hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)
d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9 (sembra + corto ma dovrebbe avere 64 caratteri pure lui) comunque e' differente. L0ho calcolato sia con sha256sum da linea di comando che con una estensione per libre (open) office. In entrambi i casi ottengo lo stesso risultato differente da quello della pagina ...
Come spiegato qui, se usi un tool che produce output binario potrai verificare che il risultato è corretto:
Code:
echo -n hello |openssl dgst -sha256 -binary |openssl dgst -sha256
bella li :-)
ottimo POC
ottimo POC
Questo è uno dei servizi più utili che ho visto tra quelli nati in seno alla community italiana - per non dire forse il più utile tra quelli non a scopo di lucro (e poi in realtà è merito solo tuo, quindi congratulazioni!).
E lascia un indirizzo che magari qualche tip la becchi per tutto questo lavoro!
E lascia un indirizzo che magari qualche tip la becchi per tutto questo lavoro!
Correranno ai ripari già dopo i primi double spend, non per questo o qualche altro thread.
Vige la regola del "chi primo arriva meglio alloggia".
Comunque, se qualcuno la pensasse come davvo (e ha senso, alla fine) e volesse segnalarmi in privato la sua esperienza, potrebbe essere d'aiuto alla prossima vittima.
Vige la regola del "chi primo arriva meglio alloggia".
Comunque, se qualcuno la pensasse come davvo (e ha senso, alla fine) e volesse segnalarmi in privato la sua esperienza, potrebbe essere d'aiuto alla prossima vittima.
Se qualcuno ha esperienza certa di ransomware che inviino la chiave su 0 confirmations per favore segnali di quale ransomware si tratta.
Fight fire with fire.
Fight fire with fire.
Eviterei magari di segnalarlo direttamente... vero che probabilmente non arriverà mai qui a leggerlo, ma altrettanto vero che BigG legge ed indicizza tutto...
Insomma non aiutiamo certa gente a raccogliere soldi in modo più sicuro segnalando che il suo sito ha problemi
Mi dicono che alcuni ransomware rilasciano chiavi di sblocco a 0 confirmations, ed è quindi possibile tentare un double spend e ottenere comunque lo sblocco dei files.
Inutile dire che se gangsta venisse usato in questo modo, sarebbe il miglior uso possibile che si possa farne. Chi avesse bisogno di usarlo per questa finalità mi contattasse per valutare insieme la costruzione di un double spend con alte possibilità di successo.
Non escludo però che da parte dei "gestori" del ransomware potrebbero esserci ritorsioni, come il non rilascio della chiave di sblocco, a fronte di un tentativo di double spend.
Se qualcuno ha esperienza certa di ransomware che inviino la chiave su 0 confirmations per favore segnali di quale ransomware si tratta.
Fight fire with fire.
Inutile dire che se gangsta venisse usato in questo modo, sarebbe il miglior uso possibile che si possa farne. Chi avesse bisogno di usarlo per questa finalità mi contattasse per valutare insieme la costruzione di un double spend con alte possibilità di successo.
Non escludo però che da parte dei "gestori" del ransomware potrebbero esserci ritorsioni, come il non rilascio della chiave di sblocco, a fronte di un tentativo di double spend.
Se qualcuno ha esperienza certa di ransomware che inviino la chiave su 0 confirmations per favore segnali di quale ransomware si tratta.
Fight fire with fire.
Alcuni double spend per cui ho fatto relay:
Il pattern più gettonato sembra essere quello di creare un diverso numero di transazioni a 0fee verso il proprio target (mi sembra gambling house) e poi invalidarle tutte mettendo tutti gli input spesi in un unico double spend, come ad esempio qui:
o qui:
etc..
Quote
2015-02-21 16:59:48 replacing tx 96520a173136b3e196c434e1c6330b2eee149c63195b21ab75f657608b703c04 with 62781c94dcc304bdafa642c29876aa16a6e3ec4b2c014f052fdb0d09a5bde590 for 0.00020001 BTC additional fees, -1 delta bytes
2015-02-21 17:06:24 replacing tx 10c5b12b968bb02f47663de36e8ad75bab6411a7f13cf418c9dced309973fda8 with 9cd2f25395f4c3b2db3b8b01ff5cf4cff5ebe21b47fcd35275c883beb131834e for 0.00011001 BTC additional fees, 0 delta bytes
2015-02-21 17:09:48 replacing tx 9cd2f25395f4c3b2db3b8b01ff5cf4cff5ebe21b47fcd35275c883beb131834e with 3d964da10dcfdf933bc6c4a204b7467c8ea66bb43ce74f44507bac5a29ad73ed for 0.00005 BTC additional fees, 0 delta bytes
2015-02-21 19:24:57 replacing tx 7ec83f314bc70bc85d4fd0daad11c443efab4e2e0846dcffcc41adf1c409423c with 6fdeda9f91210909406a6f24897d47437ebc685e71ae146a879d1ca983c5ad69 for 0.00009 BTC additional fees, -1 delta bytes
2015-02-21 19:25:00 replacing tx d6cf73f62cc794ec91bc457777f616b063516f049349a6a22d6470865dfc8fb8 with 1059758b7988e91221e5bee37b34e26e06e3b11d80d10c3e765c84ac1cae539a for 0.00009 BTC additional fees, 0 delta bytes
2015-02-21 20:45:03 replacing tx d0c0a4d20bb195b819367e4187bcd11dae92edcf7ca85cfd70f418a1620a546e with 52115b5ec88ae961047d0b68d6762f274dcf3ca988972e5cc5cfa2c66a676632 for 0.0001 BTC additional fees, 1 delta bytes
2015-02-21 22:17:49 replacing tx 18161c834e346f5341dda9bfd3a17f15587e65ba7262ea745429482fa453e764 with d7cc02e51708f54ab0ad0c97b90eab15d460203e36b60f655ef66a166b868bdb for 0.0001 BTC additional fees, 824 delta bytes
2015-02-21 23:05:34 replacing tx 877821618f16b9da639b6ac97a1bee544678c747eb34f7997d0d2263b513ad1b with 490f51d352f2c687cc42f9cee1124d23c2cbf2fb10981a20931b1e23a37b6ef3 for 0.00009999 BTC additional fees, 539 delta bytes
2015-02-22 04:24:43 replacing tx abf8b5d542f322364aed589fad5c1d0e73df80a7d170ae73b0e982d4213f33ce with 41e9becee390af68404c3d31b0557911e3ea211340f82711201d550b88031bdd for 0.0001 BTC additional fees, 0 delta bytes
2015-02-22 05:40:17 replacing tx cbe94636fc9c90e3237325303fe0d094b2998767851e733403360f94ea416da5 with 23dbcceba8b6cd63bdfc5cbe114a56f33e6245d74b5fdb5045a8a96dbaecf38c for 0.002 BTC additional fees, 150 delta bytes
2015-02-22 07:56:49 replacing tx ed1ebf6d3c7db1912041b03ef519376a9d1df7e31040ab00aecf2f03ca377b1d with 74aeed24dff684f1faeef50efcf7129352acddd680d090930f93c1d72d810920 for 0.0002 BTC additional fees, 1 delta bytes
2015-02-22 08:04:46 replacing tx b0f1e1a3473b0d4e10b7c271547066467bd41d2e62e86d8fbc58fd73234230f6 with c70384a6114025e9a3bee6f759f5932d5631f534887ec32d4d286a3b3ad7e9b7 for 0.00039 BTC additional fees, 180 delta bytes
2015-02-22 10:18:13 replacing tx 37d7a606f1504de5c197ce7d3d08584629942928f0351d67f63f6dd4665d26d1 with d0880b576cc6cc29241291d92dc1aa6d30abb784b1e0008f7b89c01f5a045855 for 0.00009999 BTC additional fees, 0 delta bytes
2015-02-22 11:43:43 replacing tx b7e8f7831e0b5c86e6ed4f915fe631668fc9e80a840b5aaae583be30d7902f40 with 40c56c04fdd83d8d7fb7afc90d31da4900036ddf822bc09a8fae957655c3e517 for 0.00001 BTC additional fees, 295 delta bytes
2015-02-22 11:46:31 replacing tx fe5fd26e25548e9e16bed3ea1ccfdddc4dbf1d95d269520ef6b4705ff5df3e66 with 8d8bc27f5ec9187bfd8b5059ae4a1e52aa6e92f65127106d0f0814c4541817a6 for 0.0001 BTC additional fees, 1 delta bytes
2015-02-22 11:53:04 replacing tx 264b1800d41ea05cf10b9828dfa6fc96091cd0255e7b6ed659e1c1d81084a498 with e4b168c1d921f87c71d50e027accb23243b156b6ccad78f2193c92404de8d427 for 0.00010314 BTC additional fees, -32 delta bytes
2015-02-22 12:29:43 replacing tx f10ed9456c217f9b7dce88b5943681cf887c82192382b1511fa5b5a956485a4e with 567313662927b29abe59aa9e4c5123500a1f4e3526e0a5b3545dc47be39c3692 for 0.00001 BTC additional fees, 35 delta bytes
2015-02-22 12:48:25 replacing tx 39097df9e3c022f1d92aee08f85afa8e5a84fcc680b4987b8da614a7375145b0 with dd5df6d2b246e2b66de8762be701de37c9a0542de472a52c96483a97e3be99dc for 0.00008594 BTC additional fees, 366 delta bytes
2015-02-22 13:06:54 replacing tx dddd8a7eae2eeb46bc361517d7e55ee9e851e65585161bc6fc736df3a92ed728 with d31991825dd82ba62b23bab890cc999bc2c142266045216d9304c4ec2c98ab9b for 0.00039 BTC additional fees, 181 delta bytes
2015-02-22 14:42:14 replacing tx 8ca0073193846d645164abcae48891fca71278866545e12106310d7dbf332ae0 with 4f52609ea359858bd2df62a292dfa328dc53e713ed33e126614634e46e4b2f44 for 0.00049 BTC additional fees, -31 delta bytes
2015-02-22 15:08:51 replacing tx 8cd02fe75efb33fecdfe468e3219bde73c599a54aeba71fc804d9b75173ec4b3 with 8a27ddd50809ec7d24ba470aa38a9752d3b8bd07832204448380929ffb64ec4d for 0.0003 BTC additional fees, 0 delta bytes
2015-02-22 15:11:54 replacing tx 1abc020b6825fb9dad489aea015578d2d8edf531ac3bbe9bdcf1ba430dfae015 with 978c1be3d357c9341dfce86332df597cd983a97246d650470ef2c650580d12bc for 0.00009 BTC additional fees, 0 delta bytes
2015-02-22 15:18:37 replacing tx a6fee0343c5ba6d078c6131346b734e44d5452543eee8371ca69751f40f4177e with 2144b39cf65f977543ea4964bd8228d28a5c2f012933dbdbb6755eaccc41e5dd for 0.00009 BTC additional fees, -1 delta bytes
2015-02-22 19:01:26 replacing tx 7f0b97ac3a754629460b948a933d655322dce54f3463c57a555a7fba2e4757f1 with 9c99614120349c3f8c74b42534103d08855ffbe1f07f1dfa7804ba1e9e1d8a1b for 0.00009 BTC additional fees, 1613 delta bytes
2015-02-22 19:18:41 replacing tx 4bef39117bffde1652b1dbeade3a8b788f3d5622b8f4fd152d7bd28478b23f82 with 349df62c1a1c930541f46a5cfdf88c6d991ce4aed451b88e5b8bc4f789f5066a for 0.0001 BTC additional fees, 434 delta bytes
2015-02-22 19:18:41 replacing tx 49ec7695acb27dd0b035ec31b6457cffddf4680a9a2060e3e6ed1e45bb434dd3 with 349df62c1a1c930541f46a5cfdf88c6d991ce4aed451b88e5b8bc4f789f5066a for 0.0001 BTC additional fees, 434 delta bytes
2015-02-22 19:49:42 replacing tx aa7cc0ba9ffc1cc1ddef9b53cd9676a65250dc67245b99edbff6d2ae0e0a7846 with 052ec690cb3b84a0dc4a8ea584fad3f4bc4ecc99bac78e24fe85c84c524f6e20 for 0.00009 BTC additional fees, -4 delta bytes
2015-02-22 20:21:22 replacing tx fa108eeedb69d269516b57ebd19718d6492c574b18a91a48058e08c1579ed29e with 0a341f3e802787e67592f4933160361918f7e4e362c098d81cb8b10ba42b8e7d for 0.00009993 BTC additional fees, 2 delta bytes
2015-02-22 20:47:28 replacing tx b798c05c1edab29b4f26c15cd25f39ac6498f2f758c4e00a68d3b41ad2f0ad34 with 4338766d46030bc25b8311b03c7d555e39ef87d942f1bcd9ea831e27b09d0ddc for 0.00069 BTC additional fees, 444 delta bytes
2015-02-22 21:30:39 replacing tx c442e06a93ac616e994cce62a579ff0ad841746066ab7fd8bf67a8359f72a77a with c768a799f397762fd146cd65a89b872d01f05ff5e6c0d848a3a803036e9e719c for 0.00002 BTC additional fees, 34 delta bytes
2015-02-22 23:20:19 replacing tx db51721825558b2bc9af58a75a0ba2d6178c0931c5bb29a29e3101ea8a648321 with d73451b0404a50dc83661694ccd89535f2b752a8ec9bbe6d78a6304ebaab9035 for 0.000149 BTC additional fees, -1 delta bytes
2015-02-23 01:05:03 replacing tx 6b0c96fe020eb58e4c952185f9edee04c2fc3c40a22fc70f72c37c6b4cf3ac90 with 661d1b261724eff6150814bac83769d0f36cafc2a01c11f0e33e098c1f18795d for 0.000009 BTC additional fees, -1 delta bytes
2015-02-23 08:09:10 replacing tx 787751d70881ff6b8390e9ed0a491e4d1d7fdf8dd431b1b5e51a19e474db29e7 with 20230f11c033e340f380143b1c925b12d55da7d05adf5d04f458b651172427ce for 0.00009 BTC additional fees, -1 delta bytes
2015-02-23 08:11:06 replacing tx 818ab960aced3e1dc82642c2f6632395aa54f669aa407cc548a7f47574aa7af5 with a748e2598bcc61dd363e788a256c29aa1f244d31b5e33f33a23b654e847834c2 for 0.00207 BTC additional fees, 1348 delta bytes
2015-02-23 09:16:27 replacing tx 16b35d02a6d75d1056d48ad47a278b0d6110e48de1199d5dc5c0865019a1ce28 with e835f16316a96b76d1a98d014251a47ac0508b17d306e53def40d26db5d90801 for 0.0001 BTC additional fees, 2063 delta bytes
2015-02-23 09:16:27 replacing tx b461bd721a821d6ae7f6aad5224e7a214328fa73636829134547390102fef5e0 with e835f16316a96b76d1a98d014251a47ac0508b17d306e53def40d26db5d90801 for 0.0001 BTC additional fees, 2063 delta bytes
2015-02-23 09:16:27 replacing tx 0ba5f78bac01c3d5b3d42cbfe4b853a3e15176c95f45bab8ebf05fe1834056d5 with e835f16316a96b76d1a98d014251a47ac0508b17d306e53def40d26db5d90801 for 0.0001 BTC additional fees, 2063 delta bytes
2015-02-23 10:39:58 replacing tx 4d8e5e7d1c76ce0f8a7c9fd4f82822272df1f3867d5c8486fc94a48cd3d3837d with b57debfbf3dc76fe7679c2e7f12f42b0bebca20cd3f0c903930e9a5baaad6790 for 0.00029 BTC additional fees, 445 delta bytes
2015-02-23 10:43:36 replacing tx de6cf5e0d0f2e71feca1449afdc700a27813d26aef1f2c616c1244cfb1cc91fe with 43cd49e55eac9cf44c8fe788897406fec048daafc0d7228ffae66aaea62ab2ab for 0.0004999 BTC additional fees, 3372 delta bytes
2015-02-23 10:53:39 replacing tx 9040dc50441731f53e383b89ebe872c91241ccdfd208b27697e0d44dbc1e7b7a with 81be98b5f816bfaa0f37874ddb095bcef45a8051419dcb1d9a75e54bc4eb3ed7 for 0.0001 BTC additional fees, 326 delta bytes
2015-02-23 13:03:06 replacing tx 56689c7d449a2d843324bd993d0e0decb9c6498727f65130394192c6059b3e11 with 0b0988a6f1457070b12944c55ab7339d91b39bb6188f98e4dc6068b86ae4e2eb for 0.0001 BTC additional fees, 1 delta bytes
2015-02-23 15:21:17 replacing tx c7a8defd93deefc907ffc1ffdde1fa3d4aebae778c2fee5dbe17fd9ba7976b35 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 73226c1e56606ff109c13723576617f1484f0af992814e66997b74f9e7e3916e with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 9c1b747d341eecaab7abc990b32eb01ca16193e098aa67533151d9abd30ff338 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 9caee64d69df493367934c5af44b13ef8cbf003277643f20b314ef6f4194cae4 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 18:48:03 replacing tx 5fda01575acbf68159bb2e675d6480443cfd7934d0e49ade51b13ca0b3fb80e3 with fbd6cc97973404f28f324c45def43e88341435ad5c70b1d548de72865e9bc2c4 for 0.0002 BTC additional fees, -22005 delta bytes
2015-02-23 18:48:03 replacing tx ed54e478884181f11bdc217caf0d5e346297d13bf4fdcece7580b29e2ef72d10 with fbd6cc97973404f28f324c45def43e88341435ad5c70b1d548de72865e9bc2c4 for 0.0002 BTC additional fees, -22005 delta bytes
2015-02-23 19:51:01 replacing tx 3656372e56a6fcb8b72bca04d5b65f9fb07a83e5cc94799b891db2df774c17bb with e5f2cceecd617f696d297ac1700c0f38f3de8e2a6b51f4d00c5aab3878321945 for 0.0002 BTC additional fees, 443 delta bytes
2015-02-23 20:27:35 replacing tx 03ba172bfdbc4d9fd8a1dac9bcd4314865cff45d59671d3424b0f6c4ab843e4f with 334b8593261ec753205f94b57ad0398d4251fa2551f83d047a576a4db6d7d4cd for 0.0001 BTC additional fees, 0 delta bytes
2015-02-23 20:33:02 replacing tx 933b97714e57f5bdc95ea938de72ae9aada64771ae3c557800cf08dbc6329b95 with 927b767379c2e3ff5b42e5808c47ee136423ad14ddea85f9bfc03caa7cd622e1 for 0.0001 BTC additional fees, 215 delta bytes
2015-02-23 23:46:59 replacing tx 19e29d666727445647042f005e139d2619acb695aa4e567ffa4aa363e46d1f8e with f37bd3275cf25fa54dbb6239b0476f095f52b36a8ab111bb43a599f93e0997fa for 0.0001 BTC additional fees, -39 delta bytes
2015-02-23 23:46:59 replacing tx fcca373a6c2ef173659ef3caa42be123ba056480575db1004beea9be6e94c8a9 with f37bd3275cf25fa54dbb6239b0476f095f52b36a8ab111bb43a599f93e0997fa for 0.0001 BTC additional fees, -39 delta bytes
2015-02-24 00:05:21 replacing tx 347e6ddc841170b8258bd1384d1e6af4941ffc68c84065047c93f58efd1623c6 with 343f48ad2dbf9e494d9140a853bca816edf902c6ab93a4f44497cb758087cabb for 0.00001 BTC additional fees, -1 delta bytes
2015-02-24 00:23:30 replacing tx e0c52fb8880e3613b056a105dee40b99706d9823731cbd98f92ed5354b13d69b with 2effc9c3cf1337911856af451359546df3c3b9e0e06e36e47c9a37d12c2abc9d for 0.00009 BTC additional fees, 302 delta bytes
2015-02-24 02:33:57 replacing tx 72a46b6de19357218a16089eee99230c2d57258fd18f41363933658459c77214 with c250a2970f286929964504268bac417eda1b6f6d815f6fd81bc28ee8814041fe for 0.0001 BTC additional fees, 706 delta bytes
2015-02-24 04:11:38 replacing tx 2aadb23e327fffea09f8eb350c0d73eead75c92696da5d61ca3dd440def09b4f with 6aed7914bfb8d26fc5e93d4b2f069fa601c7dcd9f082e6ae4c45eda234eddeb0 for 0.000199 BTC additional fees, 3 delta bytes
2015-02-24 05:13:34 replacing tx 55c87182da3f0e7e71aeadb120fc2a3125102d40f73062e986bf0e6d043c37cb with 9e91e8724a769ff52b12c82fac0a659f52c1ac4258103e1f1160109202618915 for 0.00059 BTC additional fees, 713 delta bytes
2015-02-24 07:32:35 replacing tx 86d055746bbf7bb40c8be57763675dcde8a174eb4381a6e5d1e30a7d3818a281 with c7665a93bb9e66b24b52e9d086bb5980d3fe2014078a95a94c3fc728f4282e45 for 0.0001 BTC additional fees, -1 delta bytes
2015-02-24 07:56:57 replacing tx 8217ccf238f39e0f3085f8af679bf4f0ed884cbc4f0ac50234716d8f2d41b785 with cb5a8a7e0a299a8ffd8a75b548642436f18454eb81c9e9ed4e4924f8c427d5be for 0.000499 BTC additional fees, 1404 delta bytes
2015-02-24 11:03:27 replacing tx 0e36828314b74ef47611e6b68f15f9da80121f74e2ef4ce02b0ee133ebfa2135 with cc16d8226793867338780734fbdfdbf741cafd0668ee8b4226097b1d08ea0496 for 0.00009 BTC additional fees, -4754 delta bytes
2015-02-24 12:27:21 replacing tx be37dfa360a26b8fc09daf2c5fa475acd677fde474d8fad1155aa573998d1cd5 with f6be5904950ceb2107fb2d61d3a616102c87507f578e6122015c06649b596e49 for 0.00001 BTC additional fees, 114 delta bytes
2015-02-24 14:03:03 replacing tx 5a541f15f895568fb8aa3aab4b7e8c381f6fd480824acc39074ec4e8a5812636 with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:03:03 replacing tx 8b415ac8104151c77512c30b793250ee9a48eaf993e8d523a20f38e0e6555f30 with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:03:03 replacing tx 60ccc56361a37a038509f47e050cfe732f5d40805e75a9792a329627d8648ece with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:18:04 replacing tx e1f5eab3af756f4591502e4c3d473a8c8871a67e2064b6f857507d517cf1406d with 98585bfdeb969d032a38624dfecf1496cf8e65a0c6a4f2660cad2b517f1c44b0 for 0.0001 BTC additional fees, 148 delta bytes
2015-02-24 22:24:32 replacing tx 5838cb6ebe43ab1dfc70b4dfa1f9a91a8ad67e7dbf2311999ffc4344e234a771 with 16009d95214032ac1e6f67b453dc1ccc8157f9de9d539f6918b19b9c98d36eda for 0.0002 BTC additional fees, 182 delta bytes
2015-02-25 01:06:29 replacing tx 21f0da8c203f30f0773d4bf9f307caab058ff821937c7c9ca283a68e4e341a60 with c806ef5dd167b888d74813f33c15850e62686b13f8a4c733dfcfb7164d3ac9ef for 0.0009 BTC additional fees, 0 delta bytes
2015-02-25 01:57:40 replacing tx 7b76fd4d3ca0b6564a2bb9bd1e762e148ad259f93d8be7c38d594f7406ba514f with fee5ae2043667236df93a6d57f739e4ff13a7f1b308cbcea4cfcbcf968902d44 for 0.0001 BTC additional fees, 149 delta bytes
2015-02-25 02:29:34 replacing tx 303a20493c92a87956f12764446554df5c205a5c3752a03eacefb43e146f46bb with 0b6c3ac0bf92646477577018a345e7d5f29240069ddb326a9874e42c3f86ef6e for 0.0002 BTC additional fees, 0 delta bytes
2015-02-25 04:37:06 replacing tx 986533577ab6a93bf4c5cfbc41e5ff0bd7fea532f54d504b27afa095acc200a9 with 5557bab846acf7ff0e553c68345b44812d7154ab464fd6548feb3bf9a94e0d24 for 0.00012241 BTC additional fees, -39 delta bytes
2015-02-25 06:08:27 replacing tx a0be6b95f944a051a7f1a23c3aa60ef00e92bcdce2bfb45c7caf465d5eb04a92 with 7f8c495e444ddc263ec96ec5724c12e04c0830e525e31eb1f89d8d544c7419d8 for 0.0001 BTC additional fees, 1513 delta bytes
2015-02-21 17:06:24 replacing tx 10c5b12b968bb02f47663de36e8ad75bab6411a7f13cf418c9dced309973fda8 with 9cd2f25395f4c3b2db3b8b01ff5cf4cff5ebe21b47fcd35275c883beb131834e for 0.00011001 BTC additional fees, 0 delta bytes
2015-02-21 17:09:48 replacing tx 9cd2f25395f4c3b2db3b8b01ff5cf4cff5ebe21b47fcd35275c883beb131834e with 3d964da10dcfdf933bc6c4a204b7467c8ea66bb43ce74f44507bac5a29ad73ed for 0.00005 BTC additional fees, 0 delta bytes
2015-02-21 19:24:57 replacing tx 7ec83f314bc70bc85d4fd0daad11c443efab4e2e0846dcffcc41adf1c409423c with 6fdeda9f91210909406a6f24897d47437ebc685e71ae146a879d1ca983c5ad69 for 0.00009 BTC additional fees, -1 delta bytes
2015-02-21 19:25:00 replacing tx d6cf73f62cc794ec91bc457777f616b063516f049349a6a22d6470865dfc8fb8 with 1059758b7988e91221e5bee37b34e26e06e3b11d80d10c3e765c84ac1cae539a for 0.00009 BTC additional fees, 0 delta bytes
2015-02-21 20:45:03 replacing tx d0c0a4d20bb195b819367e4187bcd11dae92edcf7ca85cfd70f418a1620a546e with 52115b5ec88ae961047d0b68d6762f274dcf3ca988972e5cc5cfa2c66a676632 for 0.0001 BTC additional fees, 1 delta bytes
2015-02-21 22:17:49 replacing tx 18161c834e346f5341dda9bfd3a17f15587e65ba7262ea745429482fa453e764 with d7cc02e51708f54ab0ad0c97b90eab15d460203e36b60f655ef66a166b868bdb for 0.0001 BTC additional fees, 824 delta bytes
2015-02-21 23:05:34 replacing tx 877821618f16b9da639b6ac97a1bee544678c747eb34f7997d0d2263b513ad1b with 490f51d352f2c687cc42f9cee1124d23c2cbf2fb10981a20931b1e23a37b6ef3 for 0.00009999 BTC additional fees, 539 delta bytes
2015-02-22 04:24:43 replacing tx abf8b5d542f322364aed589fad5c1d0e73df80a7d170ae73b0e982d4213f33ce with 41e9becee390af68404c3d31b0557911e3ea211340f82711201d550b88031bdd for 0.0001 BTC additional fees, 0 delta bytes
2015-02-22 05:40:17 replacing tx cbe94636fc9c90e3237325303fe0d094b2998767851e733403360f94ea416da5 with 23dbcceba8b6cd63bdfc5cbe114a56f33e6245d74b5fdb5045a8a96dbaecf38c for 0.002 BTC additional fees, 150 delta bytes
2015-02-22 07:56:49 replacing tx ed1ebf6d3c7db1912041b03ef519376a9d1df7e31040ab00aecf2f03ca377b1d with 74aeed24dff684f1faeef50efcf7129352acddd680d090930f93c1d72d810920 for 0.0002 BTC additional fees, 1 delta bytes
2015-02-22 08:04:46 replacing tx b0f1e1a3473b0d4e10b7c271547066467bd41d2e62e86d8fbc58fd73234230f6 with c70384a6114025e9a3bee6f759f5932d5631f534887ec32d4d286a3b3ad7e9b7 for 0.00039 BTC additional fees, 180 delta bytes
2015-02-22 10:18:13 replacing tx 37d7a606f1504de5c197ce7d3d08584629942928f0351d67f63f6dd4665d26d1 with d0880b576cc6cc29241291d92dc1aa6d30abb784b1e0008f7b89c01f5a045855 for 0.00009999 BTC additional fees, 0 delta bytes
2015-02-22 11:43:43 replacing tx b7e8f7831e0b5c86e6ed4f915fe631668fc9e80a840b5aaae583be30d7902f40 with 40c56c04fdd83d8d7fb7afc90d31da4900036ddf822bc09a8fae957655c3e517 for 0.00001 BTC additional fees, 295 delta bytes
2015-02-22 11:46:31 replacing tx fe5fd26e25548e9e16bed3ea1ccfdddc4dbf1d95d269520ef6b4705ff5df3e66 with 8d8bc27f5ec9187bfd8b5059ae4a1e52aa6e92f65127106d0f0814c4541817a6 for 0.0001 BTC additional fees, 1 delta bytes
2015-02-22 11:53:04 replacing tx 264b1800d41ea05cf10b9828dfa6fc96091cd0255e7b6ed659e1c1d81084a498 with e4b168c1d921f87c71d50e027accb23243b156b6ccad78f2193c92404de8d427 for 0.00010314 BTC additional fees, -32 delta bytes
2015-02-22 12:29:43 replacing tx f10ed9456c217f9b7dce88b5943681cf887c82192382b1511fa5b5a956485a4e with 567313662927b29abe59aa9e4c5123500a1f4e3526e0a5b3545dc47be39c3692 for 0.00001 BTC additional fees, 35 delta bytes
2015-02-22 12:48:25 replacing tx 39097df9e3c022f1d92aee08f85afa8e5a84fcc680b4987b8da614a7375145b0 with dd5df6d2b246e2b66de8762be701de37c9a0542de472a52c96483a97e3be99dc for 0.00008594 BTC additional fees, 366 delta bytes
2015-02-22 13:06:54 replacing tx dddd8a7eae2eeb46bc361517d7e55ee9e851e65585161bc6fc736df3a92ed728 with d31991825dd82ba62b23bab890cc999bc2c142266045216d9304c4ec2c98ab9b for 0.00039 BTC additional fees, 181 delta bytes
2015-02-22 14:42:14 replacing tx 8ca0073193846d645164abcae48891fca71278866545e12106310d7dbf332ae0 with 4f52609ea359858bd2df62a292dfa328dc53e713ed33e126614634e46e4b2f44 for 0.00049 BTC additional fees, -31 delta bytes
2015-02-22 15:08:51 replacing tx 8cd02fe75efb33fecdfe468e3219bde73c599a54aeba71fc804d9b75173ec4b3 with 8a27ddd50809ec7d24ba470aa38a9752d3b8bd07832204448380929ffb64ec4d for 0.0003 BTC additional fees, 0 delta bytes
2015-02-22 15:11:54 replacing tx 1abc020b6825fb9dad489aea015578d2d8edf531ac3bbe9bdcf1ba430dfae015 with 978c1be3d357c9341dfce86332df597cd983a97246d650470ef2c650580d12bc for 0.00009 BTC additional fees, 0 delta bytes
2015-02-22 15:18:37 replacing tx a6fee0343c5ba6d078c6131346b734e44d5452543eee8371ca69751f40f4177e with 2144b39cf65f977543ea4964bd8228d28a5c2f012933dbdbb6755eaccc41e5dd for 0.00009 BTC additional fees, -1 delta bytes
2015-02-22 19:01:26 replacing tx 7f0b97ac3a754629460b948a933d655322dce54f3463c57a555a7fba2e4757f1 with 9c99614120349c3f8c74b42534103d08855ffbe1f07f1dfa7804ba1e9e1d8a1b for 0.00009 BTC additional fees, 1613 delta bytes
2015-02-22 19:18:41 replacing tx 4bef39117bffde1652b1dbeade3a8b788f3d5622b8f4fd152d7bd28478b23f82 with 349df62c1a1c930541f46a5cfdf88c6d991ce4aed451b88e5b8bc4f789f5066a for 0.0001 BTC additional fees, 434 delta bytes
2015-02-22 19:18:41 replacing tx 49ec7695acb27dd0b035ec31b6457cffddf4680a9a2060e3e6ed1e45bb434dd3 with 349df62c1a1c930541f46a5cfdf88c6d991ce4aed451b88e5b8bc4f789f5066a for 0.0001 BTC additional fees, 434 delta bytes
2015-02-22 19:49:42 replacing tx aa7cc0ba9ffc1cc1ddef9b53cd9676a65250dc67245b99edbff6d2ae0e0a7846 with 052ec690cb3b84a0dc4a8ea584fad3f4bc4ecc99bac78e24fe85c84c524f6e20 for 0.00009 BTC additional fees, -4 delta bytes
2015-02-22 20:21:22 replacing tx fa108eeedb69d269516b57ebd19718d6492c574b18a91a48058e08c1579ed29e with 0a341f3e802787e67592f4933160361918f7e4e362c098d81cb8b10ba42b8e7d for 0.00009993 BTC additional fees, 2 delta bytes
2015-02-22 20:47:28 replacing tx b798c05c1edab29b4f26c15cd25f39ac6498f2f758c4e00a68d3b41ad2f0ad34 with 4338766d46030bc25b8311b03c7d555e39ef87d942f1bcd9ea831e27b09d0ddc for 0.00069 BTC additional fees, 444 delta bytes
2015-02-22 21:30:39 replacing tx c442e06a93ac616e994cce62a579ff0ad841746066ab7fd8bf67a8359f72a77a with c768a799f397762fd146cd65a89b872d01f05ff5e6c0d848a3a803036e9e719c for 0.00002 BTC additional fees, 34 delta bytes
2015-02-22 23:20:19 replacing tx db51721825558b2bc9af58a75a0ba2d6178c0931c5bb29a29e3101ea8a648321 with d73451b0404a50dc83661694ccd89535f2b752a8ec9bbe6d78a6304ebaab9035 for 0.000149 BTC additional fees, -1 delta bytes
2015-02-23 01:05:03 replacing tx 6b0c96fe020eb58e4c952185f9edee04c2fc3c40a22fc70f72c37c6b4cf3ac90 with 661d1b261724eff6150814bac83769d0f36cafc2a01c11f0e33e098c1f18795d for 0.000009 BTC additional fees, -1 delta bytes
2015-02-23 08:09:10 replacing tx 787751d70881ff6b8390e9ed0a491e4d1d7fdf8dd431b1b5e51a19e474db29e7 with 20230f11c033e340f380143b1c925b12d55da7d05adf5d04f458b651172427ce for 0.00009 BTC additional fees, -1 delta bytes
2015-02-23 08:11:06 replacing tx 818ab960aced3e1dc82642c2f6632395aa54f669aa407cc548a7f47574aa7af5 with a748e2598bcc61dd363e788a256c29aa1f244d31b5e33f33a23b654e847834c2 for 0.00207 BTC additional fees, 1348 delta bytes
2015-02-23 09:16:27 replacing tx 16b35d02a6d75d1056d48ad47a278b0d6110e48de1199d5dc5c0865019a1ce28 with e835f16316a96b76d1a98d014251a47ac0508b17d306e53def40d26db5d90801 for 0.0001 BTC additional fees, 2063 delta bytes
2015-02-23 09:16:27 replacing tx b461bd721a821d6ae7f6aad5224e7a214328fa73636829134547390102fef5e0 with e835f16316a96b76d1a98d014251a47ac0508b17d306e53def40d26db5d90801 for 0.0001 BTC additional fees, 2063 delta bytes
2015-02-23 09:16:27 replacing tx 0ba5f78bac01c3d5b3d42cbfe4b853a3e15176c95f45bab8ebf05fe1834056d5 with e835f16316a96b76d1a98d014251a47ac0508b17d306e53def40d26db5d90801 for 0.0001 BTC additional fees, 2063 delta bytes
2015-02-23 10:39:58 replacing tx 4d8e5e7d1c76ce0f8a7c9fd4f82822272df1f3867d5c8486fc94a48cd3d3837d with b57debfbf3dc76fe7679c2e7f12f42b0bebca20cd3f0c903930e9a5baaad6790 for 0.00029 BTC additional fees, 445 delta bytes
2015-02-23 10:43:36 replacing tx de6cf5e0d0f2e71feca1449afdc700a27813d26aef1f2c616c1244cfb1cc91fe with 43cd49e55eac9cf44c8fe788897406fec048daafc0d7228ffae66aaea62ab2ab for 0.0004999 BTC additional fees, 3372 delta bytes
2015-02-23 10:53:39 replacing tx 9040dc50441731f53e383b89ebe872c91241ccdfd208b27697e0d44dbc1e7b7a with 81be98b5f816bfaa0f37874ddb095bcef45a8051419dcb1d9a75e54bc4eb3ed7 for 0.0001 BTC additional fees, 326 delta bytes
2015-02-23 13:03:06 replacing tx 56689c7d449a2d843324bd993d0e0decb9c6498727f65130394192c6059b3e11 with 0b0988a6f1457070b12944c55ab7339d91b39bb6188f98e4dc6068b86ae4e2eb for 0.0001 BTC additional fees, 1 delta bytes
2015-02-23 15:21:17 replacing tx c7a8defd93deefc907ffc1ffdde1fa3d4aebae778c2fee5dbe17fd9ba7976b35 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 73226c1e56606ff109c13723576617f1484f0af992814e66997b74f9e7e3916e with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 9c1b747d341eecaab7abc990b32eb01ca16193e098aa67533151d9abd30ff338 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 9caee64d69df493367934c5af44b13ef8cbf003277643f20b314ef6f4194cae4 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 18:48:03 replacing tx 5fda01575acbf68159bb2e675d6480443cfd7934d0e49ade51b13ca0b3fb80e3 with fbd6cc97973404f28f324c45def43e88341435ad5c70b1d548de72865e9bc2c4 for 0.0002 BTC additional fees, -22005 delta bytes
2015-02-23 18:48:03 replacing tx ed54e478884181f11bdc217caf0d5e346297d13bf4fdcece7580b29e2ef72d10 with fbd6cc97973404f28f324c45def43e88341435ad5c70b1d548de72865e9bc2c4 for 0.0002 BTC additional fees, -22005 delta bytes
2015-02-23 19:51:01 replacing tx 3656372e56a6fcb8b72bca04d5b65f9fb07a83e5cc94799b891db2df774c17bb with e5f2cceecd617f696d297ac1700c0f38f3de8e2a6b51f4d00c5aab3878321945 for 0.0002 BTC additional fees, 443 delta bytes
2015-02-23 20:27:35 replacing tx 03ba172bfdbc4d9fd8a1dac9bcd4314865cff45d59671d3424b0f6c4ab843e4f with 334b8593261ec753205f94b57ad0398d4251fa2551f83d047a576a4db6d7d4cd for 0.0001 BTC additional fees, 0 delta bytes
2015-02-23 20:33:02 replacing tx 933b97714e57f5bdc95ea938de72ae9aada64771ae3c557800cf08dbc6329b95 with 927b767379c2e3ff5b42e5808c47ee136423ad14ddea85f9bfc03caa7cd622e1 for 0.0001 BTC additional fees, 215 delta bytes
2015-02-23 23:46:59 replacing tx 19e29d666727445647042f005e139d2619acb695aa4e567ffa4aa363e46d1f8e with f37bd3275cf25fa54dbb6239b0476f095f52b36a8ab111bb43a599f93e0997fa for 0.0001 BTC additional fees, -39 delta bytes
2015-02-23 23:46:59 replacing tx fcca373a6c2ef173659ef3caa42be123ba056480575db1004beea9be6e94c8a9 with f37bd3275cf25fa54dbb6239b0476f095f52b36a8ab111bb43a599f93e0997fa for 0.0001 BTC additional fees, -39 delta bytes
2015-02-24 00:05:21 replacing tx 347e6ddc841170b8258bd1384d1e6af4941ffc68c84065047c93f58efd1623c6 with 343f48ad2dbf9e494d9140a853bca816edf902c6ab93a4f44497cb758087cabb for 0.00001 BTC additional fees, -1 delta bytes
2015-02-24 00:23:30 replacing tx e0c52fb8880e3613b056a105dee40b99706d9823731cbd98f92ed5354b13d69b with 2effc9c3cf1337911856af451359546df3c3b9e0e06e36e47c9a37d12c2abc9d for 0.00009 BTC additional fees, 302 delta bytes
2015-02-24 02:33:57 replacing tx 72a46b6de19357218a16089eee99230c2d57258fd18f41363933658459c77214 with c250a2970f286929964504268bac417eda1b6f6d815f6fd81bc28ee8814041fe for 0.0001 BTC additional fees, 706 delta bytes
2015-02-24 04:11:38 replacing tx 2aadb23e327fffea09f8eb350c0d73eead75c92696da5d61ca3dd440def09b4f with 6aed7914bfb8d26fc5e93d4b2f069fa601c7dcd9f082e6ae4c45eda234eddeb0 for 0.000199 BTC additional fees, 3 delta bytes
2015-02-24 05:13:34 replacing tx 55c87182da3f0e7e71aeadb120fc2a3125102d40f73062e986bf0e6d043c37cb with 9e91e8724a769ff52b12c82fac0a659f52c1ac4258103e1f1160109202618915 for 0.00059 BTC additional fees, 713 delta bytes
2015-02-24 07:32:35 replacing tx 86d055746bbf7bb40c8be57763675dcde8a174eb4381a6e5d1e30a7d3818a281 with c7665a93bb9e66b24b52e9d086bb5980d3fe2014078a95a94c3fc728f4282e45 for 0.0001 BTC additional fees, -1 delta bytes
2015-02-24 07:56:57 replacing tx 8217ccf238f39e0f3085f8af679bf4f0ed884cbc4f0ac50234716d8f2d41b785 with cb5a8a7e0a299a8ffd8a75b548642436f18454eb81c9e9ed4e4924f8c427d5be for 0.000499 BTC additional fees, 1404 delta bytes
2015-02-24 11:03:27 replacing tx 0e36828314b74ef47611e6b68f15f9da80121f74e2ef4ce02b0ee133ebfa2135 with cc16d8226793867338780734fbdfdbf741cafd0668ee8b4226097b1d08ea0496 for 0.00009 BTC additional fees, -4754 delta bytes
2015-02-24 12:27:21 replacing tx be37dfa360a26b8fc09daf2c5fa475acd677fde474d8fad1155aa573998d1cd5 with f6be5904950ceb2107fb2d61d3a616102c87507f578e6122015c06649b596e49 for 0.00001 BTC additional fees, 114 delta bytes
2015-02-24 14:03:03 replacing tx 5a541f15f895568fb8aa3aab4b7e8c381f6fd480824acc39074ec4e8a5812636 with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:03:03 replacing tx 8b415ac8104151c77512c30b793250ee9a48eaf993e8d523a20f38e0e6555f30 with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:03:03 replacing tx 60ccc56361a37a038509f47e050cfe732f5d40805e75a9792a329627d8648ece with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:18:04 replacing tx e1f5eab3af756f4591502e4c3d473a8c8871a67e2064b6f857507d517cf1406d with 98585bfdeb969d032a38624dfecf1496cf8e65a0c6a4f2660cad2b517f1c44b0 for 0.0001 BTC additional fees, 148 delta bytes
2015-02-24 22:24:32 replacing tx 5838cb6ebe43ab1dfc70b4dfa1f9a91a8ad67e7dbf2311999ffc4344e234a771 with 16009d95214032ac1e6f67b453dc1ccc8157f9de9d539f6918b19b9c98d36eda for 0.0002 BTC additional fees, 182 delta bytes
2015-02-25 01:06:29 replacing tx 21f0da8c203f30f0773d4bf9f307caab058ff821937c7c9ca283a68e4e341a60 with c806ef5dd167b888d74813f33c15850e62686b13f8a4c733dfcfb7164d3ac9ef for 0.0009 BTC additional fees, 0 delta bytes
2015-02-25 01:57:40 replacing tx 7b76fd4d3ca0b6564a2bb9bd1e762e148ad259f93d8be7c38d594f7406ba514f with fee5ae2043667236df93a6d57f739e4ff13a7f1b308cbcea4cfcbcf968902d44 for 0.0001 BTC additional fees, 149 delta bytes
2015-02-25 02:29:34 replacing tx 303a20493c92a87956f12764446554df5c205a5c3752a03eacefb43e146f46bb with 0b6c3ac0bf92646477577018a345e7d5f29240069ddb326a9874e42c3f86ef6e for 0.0002 BTC additional fees, 0 delta bytes
2015-02-25 04:37:06 replacing tx 986533577ab6a93bf4c5cfbc41e5ff0bd7fea532f54d504b27afa095acc200a9 with 5557bab846acf7ff0e553c68345b44812d7154ab464fd6548feb3bf9a94e0d24 for 0.00012241 BTC additional fees, -39 delta bytes
2015-02-25 06:08:27 replacing tx a0be6b95f944a051a7f1a23c3aa60ef00e92bcdce2bfb45c7caf465d5eb04a92 with 7f8c495e444ddc263ec96ec5724c12e04c0830e525e31eb1f89d8d544c7419d8 for 0.0001 BTC additional fees, 1513 delta bytes
Il pattern più gettonato sembra essere quello di creare un diverso numero di transazioni a 0fee verso il proprio target (mi sembra gambling house) e poi invalidarle tutte mettendo tutti gli input spesi in un unico double spend, come ad esempio qui:
Quote
2015-02-24 14:03:03 replacing tx 5a541f15f895568fb8aa3aab4b7e8c381f6fd480824acc39074ec4e8a5812636 with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:03:03 replacing tx 8b415ac8104151c77512c30b793250ee9a48eaf993e8d523a20f38e0e6555f30 with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:03:03 replacing tx 60ccc56361a37a038509f47e050cfe732f5d40805e75a9792a329627d8648ece with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:03:03 replacing tx 8b415ac8104151c77512c30b793250ee9a48eaf993e8d523a20f38e0e6555f30 with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
2015-02-24 14:03:03 replacing tx 60ccc56361a37a038509f47e050cfe732f5d40805e75a9792a329627d8648ece with 4a61626bb3f1595cab667935760967836f20347f68e6f9ac2e729da670f09e9c for 0.00049 BTC additional fees, -8753 delta bytes
o qui:
Quote
2015-02-23 15:21:17 replacing tx c7a8defd93deefc907ffc1ffdde1fa3d4aebae778c2fee5dbe17fd9ba7976b35 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 73226c1e56606ff109c13723576617f1484f0af992814e66997b74f9e7e3916e with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 9c1b747d341eecaab7abc990b32eb01ca16193e098aa67533151d9abd30ff338 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 9caee64d69df493367934c5af44b13ef8cbf003277643f20b314ef6f4194cae4 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 73226c1e56606ff109c13723576617f1484f0af992814e66997b74f9e7e3916e with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 9c1b747d341eecaab7abc990b32eb01ca16193e098aa67533151d9abd30ff338 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
2015-02-23 15:21:17 replacing tx 9caee64d69df493367934c5af44b13ef8cbf003277643f20b314ef6f4194cae4 with a4431cdd0c75824172b00e8ce1242c443ad6fe81aad32f844d5742eaa9e8cdcd for 0.0001 BTC additional fees, -772 delta bytes
etc..
Si, il limite di quella funzione è appunto 21 milioni, mi quoto dal messaggio di prima:
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L840
Dove MAX_MONEY è definito qui :
https://github.com/bitcoin/bitcoin/blob/master/src/amount.h#L20
FaSan
Anche quello che hai postato tu, come limite, mette appunto i 21milioni (che sono i BTC massimi).
Per cui non c'è un limite
Bitcoin limita l' importo max per ogni TX qui :https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L840
Dove MAX_MONEY è definito qui :
https://github.com/bitcoin/bitcoin/blob/master/src/amount.h#L20
FaSan
Per cui non c'è un limite
Bitcoin limita l' importo max per ogni TX qui :
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L840
Dove MAX_MONEY è definito qui :
https://github.com/bitcoin/bitcoin/blob/master/src/amount.h#L20
FaSan
se ho capito bene limitano la txout.nValue con il massimo di monete che saranno in circolazione quando il mining che genera blocchi sarà terminato.
if (txout.nValue > MAX_MONEY) then ERROR
con
static const CAmount COIN = 100000000;
/** No amount larger than this (in satoshi) is valid */
static const CAmount MAX_MONEY = 21000000 * COIN;
Per cui non c'è un limite
Bitcoin limita l' importo max per ogni TX qui :https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L840
Dove MAX_MONEY è definito qui :
https://github.com/bitcoin/bitcoin/blob/master/src/amount.h#L20
FaSan
Si ok.. tutto ha un limite in informatica se vogliamo esser pignoli, logico... ma intendevo come ho detto che:
Vedrai chiaramente che sono molti di piu dell'importo massimo di bitcoin esistenti Smiley
Ora, considerando che ci sono 21milioni di BTC massimi, e che il numero previsto dal protocollo è di 184miliardi circa, non ha un limite tecnico il protocollo, perchè anche se tutti i BTC fossero su un solo indirizzo, sarebbero spendibili da protocollo... quindi in quel senso "non c'è un limite".
Anche quello che hai postato tu, come limite, mette appunto i 21milioni (che sono i BTC massimi).
Quindi la mia affermazione che non ha un limite era intesa in quel senso, puoi spendere anche tutti i BTC in un singolo colpo che il protocollo lo accetta, non hai limite di cifre date dal protocollo stesso o da bitcoin-core. Il limite è semmai quanti BTC hai tu.
Per cui non c'è un limite
Bitcoin limita l' importo max per ogni TX qui :
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L840
Dove MAX_MONEY è definito qui :
https://github.com/bitcoin/bitcoin/blob/master/src/amount.h#L20
FaSan
@Picchio: Per via dei problemi con la precisione dei floating point, la blockchain non poteva che registrare gli importi in interi.
Quanti bit sono dedicati all'importo?EDIT: dove posso trovare le specifiche cosi' non rompo ...
https://en.bitcoin.it/wiki/Protocol_documentation
In particolare nella parte: https://en.bitcoin.it/wiki/Protocol_documentation#tx
Vedi la TX come è composta.
L'importo è formato da 16 cifre esadecimali.
Quindi circa 1,844674407×10¹⁹ satoshi.. dividi per 100.000.000 per trovare i BTC massimi di ogni TX (18.4467.440.737 BTC).
Vedrai chiaramente che sono molti di piu dell'importo massimo di bitcoin esistenti
Per cui non c'è un limite
NB: al link si trova che
8 value int64_t Transaction Value
Quindi si legge 8 Byte che sono ovviamente 16 cifre esadecimali, cosi' il prossimo che legge non perde i miei 10 minuti per capire
Grande pagina quella (https://en.bitcoin.it/wiki/Protocol_documentation) ...
EDIT:
Non mi quadra:
Quote
Example of double-SHA-256 encoding of string "hello":
hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)
A me il secondo hash viene:hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)
d7914fe546b684688bb95f4f888a92dfc680603a75f23eb823658031fff766d9 (sembra + corto ma dovrebbe avere 64 caratteri pure lui) comunque e' differente. L0ho calcolato sia con sha256sum da linea di comando che con una estensione per libre (open) office. In entrambi i casi ottengo lo stesso risultato differente da quello della pagina ...
@Picchio: Per via dei problemi con la precisione dei floating point, la blockchain non poteva che registrare gli importi in interi.
Quanti bit sono dedicati all'importo?EDIT: dove posso trovare le specifiche cosi' non rompo ...
https://en.bitcoin.it/wiki/Protocol_documentation
In particolare nella parte: https://en.bitcoin.it/wiki/Protocol_documentation#tx
Vedi la TX come è composta.
L'importo è formato da 16 cifre esadecimali.
Quindi circa 1,844674407×10¹⁹ satoshi.. dividi per 100.000.000 per trovare i BTC massimi di ogni TX (184.467.440.737 BTC).
Vedrai chiaramente che sono molti di piu dell'importo massimo di bitcoin esistenti
Per cui non c'è un limite
Edit: ho aggiustato la cifra, era scritta male
@Picchio: Per via dei problemi con la precisione dei floating point, la blockchain non poteva che registrare gli importi in interi.
Quanti bit sono dedicati all'importo?EDIT: dove posso trovare le specifiche cosi' non rompo ...
@Picchio: Per via dei problemi con la precisione dei floating point, la blockchain non poteva che registrare gli importi in interi.
@Dusty: Grazie, il nome è effettivamente la cosa di cui vado più fiero
@Dusty: Grazie, il nome è effettivamente la cosa di cui vado più fiero
Complimenti Guido per il progetto e per il suo nome 
Sono contento, era uno degli obiettivi di gangsta: capirci di più sia io che l'ho codato, che chi si fosse interessato dopo sul suo funzionamento :-)
Riflettevo su dove porre la seguente domanda e mi sono risposto ... qui'!- che tipo di dato utilizzala variabile importo della transazione? Sono interi divisi per 10^8 o floatting?
Potremmo quasi aprire un 3d per capire meglio le specifiche tecniche della struttura blockchain al fine di non essere OT su questo 3d.
Sono contento, era uno degli obiettivi di gangsta: capirci di più sia io che l'ho codato, che chi si fosse interessato dopo sul suo funzionamento :-)
O in caso devo generare un output verso me sesso o altro mio indirizzo se voglio pagare solo 0.1?
Esatto. E tutto ciò che non viene speso in outputs è automaticamente considerato transaction fee.
O in caso devo generare un output verso me sesso o altro mio indirizzo se voglio pagare solo 0.1?
Esatto. E tutto ciò che non viene speso in outputs è automaticamente considerato transaction fee.
(...)
No, si puo' prendere solo una parte, infatti oltre a txid va specificato anche un parametro che possiamo chiamare "prev_txout_height", ovvero l'altezza dell'input che si intende spendere nella transazione precedente. Questo anche perché in un certo txid possono vivere degli output che non necessariamente appartengono a te che vuoi spendere quel txid.
Prendendo per esempio questa transazione:
https://blockchain.info/tx/9021b49d445c719106c95d561b9c3fac7bcb3650db67684a9226cd7fa1e1c1a0
E prendendo per esempio di essere il proprietario di 1FwLde9A8xyiboJkmjpBnVUYi1DTbXi8yf
Nella costruzione della tua transazione dovrai specificare una roba tipo:
input = 9021b49d445c719106c95d561b9c3fac7bcb3650db67684a9226cd7fa1e1c1a0:0
I 0.39 BTC (1FwLde9A8xyiboJkmjpBnVUYi1DTbXi8yf - (Spesi) 0.39 BTC) vanno spesi tutti o posso spenderne anche solo 0.1 se voglio? O in caso devo generare un output verso me sesso o altro mio indirizzo se voglio pagare solo 0.1? No, si puo' prendere solo una parte, infatti oltre a txid va specificato anche un parametro che possiamo chiamare "prev_txout_height", ovvero l'altezza dell'input che si intende spendere nella transazione precedente. Questo anche perché in un certo txid possono vivere degli output che non necessariamente appartengono a te che vuoi spendere quel txid.
Prendendo per esempio questa transazione:
https://blockchain.info/tx/9021b49d445c719106c95d561b9c3fac7bcb3650db67684a9226cd7fa1e1c1a0
E prendendo per esempio di essere il proprietario di 1FwLde9A8xyiboJkmjpBnVUYi1DTbXi8yf
Nella costruzione della tua transazione dovrai specificare una roba tipo:
input = 9021b49d445c719106c95d561b9c3fac7bcb3650db67684a9226cd7fa1e1c1a0:0
(...)
Un input è composto, oltre che dalle sue componenti crittografiche e dalle istruzioni di esecuzione, dall'id transazione di provenienza dei fondi (è questa la cosa importante: ID transazione, non indirizzo).
All'interno della composizione di una transazione l'indirizzo sorgente non appare affatto!
(...)
Non si smette mai di imparare, ero convinto che i BTC venissero in qualche modo mischiati invece rimangono collegati alla transizione ... Un input è composto, oltre che dalle sue componenti crittografiche e dalle istruzioni di esecuzione, dall'id transazione di provenienza dei fondi (è questa la cosa importante: ID transazione, non indirizzo).
All'interno della composizione di una transazione l'indirizzo sorgente non appare affatto!
(...)
Mi serve un chiarimento (spero di spiegarmi): la transazione coinvolta come input va svuotata completamente o è possibile prendere solo una parte (nella componente di output di competenza dell'indirizzo che invia i BTC)?
grazie
No, si puo' prendere solo una parte, infatti oltre a txid va specificato anche un parametro che possiamo chiamare "prev_txout_height", ovvero l'altezza dell'input che si intende spendere nella transazione precedente. Questo anche perché in un certo txid possono vivere degli output che non necessariamente appartengono a te che vuoi spendere quel txid.
Prendendo per esempio questa transazione:
https://blockchain.info/tx/9021b49d445c719106c95d561b9c3fac7bcb3650db67684a9226cd7fa1e1c1a0
E prendendo per esempio di essere il proprietario di 1FwLde9A8xyiboJkmjpBnVUYi1DTbXi8yf
Nella costruzione della tua transazione dovrai specificare una roba tipo:
input = 9021b49d445c719106c95d561b9c3fac7bcb3650db67684a9226cd7fa1e1c1a0:0
visto che il primo indice d'altezza è sempre "0".
Altrimenti, ipotizzando di essere 1kNAebmDfKcAfEEC2cRgyVFw5jRSjsAyk, avremmo dovuto specificare una roba tipo:
input = 9021b49d445c719106c95d561b9c3fac7bcb3650db67684a9226cd7fa1e1c1a0:1
etc.. etc..
(...)
Un input è composto, oltre che dalle sue componenti crittografiche e dalle istruzioni di esecuzione, dall'id transazione di provenienza dei fondi (è questa la cosa importante: ID transazione, non indirizzo).
All'interno della composizione di una transazione l'indirizzo sorgente non appare affatto!
(...)
Non si smette mai di imparare, ero convinto che i BTC venissero in qualche modo mischiati invece rimangono collegati alla transizione ... Un input è composto, oltre che dalle sue componenti crittografiche e dalle istruzioni di esecuzione, dall'id transazione di provenienza dei fondi (è questa la cosa importante: ID transazione, non indirizzo).
All'interno della composizione di una transazione l'indirizzo sorgente non appare affatto!
(...)
Mi serve un chiarimento (spero di spiegarmi): la transazione coinvolta come input va svuotata completamente o è possibile prendere solo una parte (nella componente di output di competenza dell'indirizzo che invia i BTC)?
grazie
In ogni caso quando esegui una transazione l'indirizzo mittente viene interamente "svuotato", ed eventualmente (bad practice: address reusing, gli indirizzi BTC debbono essere pensati come "usa e getta") riempito di nuovo dal resto, ma se tu volessi effettuare una nuova transazione, non potresti usare gli stessi input della precedente.
Un input è composto, oltre che dalle sue componenti crittografiche e dalle istruzioni di esecuzione, dall'id transazione di provenienza dei fondi (è questa la cosa importante: ID transazione, non indirizzo).
All'interno della composizione di una transazione l'indirizzo sorgente non appare affatto!
Quindi, anche in presenza di "fondi sufficienti" (perché hai usato come change address della prima tx l'indirizzo stesso) la seconda tx non sarà valida, perché l'id transazione specificato nella precedente sarà già stato "impegnato" per il blocco successivo.
Un input è composto, oltre che dalle sue componenti crittografiche e dalle istruzioni di esecuzione, dall'id transazione di provenienza dei fondi (è questa la cosa importante: ID transazione, non indirizzo).
All'interno della composizione di una transazione l'indirizzo sorgente non appare affatto!
Quindi, anche in presenza di "fondi sufficienti" (perché hai usato come change address della prima tx l'indirizzo stesso) la seconda tx non sarà valida, perché l'id transazione specificato nella precedente sarà già stato "impegnato" per il blocco successivo.
Domanda: ma se un indirizzo ha fondi a sufficienza per sostenere entrambe le transazioni di fatto possono venire approvate entrambe. A meno che il resto non venga in entrambe inviato ad un address differente dal mittente (e non avrebbe pertanto i fondi per sostenere entrambe le transazioni). Sbaglio qualcosa?
Il problema stà nel tempo settato per il refresh delle tx nelle varie pool. Se osservi un pò di codice e l' andamento della blockchain vedrai che alcune pool aggiornano ogni 30 secondi, ma c'anche chi aggiorna ogni 60, qualche furbetto anche più tardi. In questo modo il rischio di includere una TX al posto di un'altra è abbastanza alto e completamente imprevedibile.
FaSan
FaSan
premetto che viste le vs. competenze,
le mie rasentano lo zero,
mi chiedo:
come mai si tende ad alzare il refresh delle transazioni oltre i 30 sec da parte delle pool???
per come è stato impostato il discorso sembra che questo refresh abbia un "costo" e alzando oltre i 30 sec questo intervallo, il costo si abbatta..
ora mi chiedo...
ma questo "costo" ..
quale è???
Siamo OT quindi ti rispondo velocemente, poi se vuoi approfondire magari apriamo un thread apposta.
Non c'è alcun costo, se non chiaramente nelle prestazioni del server. Aggiornare ogni secondo impegna più risorse che aggiornare ogni minuto. Inoltre non daresti abbastanza tempo ai miners di lavorare il job.
Il discorso è un'altro, secondo alcune scuole di pensiero (secondo me senza fondamenti validi), aggiornare più tardi escluderebbe per un periodo più lungo una delle tre incognite durante il mining (che si ridurrebbero a due - timestamp e nonce variabili con merkleroot fissa per il tutto il periodo), dando più probabilità nel trovare il blocco. In realtà non è affatto così inquanto non è assolutamente detto che quella Merkle possa dare un hash sotto la diff.
FaSan
Non ho guardato il codice, ma il progetto per come descritto sembra davvero ottimo. Complimenti.
Personalmente mi auguro che la patch replace-by-fee venga integrata in bitcoin core, anche se non credo sia così probabile, almeno a breve.
C'è anche da dire che alla fin fine comandano i miner, e questi dovrebbero aver vantaggio ad accettare nei "tentativi di doppia spesa" la transazione con commissione maggiore, per cui boh, vedremo
Ciao!
Personalmente mi auguro che la patch replace-by-fee venga integrata in bitcoin core, anche se non credo sia così probabile, almeno a breve.
C'è anche da dire che alla fin fine comandano i miner, e questi dovrebbero aver vantaggio ad accettare nei "tentativi di doppia spesa" la transazione con commissione maggiore, per cui boh, vedremo
Ciao!
Il problema stà nel tempo settato per il refresh delle tx nelle varie pool. Se osservi un pò di codice e l' andamento della blockchain vedrai che alcune pool aggiornano ogni 30 secondi, ma c'anche chi aggiorna ogni 60, qualche furbetto anche più tardi. In questo modo il rischio di includere una TX al posto di un'altra è abbastanza alto e completamente imprevedibile.
FaSan
premetto che viste le vs. competenze,
le mie rasentano lo zero,
mi chiedo:
come mai si tende ad alzare il refresh delle transazioni oltre i 30 sec da parte delle pool???
per come è stato impostato il discorso sembra che questo refresh abbia un "costo" e alzando oltre i 30 sec questo intervallo, il costo si abbatta..
ora mi chiedo...
ma questo "costo" ..
quale è???
Il problema stà nel tempo settato per il refresh delle tx nelle varie pool. Se osservi un pò di codice e l' andamento della blockchain vedrai che alcune pool aggiornano ogni 30 secondi, ma c'anche chi aggiorna ogni 60, qualche furbetto anche più tardi.
Appunto, sarebbe uno stimolo per far sì che le pool aggiornino più di frequente: chi aggiorna ad intervalli più lunghi rischia di perdersi le commissioni più alte dei "tentativi di doppia spesa".Quote
In questo modo il rischio di includere una TX al posto di un'altra è abbastanza alto e completamente imprevedibile.
In realtà tutto ciò che avviene prima della prima conferma è sempre abbastanza imprevedibile, e alla fine è giusto così.Ciao!
Non ho guardato il codice, ma il progetto per come descritto sembra davvero ottimo. Complimenti.
Personalmente mi auguro che la patch replace-by-fee venga integrata in bitcoin core, anche se non credo sia così probabile, almeno a breve.
C'è anche da dire che alla fin fine comandano i miner, e questi dovrebbero aver vantaggio ad accettare nei "tentativi di doppia spesa" la transazione con commissione maggiore, per cui boh, vedremo
Ciao!
Personalmente mi auguro che la patch replace-by-fee venga integrata in bitcoin core, anche se non credo sia così probabile, almeno a breve.
C'è anche da dire che alla fin fine comandano i miner, e questi dovrebbero aver vantaggio ad accettare nei "tentativi di doppia spesa" la transazione con commissione maggiore, per cui boh, vedremo
Ciao!
Il problema stà nel tempo settato per il refresh delle tx nelle varie pool. Se osservi un pò di codice e l' andamento della blockchain vedrai che alcune pool aggiornano ogni 30 secondi, ma c'anche chi aggiorna ogni 60, qualche furbetto anche più tardi. In questo modo il rischio di includere una TX al posto di un'altra è abbastanza alto e completamente imprevedibile.
FaSan
Non ho guardato il codice, ma il progetto per come descritto sembra davvero ottimo. Complimenti.
Personalmente mi auguro che la patch replace-by-fee venga integrata in bitcoin core, anche se non credo sia così probabile, almeno a breve.
C'è anche da dire che alla fin fine comandano i miner, e questi dovrebbero aver vantaggio ad accettare nei "tentativi di doppia spesa" la transazione con commissione maggiore, per cui boh, vedremo
Ciao!
Personalmente mi auguro che la patch replace-by-fee venga integrata in bitcoin core, anche se non credo sia così probabile, almeno a breve.
C'è anche da dire che alla fin fine comandano i miner, e questi dovrebbero aver vantaggio ad accettare nei "tentativi di doppia spesa" la transazione con commissione maggiore, per cui boh, vedremo
Ciao!
La domande banali sono:
1)cosa si intende per stessi input?
2)Ma alla fine in che senso si avrebbe double spending? Non si tratterebbe solo una transazione che viene confermata al posto di un'altra?
3)Più che un double spending vero è proprio si tratterebbe di fregare chi considera "come ricevuta" una transazione senza conferme?
1) Nella rete Bitcoin ogni transazione è composta da input precedentemente assegnati alla chiave pubblica che firma la transazione. Emettendo una transazione si annullano quegli input (spendendoli) nella loro interezza, e i fondi vengono spostati altrove. (Destinatario e proprio indirizzo di cambio, dove viene messo "il resto", poiché gli input, ripeto, debbono essere spesi nella loro interezza).
2) Una transazione che prenda il posto di un'altra, precedentemente vista dalla rete, è quello che si definisce una doppia spesa. Uno dei due destinatari pur avendo "visto" la transazione entrante, poi in realtà non la riceverà, poiché non è possibile falsificare bitcoin.
3) Appunto, un double spending. :-)
Tuttavia l'utilizzo descritto da parte di Fasan (che chiameremo "transaction bump") è un tantinello più utile, costruttivo e attuabile con percentuali di riuscita migliori, visto che la transazione a 0-fee verrà rifiutata da tanti nodi e la concorrenza fra le due transazioni sarà "meno feroce", ma sopratutto: qualunque delle due transazioni venisse minata, andrebbe bene lo stesso.
A tal proposito, una via per il gestore potrebbe essere quella di settare il proprio layer sul nodo replace-by-fee per permettere solo i bump delle transazioni (e quindi rifiutare transazioni che condividano gli stessi input ma abbiano destinazioni diverse, permettendo invece di dare "una spintarella" alle transazioni con fee sotto la soglia minima), per renderlo "etico".
Ci sto pensando, per ora non c'è traffico rilevante da giustificare la cosa.
(...)
3)Più che un double spending vero è proprio si tratterebbe di fregare chi considera "come ricevuta" una transazione senza conferme?
Anche secondo me non sono possibili altre interpretazioni.3)Più che un double spending vero è proprio si tratterebbe di fregare chi considera "come ricevuta" una transazione senza conferme?
Al massimo ci puo' essere il dubbio e dover aspettare 6 transazioni per evitare fork.
Non credo che abbiate capito come funziona. Succede abbastanza spesso di inoltrare una TX dimenticando la fee, o inserendone una più bassa del necessario, o aver sbagliato l' address di destinazione. In quel frangente o aspetti che qualche miner benevolo l' accetti lo stesso, oppure aspetti il reject della TX che può avvenire anche dopo giorni.
Il doublespending può essere usato anche per legittimare quindi una TX e non solo per truffare. Senza contare che chi accetta pagamenti senza attendere almeno 1 conferma è un' irresponsabile e lo fà a suo rischio e pericolo.
FaSan
(...)
3)Più che un double spending vero è proprio si tratterebbe di fregare chi considera "come ricevuta" una transazione senza conferme?
Anche secondo me non sono possibili altre interpretazioni.3)Più che un double spending vero è proprio si tratterebbe di fregare chi considera "come ricevuta" una transazione senza conferme?
Al massimo ci puo' essere il dubbio e dover aspettare 6 transazioni per evitare fork.
Scusa le domande banali ma sto cercando di capire come funziona.
A questo link: http://bitcoin.stackexchange.com/questions/10733/what-is-replace-by-fee
leggo che:
It's a method that allows replacing an already transmitted transaction by transmitting another transaction with a higher fee. This only works on transactions before they are signed by miners (0-confirmations).
che è quello che hai spiegato ad inizio post:
"permette di rimpiazzare transazioni effettuate con altre transazioni aventi gli stessi input, fintanto che queste transazioni non siano state confermate"
La domande banali sono:
1)cosa si intende per stessi input?
2)Ma alla fine in che senso si avrebbe double spending? Non si tratterebbe solo una transazione che viene confermata al posto di un'altra?
3)Più che un double spending vero è proprio si tratterebbe di fregare chi considera "come ricevuta" una transazione senza conferme?
A questo link: http://bitcoin.stackexchange.com/questions/10733/what-is-replace-by-fee
leggo che:
It's a method that allows replacing an already transmitted transaction by transmitting another transaction with a higher fee. This only works on transactions before they are signed by miners (0-confirmations).
che è quello che hai spiegato ad inizio post:
"permette di rimpiazzare transazioni effettuate con altre transazioni aventi gli stessi input, fintanto che queste transazioni non siano state confermate"
La domande banali sono:
1)cosa si intende per stessi input?
2)Ma alla fine in che senso si avrebbe double spending? Non si tratterebbe solo una transazione che viene confermata al posto di un'altra?
3)Più che un double spending vero è proprio si tratterebbe di fregare chi considera "come ricevuta" una transazione senza conferme?
Penso che l'impatto maggiore lo dia la possibilità di inclusione della prima tx, se è una tx che rispetta gli standard di fee e non ha embedda dati strani, quindi tende ad essere inclusa da tutti ASAP, la % di successo precipita vertiginosamente.
Puo benissimo esser infatti che magari le prime che ho fatto di prova da alcuni nodi siano state rifiutate, quindi avendo visto solo la seconda, hanno confermato quella.
Magari è il caso di eligius se non è uno speciale, ma semplicemente ha rifiutato la prima perchè a 0 fee e con address di spam.
Quindi si, erano prove sul campo, in ogni caso l'elenco di nodi che usano il replace_by_fee si può vedere dal replace stesso, analizzando le connessioni attive.
Penso che l'impatto maggiore lo dia la possibilità di inclusione della prima tx, se è una tx che rispetta gli standard di fee e non embedda dati strani, quindi tende ad essere inclusa da tutti ASAP, la % di successo precipita vertiginosamente.
Comunque sarebbe interessante broadcastare double spend ricorrenti e identificare i nodi che minano i blocchi in cui si è avuto successo, per capire un po' questa effettiva % di riuscita.
Comunque sarebbe interessante broadcastare double spend ricorrenti e identificare i nodi che minano i blocchi in cui si è avuto successo, per capire un po' questa effettiva % di riuscita.
Luke-Jr (eligius) nega.
Come hai verificato ?
Come hai verificato ?
Avevo fatto le double e la conferma era arrivata proprio quando il blocco, blockchain.info, me lo segnava trovato da eligius, non ho pero verificato se era davvero cosi dal sito stesso.
Sinceramente non ho piu le varie TX perchè erano di qualche giorno fa....
Le ultime prove che ho fatto e che erano sicuramente in double e mi sono state confermate sono questa:
https://blockchain.info/it/tx/372745eef33cbf99e1d1cf263d23eeb4b79b26bd7b5075d3b2c2cffa52a17f54
E questa:
https://blockchain.info/tx/0aea7e4ca748a91734153d0d0be287c3c93f99390c1474c3b3c455e1aaeac71d
La prima sempre blockchain la segna trovata da bw pool mentre la seconda da BTC Guild.
Tra l'altro bw pool ha tutt'ora delle double in attesa (https://blockchain.info/it/address/1JLRXD8rjRgQtTS9MvfQALfHgGWau9L9ky)
Aggiungo che l'altra cosa che ho notato è che comunque, anche con fee alta (1mBTC su alcune) prima che arrivino conferme possono volerci anche 4-5 ore.
Questo perchè immagino che creino abbastanza "confusione" all'interno della rete e dei vari btc.
Cosi come ho notato che cercando le TX su vari block explorer (chain.so, bitboat e blockchain) queste nell'arco delle 4-5 ore spariscono e riappaiono. In particolare blockchain.info vede entrambe le TX, mentre gli altri due explorer ne vedono e accettano solo una.
Ed a volte questa cambia (magari quindi prima bitboat vede la TX a 0 fee, poi sparisce, non vede nulla... e dopo un po vede l'altra).
Quindi sembra come (ma non ho approfondito poi piu di tanto dopo) che se mandi una TX con indirizzi di spam (usavo satoshidice) magari si propaga ma, dopo che rimane per troppo tempo nella mem dei miner, viene tolta e subentra l'altra.
Ho verificato che gli unici miner "grossi" che accettano e confermano il double sono quello d eligius.st e uno riconducibile a ghash (ma solo 1 appunto, gli altri 2-3 demoni sempre di ghash non l'accettano).
Quindi siamo sopra al 3% della rete ma confermo, veramente poca roba.
Luke-Jr (eligius) nega.
Come hai verificato ?
Tendenzialmente queste transazioni vengono viste dall'intera rete come doppie spese, e quindi ignorate dalla maggioranza dei nodi (speculazioni parlano di un 3% dei miners che le accetterebbero, non ho fonte, non ricordo neanche dove l'avevo letto, ma non è un numero da prendere per buono, probabilmente si parla di molto meno).
Ho provato nei giorni scorsi proprio la patch e vari double-spend per delle prove.
Ho verificato che gli unici miner "grossi" che accettano e confermano il double sono quello d eligius.st e uno riconducibile a ghash (ma solo 1 appunto, gli altri 2-3 demoni sempre di ghash non l'accettano).
Quindi siamo sopra al 3% della rete ma confermo, veramente poca roba.
La patch replace-by-fee, scritta l'anno scorso da Peter Todd dietro bounty da parte di un privato, ma mai inserita nel codice ufficiale dal core team, permette di rimpiazzare transazioni effettuate con altre transazioni aventi gli stessi input, fintanto che queste transazioni non siano state confermate, a patto che la fee della tx di rimpiazzo sia maggiore della precedente.
Tendenzialmente queste transazioni vengono viste dall'intera rete come doppie spese, e quindi ignorate dalla maggioranza dei nodi (speculazioni parlano di un 3% dei miners che le accetterebbero, non ho fonte, non ricordo neanche dove l'avevo letto, ma non è un numero da prendere per buono, probabilmente si parla di molto meno).
Un esempio di indirizzo che ha effettuato delle doppie spese, è questo:
La prima transazione in ordine temporale è quella "buona", le altre due non sarebbero mai state accettate da un nodo normale, ma un nodo patchato replace-by-fee invece le salva, e propone per l'inclusione nel blocco quella con fee maggiore. Se al nodo stesso venissero nuovamente proposte da altri nodi transazioni con fee minore, il nodo risponderebbe così
Intanto, ecco com'è andato a finire il double spend qui sopra:
Un miner della maggioranza, quindi, uno di quelli che non validano transazioni di rimpiazzo, ha minato il blocco, e lo ha fatto dopo aver rifiutato il relay delle altre due transazioni, i double spend.
Tutto bene, insomma, double spend ad oggi resta tagliato fuori dalla rete (una decina di tentativi, nessun successo). Resta assunto che le transazioni a zero conferme sono transazioni a zero lavoro, e vanno prese con le pinzette, come fa la stragrande maggioranza dei merchant. Oppure, ci sono servizi terzi che si pongono come trusted parties, che imho prenderanno sempre più piede.
Boh, vedremo.
Ciò detto per spiegare come (non) funziona: Introducing gangsta
Gangsta è una web app che aggiunge a qualunque client single-sig la feature di double spend nei confronti di nodi replace-by-fee.
A qualunque, sì, perché è una app stand-alone, nell'esempio la vediamo andare in supporto a Multibit:
Innanzitutto bisogna esportare le chiavi
Poi importarle in gangsta (è tutto client-side), potete pastare tutto il file senza problemi, il form è smart.
Chiavi importate, wallet sincronizzato. Ovviamente si appoggia a servizi di terze parti (blockr.io e blockchain), o sarei davvero troppo bravo per perdere tempo con queste cose.
Tornate su Multibit, fate la vostra transazione normalmente.
Tornate su gangsta, per velocità c'è un bottone di wallet sync, altrimenti c'è il polling ogni due minuti, tanto per restare sul pezzo.
Dopo che avrete visto la vostra transazione, potrete aprirla nell'editor e modificare gli outputs. Incrementate la fee o la transazione verrà rifiutata dal nodo, dopo aver fatto (fate in fretta, o finisce che la transazione viene inclusa e voi siete ancora lì che scrivete a mano l'indirizzo di rimpiazzo) premete il bottone verde. Premete sempre il bottone, ogni 108 minuti.
Una panoramica della transazione modificata e la possibilità di pusharla. Dunque, sia decodifica che push vengono fatti lato server, quindi se non riuscirete a fare la decodifica vuol dire che per qualche motivo il server è giù, o non riuscite a raggiungerlo, o sono passati più di 108 minuti da quando avete premuto il pulsante. Insomma, non potreste pushare la transazione, ma avreste l'hex.
Assumendo che non sia esploso tutto, comunque:
Dopo aver pushato la transazione si torna alle prime immagini, la transazione non verrà inclusa in alcun blocco, le possibilità che avvenga sono risibili, ma avrete fatto un tentativo di doppia spesa.
Se su blockchain.info non riuscite a vedere la transazione dovete disabilitare i filtri sull'indirizzo:
demo: http://gangsta.dassori.me
source: http://github.com/gdassori/gangsta
Non pastate chiavi importanti sull'app online, se volete provare fatevi un wallet con pochi mbtc, basteranno. Non appena ho tempo lo passo anche su testnet.
Ovviamente loggherò tutti i vostri tentativi di doppia spesa che passeranno attraverso il mio server, e forse li pubblicherò tipo pagina figa dove scorrono i dati, roba di gran classe.
Provatela e segnalatemi i bug!
Tendenzialmente queste transazioni vengono viste dall'intera rete come doppie spese, e quindi ignorate dalla maggioranza dei nodi (speculazioni parlano di un 3% dei miners che le accetterebbero, non ho fonte, non ricordo neanche dove l'avevo letto, ma non è un numero da prendere per buono, probabilmente si parla di molto meno).
Un esempio di indirizzo che ha effettuato delle doppie spese, è questo:
La prima transazione in ordine temporale è quella "buona", le altre due non sarebbero mai state accettate da un nodo normale, ma un nodo patchato replace-by-fee invece le salva, e propone per l'inclusione nel blocco quella con fee maggiore. Se al nodo stesso venissero nuovamente proposte da altri nodi transazioni con fee minore, il nodo risponderebbe così
Quote
2015-02-19 00:49:45 ERROR: AcceptToMemoryPool : rejecting replacement 3ac20d0e9eb83e4c25ebfaa23a09885e4cad35227eddda9f7892c048a81edd87, pays less fees than conflicting txs; 0.00 < 0.0017
2015-02-19 00:49:46 ERROR: AcceptToMemoryPool : rejecting replacement 3479d936a925fe196d3c693616c6a19777d2c6929b94c77a281f33364b2d03f3, pays less fees than conflicting txs; 0.00 < 0.0008
2015-02-19 00:49:46 ERROR: AcceptToMemoryPool : rejecting replacement 3479d936a925fe196d3c693616c6a19777d2c6929b94c77a281f33364b2d03f3, pays less fees than conflicting txs; 0.00 < 0.0008
Intanto, ecco com'è andato a finire il double spend qui sopra:
Un miner della maggioranza, quindi, uno di quelli che non validano transazioni di rimpiazzo, ha minato il blocco, e lo ha fatto dopo aver rifiutato il relay delle altre due transazioni, i double spend.
Tutto bene, insomma, double spend ad oggi resta tagliato fuori dalla rete (una decina di tentativi, nessun successo). Resta assunto che le transazioni a zero conferme sono transazioni a zero lavoro, e vanno prese con le pinzette, come fa la stragrande maggioranza dei merchant. Oppure, ci sono servizi terzi che si pongono come trusted parties, che imho prenderanno sempre più piede.
Boh, vedremo.
Ciò detto per spiegare come (non) funziona: Introducing gangsta
Gangsta è una web app che aggiunge a qualunque client single-sig la feature di double spend nei confronti di nodi replace-by-fee.
A qualunque, sì, perché è una app stand-alone, nell'esempio la vediamo andare in supporto a Multibit:
Innanzitutto bisogna esportare le chiavi
Poi importarle in gangsta (è tutto client-side), potete pastare tutto il file senza problemi, il form è smart.
Chiavi importate, wallet sincronizzato. Ovviamente si appoggia a servizi di terze parti (blockr.io e blockchain), o sarei davvero troppo bravo per perdere tempo con queste cose.
Tornate su Multibit, fate la vostra transazione normalmente.
Tornate su gangsta, per velocità c'è un bottone di wallet sync, altrimenti c'è il polling ogni due minuti, tanto per restare sul pezzo.
Dopo che avrete visto la vostra transazione, potrete aprirla nell'editor e modificare gli outputs. Incrementate la fee o la transazione verrà rifiutata dal nodo, dopo aver fatto (fate in fretta, o finisce che la transazione viene inclusa e voi siete ancora lì che scrivete a mano l'indirizzo di rimpiazzo) premete il bottone verde. Premete sempre il bottone, ogni 108 minuti.
Una panoramica della transazione modificata e la possibilità di pusharla. Dunque, sia decodifica che push vengono fatti lato server, quindi se non riuscirete a fare la decodifica vuol dire che per qualche motivo il server è giù, o non riuscite a raggiungerlo, o sono passati più di 108 minuti da quando avete premuto il pulsante. Insomma, non potreste pushare la transazione, ma avreste l'hex.
Assumendo che non sia esploso tutto, comunque:
Dopo aver pushato la transazione si torna alle prime immagini, la transazione non verrà inclusa in alcun blocco, le possibilità che avvenga sono risibili, ma avrete fatto un tentativo di doppia spesa.
Se su blockchain.info non riuscite a vedere la transazione dovete disabilitare i filtri sull'indirizzo:
demo: http://gangsta.dassori.me
source: http://github.com/gdassori/gangsta
Non pastate chiavi importanti sull'app online, se volete provare fatevi un wallet con pochi mbtc, basteranno. Non appena ho tempo lo passo anche su testnet.
Ovviamente loggherò tutti i vostri tentativi di doppia spesa che passeranno attraverso il mio server, e forse li pubblicherò tipo pagina figa dove scorrono i dati, roba di gran classe.
Provatela e segnalatemi i bug!
Jump to: