Bitcoin Forum
June 16, 2024, 05:30:40 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 »  All
  Print  
Author Topic: Gangsta, double spend con replace-by-fee  (Read 9580 times)
gdassori (OP)
Hero Member
*****
Offline Offline

Activity: 980
Merit: 1002



View Profile
February 19, 2015, 01:34:25 AM
Last edit: May 26, 2015, 05:43:44 PM by gdassori
 #1

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ì

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

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.

Grin Grin Grin Grin Grin

Provatela e segnalatemi i bug!

davvo
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
February 19, 2015, 08:36:03 AM
 #2

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.
gdassori (OP)
Hero Member
*****
Offline Offline

Activity: 980
Merit: 1002



View Profile
February 19, 2015, 09:43:48 AM
 #3


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 ?

davvo
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
February 19, 2015, 10:11:56 AM
 #4

Luke-Jr (eligius) nega.

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.
gdassori (OP)
Hero Member
*****
Offline Offline

Activity: 980
Merit: 1002



View Profile
February 19, 2015, 11:28:12 AM
 #5

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.

davvo
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
February 19, 2015, 11:30:32 AM
 #6

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.
jkoin
Hero Member
*****
Offline Offline

Activity: 484
Merit: 500



View Profile
February 20, 2015, 09:30:32 AM
 #7

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?
picchio
Legendary
*
Offline Offline

Activity: 2506
Merit: 1120



View Profile
February 20, 2015, 09:34:55 AM
 #8

(...)
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.
Al massimo ci puo' essere il dubbio e dover aspettare 6 transazioni per evitare fork.

Waves mi piaceva ora non più.
FaSan
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
February 20, 2015, 09:40:59 AM
 #9

(...)
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.
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
gdassori (OP)
Hero Member
*****
Offline Offline

Activity: 980
Merit: 1002



View Profile
February 20, 2015, 02:48:20 PM
 #10


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.


Stemby
Legendary
*
Offline Offline

Activity: 2450
Merit: 1008



View Profile
February 20, 2015, 04:38:01 PM
 #11

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 Smiley

Ciao!

“…virtual currencies, could have a substitution effect on central bank money if they become widely accepted.”
ECB Report, October 2012
FaSan
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
February 20, 2015, 04:54:49 PM
 #12

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 Smiley

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
Stemby
Legendary
*
Offline Offline

Activity: 2450
Merit: 1008



View Profile
February 20, 2015, 05:10:16 PM
 #13

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!

“…virtual currencies, could have a substitution effect on central bank money if they become widely accepted.”
ECB Report, October 2012
MamaGoose
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
February 20, 2015, 08:12:34 PM
 #14

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 Smiley

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

FaSan
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
February 20, 2015, 08:20:22 PM
 #15

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


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
picchio
Legendary
*
Offline Offline

Activity: 2506
Merit: 1120



View Profile
February 20, 2015, 10:42:23 PM
 #16

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?

Waves mi piaceva ora non più.
gdassori (OP)
Hero Member
*****
Offline Offline

Activity: 980
Merit: 1002



View Profile
February 21, 2015, 08:24:15 AM
 #17

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.

picchio
Legendary
*
Offline Offline

Activity: 2506
Merit: 1120



View Profile
February 21, 2015, 11:21:26 AM
 #18

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

Waves mi piaceva ora non più.
gdassori (OP)
Hero Member
*****
Offline Offline

Activity: 980
Merit: 1002



View Profile
February 21, 2015, 12:04:06 PM
 #19

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

picchio
Legendary
*
Offline Offline

Activity: 2506
Merit: 1120



View Profile
February 21, 2015, 12:40:35 PM
 #20

(...)
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?

Waves mi piaceva ora non più.
Pages: [1] 2 3 4 5 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!