BitCoin Core, sincronizzazione lentissima

[D4rkAng3l]

Ciao,
ho scaricato il wallet BitCoin Core (credo sia il wallet ufficiale, giusto?) e lo ho installato.

Inizialmente diceva che gli mancavano circa 4 anni di sincronizzazione...dopo tante ore (divise in giornate diverse, non ho tenuto il PC acceso 24 ore su 24) è arrivato a dire che gli manca ancora 1 anni e 20 settimane della blockchain.

Possibile che sia così lento? o ho qualche problema io?

Grazie

[lucolo]

Io ci ho messo intorno alle 24h, è estremamente lento ma alla fine si sincronizza. L'importante è vedere che il tempo si riduce, finchè la barra continua a progredire non hai problemi

[alexrossi]

Ciao,
ho scaricato il wallet BitCoin Core (credo sia il wallet ufficiale, giusto?) e lo ho installato.

Inizialmente diceva che gli mancavano circa 4 anni di sincronizzazione...dopo tante ore (divise in giornate diverse, non ho tenuto il PC acceso 24 ore su 24) è arrivato a dire che gli manca ancora 1 anni e 20 settimane della blockchain.

Possibile che sia così lento? o ho qualche problema io?

Grazie

Purtroppo è normale, se vuoi un client più veloce a sincronizzarsi prova multibit o electrum

[2Noob2Trade]

Tieni conto che deve scaricare oltre 20 gb di blockchain

[YaLixx]

Ma io invece credo che il problema sia chiaramente dovuto al fatto che tu non abbia mantenuto il PC acceso 24h su 24...
Io invece non trovo il numero di conto di Bitcoin Core. Lo richiedono come collegamento ad un sito per prelievi ma il wallet non ha un numero di conto.... bah... misteri. A voi è capitato?

[MarioV]

Tieni conto che deve scaricare oltre 20 gb di blockchain

Mi sembrava di aver letto recentemente che avesse appena superato i 100 😆
Comunque consiglio la lettura di questo https://bitcointalk.org/index.php?topic=1241459.0 ad opera del buon gbianchi

[Micio]

Tieni conto che deve scaricare oltre 20 gb di blockchain

Mi sembrava di aver letto recentemente che avesse appena superato i 100 😆
Comunque consiglio la lettura di questo https://bitcointalk.org/index.php?topic=1241459.0 ad opera del buon gbianchi

Eh, nel 2014 magari era sui 20gb

Siamo in necroposting.

[nutriagrigia]

consiglio di fare un backup ogni tanto della blockchain, mi e capitato d'aver perso tutto dopo un crash.
L'ultimo crash con l'ultima versione di bitcoincore non mi ha creato problemi, pero meglio non rischiare.
A suo tempo avevo provato a scaricare via torrent la blockchain, pero dopo bitcoincore me l'ha riconosciuta corrotta e quindi alla fine ho solo perso tempo. l'idea era buona comunque, nel senso che ci ci si mette poco a scaricarla via torrent. Ovviamente i puristi della sicurezza la considerano una via errata.

[Micio]

Ma non esisteva una opzione per scaricare solo gli ultimi blocchi in bitcoin core?

[nutriagrigia]

questo è un'aggiunta a quanto scritto sopra.
Visto che ci mette un sacco di tempo anche a me a sincronizzarsi con la blockchain, ogni tot tempo faccio in backup anche se non arrivo alla sincronizzazione completa. Uso rar5 che è veloce nell'operazione e mi faccio un unico file contenente la cartella con blockchain,  wallet e tutto quello che c'è. magari con una piccola percentuale dedicata al recupero dati in caso di danneggiamento dell'archivio rar.
Se qualcuno ha esperienze positive con lo scarico della blockchain via torrent, tipo una fonte attendibile, può fare cosa gradita a segnalarlo. A me non è andata bene.

[arulbero]

Alcune osservazioni:

il pruning serve solo a risparmiare spazio, il tempo necessario per il download + syncing è lo stesso

il vero collo di bottiglia è dato di solito dal processore e dall'hard disk; per usare il più possibile la ram invece dell'hard disk per il database degli UTXO impostare il parametro --dbcache=numero di mega (per default --dbcache=300, ma se avete molta memoria potete impostare --dbcache=4000 o --dbcache=6000); per usare più core per la verifica degli script impostare il parametro --par=2 (o 4 o quanti thread in parallelo volete utilizzare)

Avrete notato che quando si sincronizza Bitcoin Core per la prima volta, il tempo per scaricare e validare i primi 200000 blocchi è meno di 1 ora, per validare gli ultimi 10000 blocchi invece ormai il mio vecchio portatile impiega 7 ore  

Ovviamente i motivi sono molti (all'inizio i blocchi erano quasi vuoti, sui primi 295000 blocchi non si verificano le firme grazie ai checkpoint, ecc.), ma perché c'è ancora tanta differenza tra validare 1 blocco di 10 mesi fa e 1 blocco di 1 mese fa?

Innanzitutto considerate che man mano che si acquisiscono blocchi il database degli UTXO che deve essere costantemente aggiornato cresce e si complica, inoltre c'è la questione del numero di firme da verificare e del tempo di verifica che cresce in maniera quadratica all'aumentare del numero di firme presenti in ciascuna transazione, e questa situazione sta peggiorando vistosamente negli ultimi mesi:

se andate qui infatti -->  https://statoshi.info/dashboard/db/transactions , impostate il tempo a 1 anno e guardate l'ultimo grafico, quello intitolato: "sigops", osserverete come si sta complicando e appesantendo il lavoro di validazione dei full node soprattutto dall'estate in poi. Se le cose continueranno così, tra 1 anno sarà letteralmente impossibile per pc vecchi come il mio tentare una sincronizzazione da zero della blockchain.

Il controllo delle firme non è l'unico controllo da fare, tutti i vari controlli si possono dividere in 3 categorie:

The checks performed can be divided in three groups: A) block validity, B) linking and C) script validity. A includes rules like proof-of-work, amount generated, ... B is about whether transactions are not double spends. C is whether spends are done using the correct key. When downloading blocks, A and B are performed, and C after the last checkpoint. At startup, only A is performed ...

Pieter Wuille

Ai primi di dicembre ho dovuto reinstallare Bitcoin Unlimited (ho provato anche con Core, e da questo punto di vista sono la stessa cosa) :  6 giorni per riscaricare e validare i 100 giga di blocchi (portatile Intel Core 2 Duo CPU 8700 @2.53Hz, 4 GB di RAM, disco meccanico usb esterno), cpu sempre al massimo. Per questo ho affermato che tra 1 anno, visto che la pesantezza dei calcoli non cresce linearmente nel tempo, probabilmente mi ci vorranno 2 settimane o più.

Per il momento l'unica cosa che mi è venuta in mente è agire direttamente sui checkpoint, quindi ho modificato a mano la lista in questo modo:
                      file chainparams.cpp originale

Code:

        checkpointData = (CCheckpointData) {
            boost::assign::map_list_of
            ( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
            ( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
            ( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
            (105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
            (134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
            (168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
            (193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
            (210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
            (216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
            (225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
            (250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
            (279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
            (295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983")),
            1397080064, // * UNIX timestamp of last checkpoint block
            36544669,   // * total number of transactions between genesis and last checkpoint
                             //   (the tx=... number in the SetBestChain debug.log lines)
            60000.0     // * estimated number of transactions per day after checkpoint
       };

                   file chainparams.cpp modificato

Code:

        checkpointData = (CCheckpointData) {
            boost::assign::map_list_of
            ( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
            ( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
            ( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
            (105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
            (134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
            (168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
            (193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
            (210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
            (216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
            (225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
            (250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
            (279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
            (295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983"))
	    (445000, uint256S("0x000000000000000003287f1b7576b82af3c8927ae8af9a7398bdcbf9af378762")),
	    1482653647, // * UNIX timestamp of last checkpoint block
            181954097,  // * total number of transactions between genesis and last checkpoint
                               //   (the tx=... number in the SetBestChain debug.log lines)
            200000.0    // * estimated number of transactions per day after checkpoint	
        };

Ho ricompilato il tutto, e riprovato da zero a scaricare e sincronizzare: 33 ore il tempo totale, quindi il 75% circa del tempo risparmiato (che corrisponde al tempo necessario a verificare le firme dal blocco 295000 al blocco 445000!).
Ovviamente bisogna essere consapevoli che così facendo non si stanno effettuando una serie di controlli (quelli della categoria C citata da Wuille).



Per concludere esiste un progetto in rete (Iguana Core) nel quale è stato riscritto completamente il codice che implementa il protocollo bitcoin (non come Unlimited, che si basa su Core), anche se è a uno stadio iniziale:

https://bitco.in/forum/threads/iguana-parallel-sync-full-btc-blockchain-in-30-minutes-uses-half-the-space-but-starts-up-instant.911/

https://bitcointalk.org/index.php?topic=1377459.0

http://wiki.supernet.org/wiki/How_To_Use_Bitcoin_RPC_In_Iguana

Vengono promesse prestazioni incredibili proprio nella fase di sincronizzazione iniziale della blockchain, ci sono anche delle critiche, io non l'ho testato, vi segnalo solo che esiste.

[arulbero]

Se volete scaricare blockchain + chainstate, eccovi due link (non li ho testati personalmente):

http://en.blockchaindownload.nl/all_downloads

https://flo.sh/bitcoin-qt-bootstrap-dat/

Bisogna fidarsi ovviamente ...

[lucasan123]

Qualcuno sa come fare per configurarlo in maniera che i blocchi vengano salvati non sulla ssd ma su un altro hard disk? perchè ho solo 100 gb di spazio sull'ssd..............

ho dovuto abbandonare questo portafoglio... meglio usare electrum o copay anche se l'indirizzo cambia sempre

[arulbero]

bitcoind   --datadir=<dir>  (vedi https://en.bitcoin.it/wiki/Data_directory)

oppure dai un'occhiata a questo articolo: http://bitzuma.com/posts/moving-the-bitcoin-core-data-directory/

[nutriagrigia]

devono aver migliorato il client, un famigliare ha staccato la spina del pc mentre scaricava la blockchain.
Mi sono venuti i sudori freddi.
Ma incredibilmente e ripartito dal punto dov'era arrivato. Ottimo direi ver0.13.1, con vecchie versioni si corrompevano i dati e bisognava partire dall'inizio. Non so se sia stata fortuna ma è andata bene.

[Micio]

Alcune osservazioni:

il pruning serve solo a risparmiare spazio, il tempo necessario per il download + syncing è lo stesso

il vero collo di bottiglia è dato di solito dal processore e dall'hard disk; per usare il più possibile la ram invece dell'hard disk per il database degli UTXO impostare il parametro --dbcache=numero di mega (per default --dbcache=300, ma se avete molta memoria potete impostare --dbcache=4000 o --dbcache=6000); per usare più core per la verifica degli script impostare il parametro --par=2 (o 4 o quanti thread in parallelo volete utilizzare)

Avrete notato che quando si sincronizza Bitcoin Core per la prima volta, il tempo per scaricare e validare i primi 200000 blocchi è meno di 1 ora, per validare gli ultimi 10000 blocchi invece ormai il mio vecchio portatile impiega 7 ore 

Ovviamente i motivi sono molti (all'inizio i blocchi erano quasi vuoti, sui primi 295000 blocchi non si verificano le firme grazie ai checkpoint, ecc.), ma perché c'è ancora tanta differenza tra validare 1 blocco di 10 mesi fa e 1 blocco di 1 mese fa?

Innanzitutto considerate che man mano che si acquisiscono blocchi il database degli UTXO che deve essere costantemente aggiornato cresce e si complica, inoltre c'è la questione del numero di firme da verificare e del tempo di verifica che cresce in maniera quadratica all'aumentare del numero di firme presenti in ciascuna transazione, e questa situazione sta peggiorando vistosamente negli ultimi mesi:

se andate qui infatti -->  https://statoshi.info/dashboard/db/transactions , impostate il tempo a 1 anno e guardate l'ultimo grafico, quello intitolato: "sigops", osserverete come si sta complicando e appesantendo il lavoro di validazione dei full node soprattutto dall'estate in poi. Se le cose continueranno così, tra 1 anno sarà letteralmente impossibile per pc vecchi come il mio tentare una sincronizzazione da zero della blockchain.

Il controllo delle firme non è l'unico controllo da fare, tutti i vari controlli si possono dividere in 3 categorie:

The checks performed can be divided in three groups: A) block validity, B) linking and C) script validity. A includes rules like proof-of-work, amount generated, ... B is about whether transactions are not double spends. C is whether spends are done using the correct key. When downloading blocks, A and B are performed, and C after the last checkpoint. At startup, only A is performed ...

Pieter Wuille

Ai primi di dicembre ho dovuto reinstallare Bitcoin Unlimited (ho provato anche con Core, e da questo punto di vista sono la stessa cosa) :  6 giorni per riscaricare e validare i 100 giga di blocchi (portatile Intel Core 2 Duo CPU 8700 @2.53Hz, 4 GB di RAM, disco meccanico usb esterno), cpu sempre al massimo. Per questo ho affermato che tra 1 anno, visto che la pesantezza dei calcoli non cresce linearmente nel tempo, probabilmente mi ci vorranno 2 settimane o più.

Per il momento l'unica cosa che mi è venuta in mente è agire direttamente sui checkpoint, quindi ho modificato a mano la lista in questo modo:
                      file chainparams.cpp originale

Code:

        checkpointData = (CCheckpointData) {
            boost::assign::map_list_of
            ( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
            ( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
            ( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
            (105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
            (134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
            (168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
            (193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
            (210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
            (216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
            (225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
            (250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
            (279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
            (295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983")),
            1397080064, // * UNIX timestamp of last checkpoint block
            36544669,   // * total number of transactions between genesis and last checkpoint
                             //   (the tx=... number in the SetBestChain debug.log lines)
            60000.0     // * estimated number of transactions per day after checkpoint
       };

                   file chainparams.cpp modificato

Code:

        checkpointData = (CCheckpointData) {
            boost::assign::map_list_of
            ( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
            ( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
            ( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
            (105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
            (134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
            (168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
            (193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
            (210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
            (216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
            (225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
            (250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
            (279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
            (295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983"))
	    (445000, uint256S("0x000000000000000003287f1b7576b82af3c8927ae8af9a7398bdcbf9af378762")),
	    1482653647, // * UNIX timestamp of last checkpoint block
            181954097,  // * total number of transactions between genesis and last checkpoint
                               //   (the tx=... number in the SetBestChain debug.log lines)
            200000.0    // * estimated number of transactions per day after checkpoint	
        };

Ho ricompilato il tutto, e riprovato da zero a scaricare e sincronizzare: 33 ore il tempo totale, quindi il 75% circa del tempo risparmiato (che corrisponde al tempo necessario a verificare le firme dal blocco 295000 al blocco 445000!).
Ovviamente bisogna essere consapevoli che così facendo non si stanno effettuando una serie di controlli (quelli della categoria C citata da Wuille).



Per concludere esiste un progetto in rete (Iguana Core) nel quale è stato riscritto completamente il codice che implementa il protocollo bitcoin (non come Unlimited, che si basa su Core), anche se è a uno stadio iniziale:

https://bitco.in/forum/threads/iguana-parallel-sync-full-btc-blockchain-in-30-minutes-uses-half-the-space-but-starts-up-instant.911/

https://bitcointalk.org/index.php?topic=1377459.0

http://wiki.supernet.org/wiki/How_To_Use_Bitcoin_RPC_In_Iguana

Vengono promesse prestazioni incredibili proprio nella fase di sincronizzazione iniziale della blockchain, ci sono anche delle critiche, io non l'ho testato, vi segnalo solo che esiste.

Sapresti guidarci su come effettuare il pruning su Bitcoin Core? Io ho provato ma non riesco, potresti fare un step-by-step? Grazie!

[arulbero]

Sapresti guidarci su come effettuare il pruning su Bitcoin Core? Io ho provato ma non riesco, potresti fare un step-by-step? Grazie!

Premetto che non ho mai utilizzato in prima persona l'opzione --prune.
Ho visto il tuo messaggio poco fa, ho provato quindi ad utilizzare anch'io questa opzione:

Code:

/usr/local/bin/bitcoind --daemon --dbcache=500 --prune=1000

Al momento, è passata quasi 1 ora, mi sembra tutto a posto, cioè sta scaricando la blockchain. Per controllare l'andamento ci sono diversi metodi:

1) guardare direttamente nella directory .bitcoin

Code:

$ ls .bitcoin
banlist.dat  bitcoind.pid  blocks  chainstate  database  db.log  debug.log  peers.dat  wallet.dat

du -sh .bitcoin/blocks/
932M 	.bitcoin/blocks/

2) interrogare Bitcoin Core

Code:

$ /usr/local/bin/bitcoin-cli getblockchaininfo
{
  "chain": "main",
  "blocks": 161145,
  "headers": 446476,
  "bestblockhash": "0000000000000128bdc4fb617bf192e67e4344eacc851a1685e52456bb86ee14",
  "difficulty": 1159929.497224385,
  "mediantime": 1325974036,
  "verificationprogress": 0.006421549817822181,
  "chainwork": "00000000000000000000000000000000000000000000000b1e31a473190efc52",
  "pruned": true,
  "softforks": [
.......
  },
  "pruneheight": 0
}

3) controllare direttamente cosa c'è scritto nel file debug.log presente in .bitcoin:

Code:

$ less .bitcoin/debug.log

2017-01-03 18:36:32 Bitcoin version v0.13.1.0-03422e5-dirty
2017-01-03 18:36:32 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrela
y=1
2017-01-03 18:36:32 Prune configured to target 1000MiB on disk for block and undo files.
2017-01-03 18:36:32 Default data directory /home/antonio/.bitcoin
2017-01-03 18:36:32 Using data directory /home/antonio/.bitcoin
2017-01-03 18:36:32 Using config file /home/antonio/.bitcoin/bitcoin.conf
2017-01-03 18:36:32 Using at most 125 connections (1024 file descriptors available)
2017-01-03 18:36:32 Using 0 threads for script verification
2017-01-03 18:36:32 HTTP: creating work queue of depth 16
2017-01-03 18:36:32 No rpcpassword set - using random cookie authentication
2017-01-03 18:36:32 Generated RPC authentication cookie /home/antonio/.bitcoin/.cookie
2017-01-03 18:36:32 HTTP: starting 4 worker threads
2017-01-03 18:36:32 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2017-01-03 18:36:32 Using wallet wallet.dat
2017-01-03 18:36:32 init message: Verifying wallet...
2017-01-03 18:36:32 CDBEnv::Open: LogDir=/home/antonio/.bitcoin/database ErrorFile=/home/antonio/.bitcoin/db.log
2017-01-03 18:36:32 scheduler thread start
2017-01-03 18:36:32 Bound to [::]:8333
2017-01-03 18:36:32 Bound to 0.0.0.0:8333
2017-01-03 18:36:32 Cache configuration:
2017-01-03 18:36:32 * Using 2.0MiB for block index database
2017-01-03 18:36:32 * Using 8.0MiB for chain state database
2017-01-03 18:36:32 * Using 490.0MiB for in-memory UTXO set
2017-01-03 18:36:32 init message: Loading block index...
2017-01-03 18:36:32 Opening LevelDB in /home/antonio/.bitcoin/blocks/index
2017-01-03 18:36:32 Opened LevelDB successfully
2017-01-03 18:36:32 Using obfuscation key for /home/antonio/.bitcoin/blocks/index: 0000000000000000
2017-01-03 18:36:32 Opening LevelDB in /home/antonio/.bitcoin/chainstate
2017-01-03 18:36:32 Opened LevelDB successfully
2017-01-03 18:36:32 Wrote new obfuscate key for /home/antonio/.bitcoin/chainstate: de5edbe74059b21f
2017-01-03 18:36:32 Using obfuscation key for /home/antonio/.bitcoin/chainstate: de5edbe74059b21f
2017-01-03 18:36:32 LoadBlockIndexDB: last block file = 0
2017-01-03 18:36:32 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)
2017-01-03 18:36:32 Checking all blk files are present...
2017-01-03 18:36:32 LoadBlockIndexDB: transaction index disabled
2017-01-03 18:36:32 Initializing databases...
2017-01-03 18:36:32 Pre-allocating up to position 0x1000000 in blk00000.dat
2017-01-03 18:36:32 init message: Verifying blocks...
2017-01-03 18:36:32  block index              48ms
2017-01-03 18:36:32 init message: Loading wallet...
2017-01-03 18:36:32 nFileVersion = 130100
2017-01-03 18:36:32 Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total
2017-01-03 18:36:32 Performing wallet upgrade to 60000
2017-01-03 18:36:32 keypool added key 1, size=1
2017-01-03 18:36:32 keypool added key 2, size=2
2017-01-03 18:36:32 keypool added key 3, size=3
2017-01-03 18:36:32 keypool added key 4, size=4
2017-01-03 18:36:32 keypool added key 5, size=5
2017-01-03 18:36:32 keypool added key 6, size=6
2017-01-03 18:36:32 keypool added key 7, size=7
2017-01-03 18:36:32 keypool added key 8, size=8
2017-01-03 18:36:32 keypool added key 9, size=9
2017-01-03 18:36:32 keypool added key 10, size=10
2017-01-03 18:36:32 keypool added key 11, size=11
..........................................................................
2017-01-03 18:36:33 keypool added key 101, size=101
2017-01-03 18:36:33 keypool reserve 1
2017-01-03 18:36:33 keypool keep 1
2017-01-03 18:36:33  wallet                  853ms
2017-01-03 18:36:33 Unsetting NODE_NETWORK on prune mode
2017-01-03 18:36:33 init message: Pruning blockstore...
2017-01-03 18:36:33 UpdateTip: new best=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 version=0x00000001 log2_work=32.000022 tx=1 date='2009-01-03 18:15:05' progress=0.000000 cache=0.0MiB(0tx)
2017-01-03 18:36:33 mapBlockIndex.size() = 1
2017-01-03 18:36:33 nBestHeight = 0
2017-01-03 18:36:33 setKeyPool.size() = 100
2017-01-03 18:36:33 mapWallet.size() = 0
2017-01-03 18:36:33 mapAddressBook.size() = 1
2017-01-03 18:36:33 init message: Loading addresses...
2017-01-03 18:36:33 torcontrol thread start
2017-01-03 18:36:33 ERROR: Read: Failed to open file /home/antonio/.bitcoin/peers.dat
2017-01-03 18:36:33 Invalid or missing peers.dat; recreating
2017-01-03 18:36:33 init message: Loading banlist...
2017-01-03 18:36:33 ERROR: Read: Failed to open file /home/antonio/.bitcoin/banlist.dat
2017-01-03 18:36:33 Invalid or missing banlist.dat; recreating
2017-01-03 18:36:33 init message: Starting network threads...
2017-01-03 18:36:33 init message: Done loading
2017-01-03 18:36:33 msghand thread start
2017-01-03 18:36:33 opencon thread start
2017-01-03 18:36:33 addcon thread start
2017-01-03 18:36:33 net thread start
2017-01-03 18:36:33 dnsseed thread start
2017-01-03 18:36:33 Loading addresses from DNS seeds (could take a while)
2017-01-03 18:36:36 receive version message: /Satoshi:0.13.1/: version 70014, blocks=446473, us=95.233.46.111:54803, peer=1
2017-01-03 18:36:36 60 addresses found from DNS seeds
2017-01-03 18:36:36 dnsseed thread exit
2017-01-03 18:36:39 Pre-allocating up to position 0x100000 in rev00000.dat
2017-01-03 18:36:39 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 version=0x00000001 log2_work=33.000022 tx=2 date='2009-01-09 02:54:25' progress=0.000000 cache=0.0MiB(1tx)
2017-01-03 18:36:39 UpdateTip: new best=000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd height=2 version=0x00000001 log2_work=33.584985 tx=3 date='2009-01-09 02:55:44' progress=0.000000 cache=0.0MiB(2tx)
2017-01-03 18:36:39 UpdateTip: new best=0000000082b5015589a3fdf2d4baff403e6f0be035a5d9742c1cae6295464449 height=3 version=0x00000001 log2_work=34.000022 tx=4 date='2009-01-09 03:02:53' progress=0.000000 cache=0.0MiB(3tx)
2017-01-03 18:36:39 UpdateTip: new best=000000004ebadb55ee9096c9a2f8880e09da59c0d68b1c228da88e48844a1485 height=4 version=0x00000001 log2_work=34.32195 tx=5 date='2009-01-09 03:16:28' progress=0.000000 cache=0.0MiB(4tx)
2017-01-03 18:36:39 UpdateTip: new best=000000009b7262315dbf071787ad3656097b892abffd1f95a1a022f896f533fc height=5 version=0x00000001 log2_work=34.584985 tx=6 date='2009-01-09 03:23:48' progress=0.000000 cache=0.0MiB(5tx)
2017-01-03 18:36:39 UpdateTip: new best=000000003031a0e73735690c5a1ff2a4be82553b2a12b776fbd3a215dc8f778d height=6 version=0x00000001 log2_work=34.807377 tx=7 date='2009-01-09 03:29:49' progress=0.000000 cache=0.0MiB(6tx)
2017-01-03 18:36:39 UpdateTip: new best=0000000071966c2b1d065fd446b1e485b2c9d9594acd2007ccbd5441cfc89444 height=7 version=0x00000001 log2_work=35.000022 tx=8 date='2009-01-09 03:39:29' progress=0.000000 cache=0.0MiB(7tx)
2017-01-03 18:36:39 UpdateTip: new best=00000000408c48f847aa786c2268fc3e6ec2af68e8468a34a28c61b7f1de0dc6 height=8 version=0x00000001 log2_work=35.169947 tx=9 date='2009-01-09 03:45:43' progress=0.000000 cache=0.0MiB(8tx)
2017-01-03 18:36:39 UpdateTip: new best=000000008d9dc510f23c2657fc4f67bea30078cc05a90eb89e84cc475c080805 height=9 version=0x00000001 log2_work=35.32195 tx=10 date='2009-01-09 03:54:39' progress=0.000000 cache=0.0MiB(9tx)
2017-01-03 18:36:39 UpdateTip: new best=000000002c05cc2e78923c34df87fd108b22221ac6076c18f3ade378a4d915e9 height=10 version=0x00000001 log2_work=35.459454 tx=11 date='2009-01-09 04:05:52' progress=0.000000 cache=0.0MiB(10tx)
..............................................................

A me sembra tutto a posto.

Ti chiederei:
1) cosa usi, Windows o Linux?
2) quale versione di Bitcoin Core?
3) i parametri li passi a bitcoind via riga di comando o attraverso il file bitcoin.conf?
4) soprattutto, che tipo di problema hai incontrato? Riguarda la sincronizzazione, il bilancio del wallet o cosa?

Fammi sapere.



EDIT: Ricordo brevemente la storia del pruning in Bitcoin Core:

0.11.0   
introduzione del pruning    --> https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning
Block pruning is  incompatible with -txindex and will automatically disable it
Block pruning is currently incompatible with running a wallet due to the fact that block data is used  for rescanning the wallet and importing keys or addresses (which require a rescan.) However, running the wallet with block pruning will be supported in the near future, subject to those limitations.


0.12.0 --> https://github.com/bitcoin/bitcoin/blob/v0.12.0/doc/release-notes.md#wallet-pruning
With 0.12 it is possible to use wallet functionality in pruned mode. This can reduce the disk usage from currently around 60 GB to around 2 GB.
However, rescans as well as the RPCs  importwallet ,  importaddress ,  importprivkey  are disabled.


0.13.1
getblockchaininfo help: pruneheight is the lowest, not highest

[Micio]

Sapresti guidarci su come effettuare il pruning su Bitcoin Core? Io ho provato ma non riesco, potresti fare un step-by-step? Grazie!

Premetto che non ho mai utilizzato in prima persona l'opzione --prune.
Ho visto il tuo messaggio poco fa, ho provato quindi ad utilizzare anch'io questa opzione:

Code:

/usr/local/bin/bitcoind --daemon --dbcache=500 --prune=1000

Al momento, è passata quasi 1 ora, mi sembra tutto a posto, cioè sta scaricando la blockchain. Per controllare l'andamento ci sono diversi metodi:

1) guardare direttamente nella directory .bitcoin

Code:

$ ls .bitcoin
banlist.dat  bitcoind.pid  blocks  chainstate  database  db.log  debug.log  peers.dat  wallet.dat

du -sh .bitcoin/blocks/
932M 	.bitcoin/blocks/

2) interrogare Bitcoin Core

Code:

$ /usr/local/bin/bitcoin-cli getblockchaininfo
{
  "chain": "main",
  "blocks": 161145,
  "headers": 446476,
  "bestblockhash": "0000000000000128bdc4fb617bf192e67e4344eacc851a1685e52456bb86ee14",
  "difficulty": 1159929.497224385,
  "mediantime": 1325974036,
  "verificationprogress": 0.006421549817822181,
  "chainwork": "00000000000000000000000000000000000000000000000b1e31a473190efc52",
  "pruned": true,
  "softforks": [
.......
  },
  "pruneheight": 0
}

3) controllare direttamente cosa c'è scritto nel file debug.log presente in .bitcoin:

Code:

$ less .bitcoin/debug.log

2017-01-03 18:36:32 Bitcoin version v0.13.1.0-03422e5-dirty
2017-01-03 18:36:32 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrela
y=1
2017-01-03 18:36:32 Prune configured to target 1000MiB on disk for block and undo files.
2017-01-03 18:36:32 Default data directory /home/antonio/.bitcoin
2017-01-03 18:36:32 Using data directory /home/antonio/.bitcoin
2017-01-03 18:36:32 Using config file /home/antonio/.bitcoin/bitcoin.conf
2017-01-03 18:36:32 Using at most 125 connections (1024 file descriptors available)
2017-01-03 18:36:32 Using 0 threads for script verification
2017-01-03 18:36:32 HTTP: creating work queue of depth 16
2017-01-03 18:36:32 No rpcpassword set - using random cookie authentication
2017-01-03 18:36:32 Generated RPC authentication cookie /home/antonio/.bitcoin/.cookie
2017-01-03 18:36:32 HTTP: starting 4 worker threads
2017-01-03 18:36:32 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2017-01-03 18:36:32 Using wallet wallet.dat
2017-01-03 18:36:32 init message: Verifying wallet...
2017-01-03 18:36:32 CDBEnv::Open: LogDir=/home/antonio/.bitcoin/database ErrorFile=/home/antonio/.bitcoin/db.log
2017-01-03 18:36:32 scheduler thread start
2017-01-03 18:36:32 Bound to [::]:8333
2017-01-03 18:36:32 Bound to 0.0.0.0:8333
2017-01-03 18:36:32 Cache configuration:
2017-01-03 18:36:32 * Using 2.0MiB for block index database
2017-01-03 18:36:32 * Using 8.0MiB for chain state database
2017-01-03 18:36:32 * Using 490.0MiB for in-memory UTXO set
2017-01-03 18:36:32 init message: Loading block index...
2017-01-03 18:36:32 Opening LevelDB in /home/antonio/.bitcoin/blocks/index
2017-01-03 18:36:32 Opened LevelDB successfully
2017-01-03 18:36:32 Using obfuscation key for /home/antonio/.bitcoin/blocks/index: 0000000000000000
2017-01-03 18:36:32 Opening LevelDB in /home/antonio/.bitcoin/chainstate
2017-01-03 18:36:32 Opened LevelDB successfully
2017-01-03 18:36:32 Wrote new obfuscate key for /home/antonio/.bitcoin/chainstate: de5edbe74059b21f
2017-01-03 18:36:32 Using obfuscation key for /home/antonio/.bitcoin/chainstate: de5edbe74059b21f
2017-01-03 18:36:32 LoadBlockIndexDB: last block file = 0
2017-01-03 18:36:32 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)
2017-01-03 18:36:32 Checking all blk files are present...
2017-01-03 18:36:32 LoadBlockIndexDB: transaction index disabled
2017-01-03 18:36:32 Initializing databases...
2017-01-03 18:36:32 Pre-allocating up to position 0x1000000 in blk00000.dat
2017-01-03 18:36:32 init message: Verifying blocks...
2017-01-03 18:36:32  block index              48ms
2017-01-03 18:36:32 init message: Loading wallet...
2017-01-03 18:36:32 nFileVersion = 130100
2017-01-03 18:36:32 Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total
2017-01-03 18:36:32 Performing wallet upgrade to 60000
2017-01-03 18:36:32 keypool added key 1, size=1
2017-01-03 18:36:32 keypool added key 2, size=2
2017-01-03 18:36:32 keypool added key 3, size=3
2017-01-03 18:36:32 keypool added key 4, size=4
2017-01-03 18:36:32 keypool added key 5, size=5
2017-01-03 18:36:32 keypool added key 6, size=6
2017-01-03 18:36:32 keypool added key 7, size=7
2017-01-03 18:36:32 keypool added key 8, size=8
2017-01-03 18:36:32 keypool added key 9, size=9
2017-01-03 18:36:32 keypool added key 10, size=10
2017-01-03 18:36:32 keypool added key 11, size=11
..........................................................................
2017-01-03 18:36:33 keypool added key 101, size=101
2017-01-03 18:36:33 keypool reserve 1
2017-01-03 18:36:33 keypool keep 1
2017-01-03 18:36:33  wallet                  853ms
2017-01-03 18:36:33 Unsetting NODE_NETWORK on prune mode
2017-01-03 18:36:33 init message: Pruning blockstore...
2017-01-03 18:36:33 UpdateTip: new best=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 version=0x00000001 log2_work=32.000022 tx=1 date='2009-01-03 18:15:05' progress=0.000000 cache=0.0MiB(0tx)
2017-01-03 18:36:33 mapBlockIndex.size() = 1
2017-01-03 18:36:33 nBestHeight = 0
2017-01-03 18:36:33 setKeyPool.size() = 100
2017-01-03 18:36:33 mapWallet.size() = 0
2017-01-03 18:36:33 mapAddressBook.size() = 1
2017-01-03 18:36:33 init message: Loading addresses...
2017-01-03 18:36:33 torcontrol thread start
2017-01-03 18:36:33 ERROR: Read: Failed to open file /home/antonio/.bitcoin/peers.dat
2017-01-03 18:36:33 Invalid or missing peers.dat; recreating
2017-01-03 18:36:33 init message: Loading banlist...
2017-01-03 18:36:33 ERROR: Read: Failed to open file /home/antonio/.bitcoin/banlist.dat
2017-01-03 18:36:33 Invalid or missing banlist.dat; recreating
2017-01-03 18:36:33 init message: Starting network threads...
2017-01-03 18:36:33 init message: Done loading
2017-01-03 18:36:33 msghand thread start
2017-01-03 18:36:33 opencon thread start
2017-01-03 18:36:33 addcon thread start
2017-01-03 18:36:33 net thread start
2017-01-03 18:36:33 dnsseed thread start
2017-01-03 18:36:33 Loading addresses from DNS seeds (could take a while)
2017-01-03 18:36:36 receive version message: /Satoshi:0.13.1/: version 70014, blocks=446473, us=95.233.46.111:54803, peer=1
2017-01-03 18:36:36 60 addresses found from DNS seeds
2017-01-03 18:36:36 dnsseed thread exit
2017-01-03 18:36:39 Pre-allocating up to position 0x100000 in rev00000.dat
2017-01-03 18:36:39 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 version=0x00000001 log2_work=33.000022 tx=2 date='2009-01-09 02:54:25' progress=0.000000 cache=0.0MiB(1tx)
2017-01-03 18:36:39 UpdateTip: new best=000000006a625f06636b8bb6ac7b960a8d03705d1ace08b1a19da3fdcc99ddbd height=2 version=0x00000001 log2_work=33.584985 tx=3 date='2009-01-09 02:55:44' progress=0.000000 cache=0.0MiB(2tx)
2017-01-03 18:36:39 UpdateTip: new best=0000000082b5015589a3fdf2d4baff403e6f0be035a5d9742c1cae6295464449 height=3 version=0x00000001 log2_work=34.000022 tx=4 date='2009-01-09 03:02:53' progress=0.000000 cache=0.0MiB(3tx)
2017-01-03 18:36:39 UpdateTip: new best=000000004ebadb55ee9096c9a2f8880e09da59c0d68b1c228da88e48844a1485 height=4 version=0x00000001 log2_work=34.32195 tx=5 date='2009-01-09 03:16:28' progress=0.000000 cache=0.0MiB(4tx)
2017-01-03 18:36:39 UpdateTip: new best=000000009b7262315dbf071787ad3656097b892abffd1f95a1a022f896f533fc height=5 version=0x00000001 log2_work=34.584985 tx=6 date='2009-01-09 03:23:48' progress=0.000000 cache=0.0MiB(5tx)
2017-01-03 18:36:39 UpdateTip: new best=000000003031a0e73735690c5a1ff2a4be82553b2a12b776fbd3a215dc8f778d height=6 version=0x00000001 log2_work=34.807377 tx=7 date='2009-01-09 03:29:49' progress=0.000000 cache=0.0MiB(6tx)
2017-01-03 18:36:39 UpdateTip: new best=0000000071966c2b1d065fd446b1e485b2c9d9594acd2007ccbd5441cfc89444 height=7 version=0x00000001 log2_work=35.000022 tx=8 date='2009-01-09 03:39:29' progress=0.000000 cache=0.0MiB(7tx)
2017-01-03 18:36:39 UpdateTip: new best=00000000408c48f847aa786c2268fc3e6ec2af68e8468a34a28c61b7f1de0dc6 height=8 version=0x00000001 log2_work=35.169947 tx=9 date='2009-01-09 03:45:43' progress=0.000000 cache=0.0MiB(8tx)
2017-01-03 18:36:39 UpdateTip: new best=000000008d9dc510f23c2657fc4f67bea30078cc05a90eb89e84cc475c080805 height=9 version=0x00000001 log2_work=35.32195 tx=10 date='2009-01-09 03:54:39' progress=0.000000 cache=0.0MiB(9tx)
2017-01-03 18:36:39 UpdateTip: new best=000000002c05cc2e78923c34df87fd108b22221ac6076c18f3ade378a4d915e9 height=10 version=0x00000001 log2_work=35.459454 tx=11 date='2009-01-09 04:05:52' progress=0.000000 cache=0.0MiB(10tx)
..............................................................

A me sembra tutto a posto.

Ti chiederei:
1) cosa usi, Windows o Linux?
2) quale versione di Bitcoin Core?
3) i parametri li passi a bitcoind via riga di comando o attraverso il file bitcoin.conf?
4) soprattutto, che tipo di problema hai incontrato? Riguarda la sincronizzazione, il bilancio del wallet o cosa?

Fammi sapere.



EDIT: Ricordo brevemente la storia del pruning in Bitcoin Core:

0.11.0
introduzione del pruning
Block pruning is  incompatible with -txindex and will automatically disable it
Block pruning is currently incompatible with running a wallet due to the fact that block data is used  for rescanning the wallet and importing keys or addresses (which require a rescan.) However, running the wallet with block pruning will be supported in the near future, subject to those limitations.


0.12.0
With 0.12 it is possible to use wallet functionality in pruned mode. This can reduce the disk usage from currently around 60 GB to around 2 GB.
However, rescans as well as the RPCs  importwallet ,  importaddress ,  importprivkey  are disabled.


0.13.1
getblockchaininfo help: pruneheight is the lowest, not highest

1. Uso Bitcoin Core per Windows, non bitcoind
2. 0.12.1 al momento
3. Tramite link perchè non trovo il bitcoin.conf ahahah
4. Non ho idea di come si faccia il pruning, ho provato a mettere --prune=1000 ma è come se lo evitasse, eppure -datadir funziona.

[arulbero]

1. Uso Bitcoin Core per Windows, non bitcoind
2. 0.12.1 al momento
3. Tramite link perchè non trovo il bitcoin.conf ahahah
4. Non ho idea di come si faccia il pruning, ho provato a mettere --prune=1000 ma è come se lo evitasse, eppure -datadir funziona.

Guarda, più tardi allora faccio una prova anche con Windows, e poi ti faccio sapere la procedura esatta (se ci riesco)  
A dopo

[Micio]

1. Uso Bitcoin Core per Windows, non bitcoind
2. 0.12.1 al momento
3. Tramite link perchè non trovo il bitcoin.conf ahahah
4. Non ho idea di come si faccia il pruning, ho provato a mettere --prune=1000 ma è come se lo evitasse, eppure -datadir funziona.

Guarda, più tardi allora faccio una prova anche con Windows, e poi ti faccio sapere la procedura esatta (se ci riesco) 
A dopo

Grazie!