Topic: L'enorme e (s)conosciuto problema del Resto nella transazioni (Read 13808 times)

condivido e ripeto sia uno dei maggiori punti negativi dell'intero ecosistema bitcoin.
Io stesso agli inizi persi frazioni di bitcoin poichè non avevo capito l'esistenza dei resti.

Da allora electrum...

Il sistema dei resti ha delle motivazioni di ordine
1) tecnico (il sistema è completamente basato sulle transazioni, non sugli indirizzi, quindi per poter spendere solo una parte di un UTXO bisognerebbe stravolgere l'intero impianto)
2) va nella direzione di una maggiore privacy
3) aumenta la sicurezza

Ma questo sistema può essere implementato in diversi modi, io preferisco di gran lunga i portafogli deterministici tipo Armory, dove è sufficiente conservare una stringa dalla quale si ricaveranno tutti gli indirizzi futuri, dei resti e non. La gestione dei resti di Bitcoin Core personalmente non mi convince, richiede un'ulteriore attenzione all'utente, e io penso che già diverse persone, pur tutt'altro che inesperte, abbiano perso dei btc a causa di un backup troppo vecchio. Forse alla base di questa scelta da parte dei sviluppatori di Bitcoin Core c'è l'esigenza di garantire la sicurezza maggiore possibile (se qualcuno mi ruba la stringa segreta del mio portafoglio Armory è come se mi rubasse in un colpo solo tutte le chiavi private del mio portafogli) ma in questo caso non so se il gioco valga la candela.

credo ne abbiamo già parlato, ma il sistema dei resti è alla base della sicurezza generale delle transazioni BTC.
Nel momento in cui io sposto dei fondi, da un qualsiasi indirizzo del mio wallet bitcoin-qt in pratica rivelo alla rete la chiave pubblica dell'indirizzo dove conservavo i fondi.
Ciò ovviamente non mi espone a grandissimi rischi, ma l'ideatore del bitcoin-qt, essendo un matematico, ben sapeva del rischio potenziale dei futuristici computer quantistici, e ha pensato bene di spostare il resto immediatamente su di un nuovo indirizzo di cui la rete non conosce chiave pubblica, per via del fatto che questo nuovo indirizzo non ha mai fatto transazioni in uscita.

Bitcoin-qt quindi mi mette il resto su un indirizzo nuovo proteggendo in tal modo il resto stesso, in quanto questa operazione fa parte di un sistema di protezione e sicurezza in generale (e anche di anonimizzazione in senso lato).

ovvio che dovro' fare spesso dei backup del wallet in modo tale da proteggermi da perdite di dati, in quanto non appena i 100 indirizzi nascosti ed inutilizzati saranno tutti esauriti, il wallet ne genererà casualmente altri 100 nuovi.

Bene, almeno ad una persona è servita la traduzione!  



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.

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 

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.

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.  

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.

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.

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.

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

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.

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

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

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

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

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

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

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

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.