L'enorme e (s)conosciuto problema del Resto nella transazioni

[alexrossi]

ho visto che su Armory (ma credo ormai su tutti i wallet principali) quando importi una privkey quindi anche un paper wallet ti chiede se importare l'indirizzo o fare lo sweep sul wallet.
In teoria facendo lo sweep ti metti al riparo in quanto viene preso tutto l'ammontare.

Sì, questo vale anche per electrum: se importo la priv key anziché fare uno sweep, e sono particolarmente inesperto, potrei credere che il seed abbia il backup di tutto, mentre non sarebbe vero e potrei perdere btc.

[1715023407]

1715023407

[1715023407]

1715023407

[1715023407]

1715023407

[1715023407]

1715023407

[1715023407]

1715023407

[1715023407]

1715023407

[Wolframio]

Ma c'è un motivo tecnico per questi resti? cioè è molto scomodo e macchinoso in realtà.. non sarebbe più semplice che tutto ciò che hai nel wallet può essere diviso e unito a piacere? C'è qualche limitazione tecnica??

[Cerbix]

Ma c'è un motivo tecnico per questi resti? cioè è molto scomodo e macchinoso in realtà.. non sarebbe più semplice che tutto ciò che hai nel wallet può essere diviso e unito a piacere? C'è qualche limitazione tecnica??

Da quello che ho capito il motivo maggiore è la privacy...
Se A paga B in realta risultera che A invia BTC sia a B che a C.
C però appartiene sempre ad A

[alexrossi]

Ma c'è un motivo tecnico per questi resti? cioè è molto scomodo e macchinoso in realtà.. non sarebbe più semplice che tutto ciò che hai nel wallet può essere diviso e unito a piacere? C'è qualche limitazione tecnica??

L'hai detto: è una limitazione tecnica!
Devi immaginarti gli input come delle banconote, se la cosa che compri è di valore inferiore rispetto al taglio che ho in mano, chiaramente non posso dividere in pezzettini la banconota ma mi sarà dato il resto.

[Wolframio]

E non potevano fare tutte "banconote" da 1 satoshi??

[Cerbix]

E non potevano fare tutte "banconote" da 1 satoshi??

L'idea dovrebbe essere questa:
Quando invio un pagamente devo dimostrare che quei BTC sono miei e per farlo metto bella transazione la provenienza.
Ecco qua che i btc che ho ricevuto in precedenza  e vengono visti come unica banconota.

Perlomeno è la conclusione alla quale sono giunto  correzioni in caso di errori sono ben accette

[alexrossi]

E non potevano fare tutte "banconote" da 1 satoshi??

Le transazioni sarebberò però risultate estremamente più pesanti (per via dei singoli input, probabilmente una singola tx potrebbe pesare parecchi MB)

[Wolframio]

E non potevano fare tutte "banconote" da 1 satoshi??

Le transazioni sarebberò però risultate estremamente più pesanti (per via dei singoli input, probabilmente una singola tx potrebbe pesare parecchi MB)

ah ecco ecco.. ci stà in effetti!! grazie per avermi chiarito i dubbi!!

[corsaro]

vorrei fare un piccolo riepilogo di questa discussione che reputo importante e fondamentale per la comprensione del funzionamento dei wallet bitcoin-qt.exe e cloni vari....

1)circa i file "wallet.dat" del client bitcoin-qt.exe, quando ci sono molte transazioni in uscita, vanno sempre fatti dei backup con periodicità, per via dei resti creati inevitabilmente durante le transazioni in uscita (ciascuna transazione in entrata forma una somma unica o una specie di blocchetto...  per pagare una somma in uscita, vengono messi insieme un tot di blocchetti fino al raggiungimento o al superamento della somma in uscita... la differenza verrà messa in un indirizzo nuovo, diverso da quello di provenienza, sempre all'interno del file wallet.dat)

Quindi, in un qualsiasi client xxxcoin-qt usato per transazioni in uscita, i soldi sono nel file wallet.dat in toto, e non nel singolo indirizzo...
Infatti, il file wallet.dat è in realtà una struttura molto complessa e piena zeppa di indirizzi e chiavi segrete diverse...  


Se invece un wallet lo usiamo solo per transazioni in entrata, su di un singolo indirizzo, in tal caso anche il solo backup della chiave privata di quell'indirizzo sarà sufficiente.


Una cosa...   ho notato che facendo "solo mining" con una moneta sha-256 a bassa difficoltà, per ogni blocco generato viene assegnato il malloppo ad un indirizzo diverso... questo conferma ulteriormente che un file wallet.dat è una miniera di indirizzi diversi, e ogni singola transazione viene decomposta e ricomposta fra i vari indirizzi all'interno del file wallet.dat

maggiori dettagli qui (sui famosi 100 indirizzi) https://it.bitcoin.it/wiki/Proteggere_il_portamonete#Contesto_tecnico

2) circa eventuali paper wallet, qualora la relativa chiave segreta fosse importata su di un client bitcoin.qt.exe per spenderne la cifra "in parte", il paper wallet diventerebbe poi vuoto per via del resto della tranzazione, resto che finirebbe su di un nuovo indirizzo all'interno del file wallet.dat
Quindi in tal caso, farsi poi un backup del file wallet.dat

3) unica eccezione il client wallet Multibit che per i resti riutilizza l'indirizzo di provenienza della somma

[Sandro kensan]

3) unica eccezione il client wallet Multibit che per i resti riutilizza l'indirizzo di provenienza della somma

Non c'è mai molto spazio per discutere di Multibit perché qui pare tutti usino il client ufficiale. Da utente di multibit faccio notare che ogni nuovo wallet ha una chiave privata e quindi l'importazione di un paper wallet o di una chiave privata di qualsiasi provenienza determina un wallet di due chiavi private. Occorre quindi fare il back up di due chiavi.

La struttura del file txt delle chiavi esportate è molto semplice per cui si può facilmente taroccare il file e inserire le chiavi private e pubbliche a proprio piacimento. Questo comporta che si possono stampare le chiavi private e pubbliche in chiaro su carta e superare il grosso problema della corruzione di dati che è la principale perdita di bitcoin (secondo me).

[corsaro]

una cosa simpatica: col wallet dogecoin-qt che uso per tenerci dentro i miei dogecoin, ho fatto tempo fa una transazione in uscita di 1 doge (all'epoca provai una semplice transazione da 1 doge per verificare un indirizzo); bene questa transazione mi ha creato un resto, in quanto ha prelevato il doge da una transazione in entrata di 5.470,3587351 doge;

solo che non riuscivo a trovare l'indirizzo interno del wallet dove mi aveva messo il resto..

cercando un po' per forum, ho trovato questo comando: listaddressgroupings

che mi ha elencato tutti gli indirizzi del mio wallet, che hanno un bilancio positivo



20:50:44

listaddressgroupings


20:50:45

[
[
[
"DL**gY**************************X",
490807.67656644,
""
],
[
"DK***3TxPE**********************C",
5469.35873510
]
]
]



e così, in pratica ho scoperto l'indirizzo dove era finito il resto... 

Volendo, con il comando: dumpprivkey DK***3TxPE**********************C  posso estrarre la chiave privata

[Sampey]

una cosa simpatica: col wallet dogecoin-qt che uso per tenerci dentro i miei dogecoin, ho fatto tempo fa una transazione in uscita di 1 doge (all'epoca provai una semplice transazione da 1 doge per verificare un indirizzo); bene questa transazione mi ha creato un resto, in quanto ha prelevato il doge da una transazione in entrata di 5.470,3587351 doge;

solo che non riuscivo a trovare l'indirizzo interno del wallet dove mi aveva messo il resto..

cercando un po' per forum, ho trovato questo comando: listaddressgroupings

che mi ha elencato tutti gli indirizzi del mio wallet, che hanno un bilancio positivo



20:50:44

listaddressgroupings


20:50:45

[
[
[
"DL**gY**************************X",
490807.67656644,
""
],
[
"DK***3TxPE**********************C",
5469.35873510
]
]
]



e così, in pratica ho scoperto l'indirizzo dove era finito il resto... 

Volendo, con il comando: dumpprivkey DK***3TxPE**********************C  posso estrarre la chiave privata

Esattamente, qua si apre il capitolo che le chiavi private presenti all'interno del Bitcoin-Qt (e derivati) sono pratiamente invisibili all'utente che crede di avere 1 indirizzo + tutti quelli dal lui creati. Quanto di più errato (almeno su bitcoin-qt) si possa pensare.

[corsaro]

una cosa simpatica: col wallet dogecoin-qt che uso per tenerci dentro i miei dogecoin, ho fatto tempo fa una transazione in uscita di 1 doge (all'epoca provai una semplice transazione da 1 doge per verificare un indirizzo); bene questa transazione mi ha creato un resto, in quanto ha prelevato il doge da una transazione in entrata di 5.470,3587351 doge;

solo che non riuscivo a trovare l'indirizzo interno del wallet dove mi aveva messo il resto..

cercando un po' per forum, ho trovato questo comando: listaddressgroupings

che mi ha elencato tutti gli indirizzi del mio wallet, che hanno un bilancio positivo



20:50:44

listaddressgroupings


20:50:45

[
[
[
"DL**gY**************************X",
490807.67656644,
""
],
[
"DK***3TxPE**********************C",
5469.35873510
]
]
]



e così, in pratica ho scoperto l'indirizzo dove era finito il resto...  

Volendo, con il comando: dumpprivkey DK***3TxPE**********************C  posso estrarre la chiave privata

Esattamente, qua si apre il capitolo che le chiavi private presenti all'interno del Bitcoin-Qt (e derivati) sono pratiamente invisibili all'utente che crede di avere 1 indirizzo + tutti quelli dal lui creati. Quanto di più errato (almeno su bitcoin-qt) si possa pensare.

si, ti posso garantire, che col comando "dumpprivkey address" sono riuscito ad avere la chiave privata dell'indirizzo su cui era finito il resto...  almeno sul wallet 1.8 per dogecoin. La stessa regola dovrebbe valere anche per bitcoin-qt.exe

Poi ovviamente, avendo la chiave privata, posso importare quell'indirizzo usato per il resto su un qualsiasi altro wallet.

In pratica, il comando magico è questo: listaddressgroupings
E' quello che ci mostra la situazione reale del nostro wallet, con tutti i resti che nasconde al suo interno

Un'altra cosa importante: se il nostro wallet è bloccato da password, prima di estrarre la chiave dobbiamo lanciare il seguente comando: walletpassphrase "my pass phrase" 60
per sbloccarlo per 60 secondi, altrimenti ci restituisce un errore

[Sampey]

Si lo avevo dovuto usare anche io per una migrazione completa da Bitcoin-QT a Multibit.
cioè volevo portarmi lo storico di tutte le transazioni sull'altro client, quindi dovevo per forza importate tutte le chiavi private di tutti gli indirizzi che avevano subito almeno una entrata.

[arulbero]

Bellissimo articolo che spiega bene cos'è un change address: http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/

Bellissimo articolo che spiega bene cos'è un change address: http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/

Consiglio a tutti di leggere questo articolo!!! Spiega davvero molto bene tutte le possibilità di perdita BTC causa change address e come prevenirle.

Dal momento che condivido l'apprezzamento per questo articolo ho chiesto all'autore se posso tradurlo in italiano.

EDIT: permesso ottenuto, ecco la versione italiana dell'articolo realizzata da me.

[acquafredda]

Questo è il problema maggiore riguardo la diffusione dei BTC a mio avviso. E anzi è un bel problema intrinseco al BTC stesso.
Poteva essere implementato meglio credo.

[arulbero]

Questo è il problema maggiore riguardo la diffusione dei BTC a mio avviso. E anzi è un bel problema intrinseco al BTC stesso.
Poteva essere implementato meglio credo.

Personalmente mi sono fatto l'idea che sia più un problema di come i diversi client implementano la gestione dei resti. Ad esempio nella guida c'è scritto che bitcoin-qt genera inizialmente un gruppo di 100 indirizzi casuali vuoti, e ogni volta che si utilizza un indirizzo (per la ricezione o per il resto) ne viene generato uno nuovo per rimpiazzare nel gruppo dei 100 quello appena utilizzato. E' chiaro che così facendo, se ho fatto il backup molto tempo fa, potrei trovarmi con una copia di sicurezza del tutto inutile, perchè gli indirizzi lì presenti potrebbero essere stati nel frattempo già tutti utilizzati e svuotati.

Dal mio punto di vista preferisco l'approccio deterministico tipo Armory, salvato il seed iniziale ho sempre tutti gli indirizzi, presenti e futuri, a disposizione e sotto controllo. E se inoltre il client che utilizzi mostra sempre tutti gli indirizzi (dei resti e non dei resti, almeno quelli contenenti output non spesi) e il bilancio totale in maniera chiara, non vedo quali altri problemi possano esserci.
Certo se poi vuoi fare operazioni "manuali" del tipo andare sul sito blockchain.info per verificare il contenuto di un certo indirizzo dopo un pagamento (e magari uno non sa leggere una transazione su blockchain.info) oppure vuoi importare una chiave privata da un paper wallet (magari senza sapere la differenza tra importare e fare uno sweep), allora no, non va bene, in quel caso bisogna prima aver capito bene il funzionamento del meccanismo del resto.

Ma per un utilizzo normale del bitcoin, sapere se un indirizzo ha 3 output non spesi da 1 btc l'uno o un unico output non speso da 3 btc, che differenza fa? Entrare nel dettaglio dei meccanismi con cui il client sceglie un indirizzo del resto piuttosto di un altro, oppure conoscere i criteri con cui decide se spendere un output prima di un altro, non portano a un sostanziale vantaggio dell'uso di questo sistema di pagamento.
Ripeto, il problema secondo me nasce soprattutto dal fatto che ci sono implementazioni diverse e alcune un po' strane dal mio punto di vista nella gestione di questo meccanismo. E se uno poi pensa al paragone tra i bitcoin e i contanti, come consigliato nella guida, il funzionamento dei resti non è davvero poi così strano.  

[arulbero]

@Ruggito :
Non so in che ordine vengano presi i soldi dal tuo portafoglio, se escano in ordine cronologico (le transazioni più vecchie escono per prime) e se si sommano transazioni fino a che non si raggiungere il valore di pagamento richiesto.

Cioè nell'esempio che sto facendo io :

Ricevo T1 : 1 BTC
Ricevo T2 : 2 BTC
Ricevo T3 : 3 BTC
Ricevo T4 : 4 BTC
Ricevo T5 : 1 BTC
Ricevo T6 : 0,5 BTC

Ho 11,5 BTC sul portafoglio

Devo pagare 6,5

6,5 viene calcolato come T1+T2+T3+T4 di cui 3,5 di T4 mi tornano su un indirizzo di resto.

Oppure se vengano prese in maniera intelligente tipo T4 + T2  + T6 = 6.5

L'algoritmo di selezione degli UTXO dal proprio portafoglio (Coin Select Algorithm), almeno per Bitcoin Core dovrebbe funzionare così:

1) Se uno degli UTXO del wallet corrisponde esattamente al pagamento da effettuare, viene selezionato quello

2) Se la somma di tutti gli UTXO minori del pagamento corrisponde esattamente al pagamento, vengono selezionati quelli

3) Se la somma di tutti gli UTXO minori del pagamento è inferiore al pagamento, viene selezionato allora il minore tra gli UTXO che eccede il pagamento ( generando così un resto più piccolo possibile )

4) Come ultima opzione viene effettuato un ciclo di 1000 combinazioni casuali degli UTXO presenti nel wallet, se una di queste combinazioni corrisponde esattamente alla cifra da inviare, il ciclo si interrompe e viene scelta quella combinazione di UTXO, altrimenti viene scelta la minore tra
    - la minore, all'interno del gruppo di 1000, tra le combinazioni che eccedono la cifra da inviare
    - il minore tra i singoli UTXO che eccedono la cifra da inviare

I vantaggi di questo criterio di selezione sono che spesso si hanno transazioni con pochi UTXO ( quindi basse fee), ogni tanto vengono riuniti molti piccoli UTXO, c'è un minimo di protezione della privacy perchè non è facile capire dall'esterno quali indirizzi appartengono allo stesso wallet. L'algoritmo, che è stato concepito per minimizzare l'entità dei resti, come svantaggio produce però alla lunga molti UTXO "piccoli".

Per avere una descrizione più precisa di questo algoritmo con l'aggiunta di qualche esempio basta leggersi la seguente spiegazione.

Da notare che l'intero processo è applicato prima solo all'insieme degli UTXO che hanno almeno 6 conferme (oppure 1 conferma per i btc che sono stati "mossi" all'interno dello stesso wallet), e in seguito, se questo insieme è vuoto/insufficiente a coprire il pagamento,  l'insieme degli UTXO su cui l'algoritmo va a cercare i fondi viene allargato in 2 passaggi successivi. I dettagli si trovano implementati nel codice sorgente in wallet.cpp nella funzione SelectCoins.

[El Emperador]

Bellissimo articolo che spiega bene cos'è un change address: http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/

Bellissimo articolo che spiega bene cos'è un change address: http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/

Consiglio a tutti di leggere questo articolo!!! Spiega davvero molto bene tutte le possibilità di perdita BTC causa change address e come prevenirle.

Dal momento che condivido l'apprezzamento per questo articolo ho chiesto all'autore se posso tradurlo in italiano.

EDIT: permesso ottenuto, ecco la versione italiana dell'articolo realizzata da me.

Grazie della traduzione  e continua a scrivere sul blog

Certo però che i 5 esempi proposti sembrano davvero estremi e con alto grado di idiozia da parte dei personaggi immaginari protagonisti 

[arulbero]

Grazie della traduzione e continua a scrivere sul blog

Bene, almeno ad una persona è servita la traduzione!  

Certo però che i 5 esempi proposti sembrano davvero estremi e con alto grado di idiozia da parte dei personaggi immaginari protagonisti  

I 5 casi sono forse un po' estremi ma sicuramente esemplificativi. La situazione più probabile è quella descritta nel paragrafo "Perdita parziale di fondi", se uno fa una copia di backup del wallet di Bitcoin Core e dopo effettua più di 100 transazioni che generano nuovi indirizzi, almeno una parte dei fondi rischia di perderli davvero qualora dovesse ripristinare quella copia di backup ormai datata. Comunque ho la sensazione che molti utenti (anche non alle prime armi) abbiano perso dei btc a causa degli indirizzi dei resti.