Topic: Gangsta, double spend con replace-by-fee - page 4. (Read 10183 times)

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

Grazie, posso dire di aver capito meglio il funzionamento della blockchain BTC.

Esatto. E tutto ciò che non viene speso in outputs è automaticamente considerato transaction fee.

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

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

Non si smette mai di imparare, ero convinto che i BTC venissero in qualche modo mischiati invece rimangono collegati alla transizione ...
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.

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?

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

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

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

In realtà tutto ciò che avviene prima della prima conferma è sempre abbastanza imprevedibile, e alla fine è giusto così.

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!

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.

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

Anche secondo me non sono possibili altre interpretazioni.
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?

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.