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

[toga]

creai 3 indirizzi con btcqt x ricevere btc. a un certo punto avrei voluto che tutti i btc sparsi su i 3 confluissero in uno solo di questi, quindi ne scelsi uno e inviai tutti i btc del wallet. Il risultato fu che la transazione risultò nulla (payment to yourself)

Non esiste transazione nulla: infatti se clicchi su payment to yourself potrai verificare tramite il txid su qualsiasi block explorer l'effettivo passaggio di BTC tra gli indirizzi

ok, mi sembrava di ricordare che sull'iconcina sotto address ci fosse scritto N/A, sotto type: payment to yourself e sotto amount: 0.0;
per questo ho creduto che fosse nulla.

x curiosità riproverò in futuro, grazie

[1714644007]

1714644007

[1714644007]

1714644007

[1714644007]

1714644007

[1714644007]

1714644007

[1714644007]

1714644007

[1714644007]

1714644007

[Stemby]

Leggo ora questa discussione.

Premettendo che, come si consiglia vivamente su bitcoinpaperwallet.com, il paper wallet sarebbe da intendersi come usa e getta (ovvero, andrebbe svuotato interamente), ma che ognuno è libero di agire come crede, chiedo: ma Bitcoin Qt ora permette di importare chiavi private? Mi giunge nuova questa cosa...

[golikcoin]

l'ho importato solo su blockchain per ora me leggendo

If you are using Cold storage, a Paper wallet or generating vanity addresses you may have a need to import a Private key. Since Bitcoin-QT/bitcoind v0.6.0, you can import private keys using built-in RPC command importprivkey. Before v0.6.0, you needed to rely on third-party wallet.dat manipulation tool such as Pywallet.

qui dice come https://en.bitcoin.it/wiki/How_to_import_private_keys  

[Stemby]

l'ho importato solo su blockchain per ora me leggendo

If you are using Cold storage, a Paper wallet or generating vanity addresses you may have a need to import a Private key. Since Bitcoin-QT/bitcoind v0.6.0, you can import private keys using built-in RPC command importprivkey. Before v0.6.0, you needed to rely on third-party wallet.dat manipulation tool such as Pywallet.

qui dice come https://en.bitcoin.it/wiki/How_to_import_private_keys  

Per l'appunto, non è ancora possibile (e probabilmente non sarà mai possibile) se non da riga di comando, proprio perché gli sviluppatori scoraggiano apertamente questa pratica (vedansi i millemila warning).

Grazie, comunque: credo che chiarire questo punto sia utile per la lettura della discussione.

[Sampey]

Leggo ora questa discussione.

Premettendo che, come si consiglia vivamente su bitcoinpaperwallet.com, il paper wallet sarebbe da intendersi come usa e getta (ovvero, andrebbe svuotato interamente), ma che ognuno è libero di agire come crede, chiedo: ma Bitcoin Qt ora permette di importare chiavi private? Mi giunge nuova questa cosa...

Si, ed è anche discretamente semplice ora :

https://en.bitcoin.it/wiki/How_to_import_private_keys_v7%2B

Ok, è da riga di comando però davvero niente di chè

[Sandro kensan]

Visto che è semplice gestire le chiavi private e che io, come molti, uso Multibit, non sembra ai più esperti che la gestione del resto non porti a generare ulteriori chiavi private?

Ho capito che in Multibit il resto viene ritornato al wallet senza generazione di ulteriori private key. Nel caso di 1 chiave privata il resto viene inviato all'indirizzo bitcoin relativo. Quindi mi sembra ottimale (Multibit) per la gestione dei paper wallet.

Per esempio si importa su un wallet la priv key del paper wallet e quindi si possono spendere i btc che si vuole, il resto ritornerà nel paper wallet. Finita l'operazione si cancella il wallet e i soldi rimarranno nel paper wallet.

P.S. il problema con Multibit è che non permette di cancellare le priv key e che crea una chiave appena un wallet viene creato.

[Ruggito]

Hola: ho seguito il thread ma ho ancora qualche dubbio.

Esempio. Paper wallet 6 Btc e (sono niubbo) invio un pagamento da 1 Btc.I restanti 5 btc di resto vengono spediti su un altro indirizzo.

Ora: il paper wallet è vuoto, ma a quanto ho capito (correggetemi se sbaglio) la sua chiave privata apre anche l'indirizzo nuovo a cui è stato inviato il resto. Per cui, vado su blockexplorer.com, verifico a quale indirizzo è andato il resto e, a Dio piacendo, apro il wallet con la chiave privata del Paper.

Il ragionamento fila?

EDIT. Forse non fila. Mi sono informato meglio e a quanto ho capito ogni volta che viene creato un indirizzo (chiave pubblica) viene anche automaticamente generata la corrispondente chiave privata. Quindi, se ad ogni chiave privata corrisponde una ed una sola chiave pubblica, il resto della transazione lo saluto allegramente,e il fatto di sapere a che indirizzo è andato non mi aiuta.

[Sampey]

Hola: ho seguito il thread ma ho ancora qualche dubbio.

Esempio. Paper wallet 6 Btc e (sono niubbo) invio un pagamento da 1 Btc.I restanti 5 btc di resto vengono spediti su un altro indirizzo.

Ora: il paper wallet è vuoto, ma a quanto ho capito (correggetemi se sbaglio) la sua chiave privata apre anche l'indirizzo nuovo a cui è stato inviato il resto. Per cui, vado su blockexplorer.com, verifico a quale indirizzo è andato il resto e, a Dio piacendo, apro il wallet con la chiave privata del Paper.

Il ragionamento fila?

No la sua chiave privata apre solo l'indirizzo a cui è associata.
Tu hai importanto la chiave del paper wallet su un client (altrimenti no potevi pagarE).
Il resto si trova sull'indirizzo di resto che ha generato il client, e ha una chiave privata diversa.

[Ruggito]

Capito. Ora resta solo il dubbio (che mi sembra abbia anche tu), se ogni volta che viene fatta una transazione vengono presi in considerazione TUTTI gli input del portafoglio (quindi il portafoglio si svuota interamente ad ogni transazione) o semplicemente quelli necessari per coprire la transazione stessa (quindi il portafoglio si svuota parzialmente, ma sicuramente di una quantità superiore al pagamento previsto). Propenderei per la prima, ma aspetto altri pareri.

Una soluzione può essere quindi il portafoglio deterministico. Se si può creare offline, e se ha lo stesso grado di sicurezza si potrebbe usar quello (non mi sono ancora informato)

P.s. Stavo editando la risposta mentre mi stavi rispondendo 

[gbianchi]

P.s. Stavo editando la risposta mentre mi stavi rispondendo 

Si, fa sempre cosi'.
a volte risponde adirittura PRIMA che tu gli faccia la domanda

[Sampey]

P.s. Stavo editando la risposta mentre mi stavi rispondendo 

Si, fa sempre cosi'.
a volte risponde adirittura PRIMA che tu gli faccia la domanda

Ahahahahah 

@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

[Ruggito]

Appena ho un attimo di tempo tenterà il classico metodo della " prova empirica"  .

Vediamo se vengo a capo di qualcosa!

[gabridome]

Scusate ma ciò che leggo é diverso da quanto credo io.
1. Non é da confondere l'indirizzo con il portafoglio. Un portafoglio é un insieme di chiavi private e di indirizzi.
2. L'indirizzo si ricava con un'operazione matematica irreversibile dalla chiave pubblica che deriva con un'altra operazione irreversibile dalla chiave privata (questo é importante da sapere per dopo).
3. Il paper wallet può essere speso solo tramite un processo che prenda in esame tutti gli INPUT NON SPESI dell'indirizzo, scelga quello più adatto all'ammontare e firmi il fatto che questo input non speso é ora nella disponibilità di un altro indirizzo. Se l'ammontare della transazione é inferiore all'input scelto dal software, la differenza genera un altro output che é l'indirizzo stesso o un altro indirizzo generato o scelto dal software client. Tutto questo processo é gestito dal client che non manda in giro resti a casaccio (in blockchain la destinazione del resto si può scegliere tra quello di origine e gli altri indirizzi del portafoglio).
4. L'ammontare che si vuole spendere più il resto non danno esattamente l'input o gli input non spesi ma un ammontare leggermente inferiore. La differenza tra l'input (a questo punto speso dall'indirizzo di origine) e gli output costituisce la fee della transazione.

Da tutto ciò deriva che quando firmate una transazione dall'indirizzo in carta lo fate all'interno di un software che manda il resto degli input di origine non spesi o sugli indirizzi del portafoglio che usate o sull'indirizzo di origine quindi a mio parere c'é poco da preoccuparsi e un pò da studiare.

Detto questo é sempre buona regola SPENDERE COMPLETAMENTE in ogni transazione ciascun indirizzo di un portafoglio di carta ogni volta e questo per alcune ragioni:
1. Il portafoglio di carta se fatto bene ha le chiavi private che non hanno mai visto internet. Se lo usate il computer usa la chiave privata e quindi la sicurezza di questa non é più quella originaria.
2. L'indirizzo prima dell'utilizzo non é sulla blockchain e dopo sì e può essere usato nelle successive transazioni per risalire alle nostre spese (diciamo che l'indagine viene facilitata).
3. Vitalik Buterik ha individuato un grande colpo di genio di Satoshi: vi siete mai chiesti perché i soldi si mandano di norma ad un indirizzo bitcoin e non a una chiave pubblica? Perché é ipotizzabile che un giorno coi computer quantici sia possibile risalire alla chiave privata da quella pubblica ma sembra che sia molto più difficile risalire da un indirizzo alla sua chiave pubblica. Da tutto questo deriva che se un giorno l'algoritmo ecdsa verrà crackato i nostri soldi sui portafogli su carta saranno come su una scialuppa di salvataggio fino a quando la chiave pubblica non comparirà sulla rete. Sulla blockchain compare solo la chiave pubblica del mittente, quella del destinatario rimane celata.

Quando dico spendere completamente intendo che se ho un indirizzo su carta da 10 btc  e voglio spenderne 1 mi conviene: o importare la chiave privata in blockchain e stracciare l'indirizzo; In questo modo perdo la sicurezza della carta (che come abbiamo visto é elevatissima) oppure calcolare manualmente il resto da tutto l'importo dell'indirizzo e mandarlo nella stessa transazione su un altro indirizzo su carta.

Scusate la lungaggine:
Tl;DR: il meccanismo del resto é delicato ma il software client manda i resti solo agli indirizzi del portafoglio che gestisce o all'indirizzo di origine (in blockchain si può scegliere). Non é praticabile effettuare una transazione da un paper wallet senza un client.

[Ruggito]

[OT]
@gabridome
Grazie 1000 per la dritta:

3. Vitalik Buterik ha individuato un grande colpo di genio di Satoshi: vi siete mai chiesti perché i soldi si mandano di norma ad un indirizzo bitcoin e non a una chiave pubblica? Perché é ipotizzabile che un giorno coi computer quantici sia possibile risalire alla chiave privata da quella pubblica ma sembra che sia molto più difficile risalire da un indirizzo alla sua chiave pubblica. Da tutto questo deriva che se un giorno l'algoritmo ecdsa verrà crackato i nostri soldi sui portafogli su carta saranno come su una scialuppa di salvataggio fino a quando la chiave pubblica non comparirà sulla rete. Sulla blockchain compare solo la chiave pubblica del mittente, quella del destinatario rimane celata.

Ho trovato online le slides in cui spiega ciò..veramente interessante

 (https://dl.dropboxusercontent.com/u/7426164/Bitcoin/Quantum%20Computing%20and%20Bitcoin.pdf)

[fine OT]

[Sandro kensan]

Scusate ma ciò che leggo é diverso da quanto credo io.

Grazie della lunga e chiara spiegazione.

[gdassori]

ORA anche Mark Karpeles conosce l'enorme e (s)conosciuto problema del Resto nelle transazioni

[corsaro]

Visto che è semplice gestire le chiavi private e che io, come molti, uso Multibit, non sembra ai più esperti che la gestione del resto non porti a generare ulteriori chiavi private?

Ho capito che in Multibit il resto viene ritornato al wallet senza generazione di ulteriori private key. Nel caso di 1 chiave privata il resto viene inviato all'indirizzo bitcoin relativo. Quindi mi sembra ottimale (Multibit) per la gestione dei paper wallet.

Per esempio si importa su un wallet la priv key del paper wallet e quindi si possono spendere i btc che si vuole, il resto ritornerà nel paper wallet. Finita l'operazione si cancella il wallet e i soldi rimarranno nel paper wallet.

P.S. il problema con Multibit è che non permette di cancellare le priv key e che crea una chiave appena un wallet viene creato.

Si l'ho notato anch'io da diverso tempo. Multibit il resto lo manda all'indirizzo del wallet di partenza della somma.

Se uno vuole spendere dei BTC messi in un paper wallet, basta che si importa la chiave privata (secret key) su multibit (procedura semplicissima da GUI) e lui penserà a rimettere il resto dentro il paper wallet.
http://bitcoin.stackexchange.com/questions/14154/how-do-import-a-paper-private-key-into-multibit

Poi a quel punto, il resto si potrà inviare ad un nuovo paper wallet, sempre tramite multibit

[Stemby]

Se uno vuole spendere dei BTC messi in un paper wallet, basta che si importa la chiave privata (secret key) su multibit (procedura semplicissima da GUI) e lui penserà a rimettere il resto dentro il paper wallet.
http://bitcoin.stackexchange.com/questions/14154/how-do-import-a-paper-private-key-into-multibit

Poi a quel punto, il resto si potrà inviare ad un nuovo paper wallet, sempre tramite multibit

Se l'idea è di inviare il resto su un nuovo paper wallet (cosa buona è giusta, molto più sicura della procedura indicata da corsaro, che funziona solo grazie all'attuale implementazione di MultiBit), si può fare direttamente con un'unica transazione: basta indicare i due destinatari. Ovvero: se X è l'importo contenuto nel paper wallet e Y è l'importo da pagare, X-Y sarà il resto da mandare al nuovo paper wallet. Basta quindi fare un'unica transazione diretta a due destinatari, il secondo dei quali sarà il nuovo paper wallet per l'ammontare di X-Y. In questo modo non ci sarà alcun resto che possa essere perso.

Ciao!

[zoe]

Se uno vuole spendere dei BTC messi in un paper wallet, basta che si importa la chiave privata (secret key) su multibit (procedura semplicissima da GUI) e lui penserà a rimettere il resto dentro il paper wallet.
http://bitcoin.stackexchange.com/questions/14154/how-do-import-a-paper-private-key-into-multibit

Poi a quel punto, il resto si potrà inviare ad un nuovo paper wallet, sempre tramite multibit

Se l'idea è di inviare il resto su un nuovo paper wallet (cosa buona è giusta, molto più sicura della procedura indicata da corsaro, che funziona solo grazie all'attuale implementazione di MultiBit), si può fare direttamente con un'unica transazione: basta indicare i due destinatari. Ovvero: se X è l'importo contenuto nel paper wallet e Y è l'importo da pagare, X-Y sarà il resto da mandare al nuovo paper wallet. Basta quindi fare un'unica transazione diretta a due destinatari, il secondo dei quali sarà il nuovo paper wallet per l'ammontare di X-Y. In questo modo non ci sarà alcun resto che possa essere perso.

Ciao!

In questo caso bisogna calcolare le fee, o lo fa in automatico?

Edit: intendo qualora nel wallet non vi sia altro che l'importo importato con la private_key.

[Stemby]

Sì, la mia era effettivamente una semplificazione: occorre anche calcolare la commissione.

X = saldo del paper wallet
Y = importo da pagare
Z = commissione

La transazione avrà un importo di Y diretto al primo indirizzo, X-Y-Z al nuovo paper wallet; occorre inoltre impostare Z come commissione. In questo modo non ci sarà resto e il vecchio paper wallet resterà vuoto (e cestinabile).

Ciao!