we non parlate forte che porta sfiga, e oggi siamo venerdi 17  quindi zitti tutti Io non sono scaramantico, ma finchè angrynerd non dice che salirà il prezzo io non vendo |
|
|
|
quindi anche i casinò in bitcoin sono illegali in italia? aspettiamo allora che li oscurino come quelli normali
Infatti alcuni casino in bitcoin sono bloccati dall'aams, a volte vedo il sito defacciato dalla pagina dell'avvertenza aams |
|
|
|
incredibile su come i volumi si siano progressivamente ridotti e di conseguenza stabilizzato il prezzo
non so se c'è correlazione fra le due cose (sono ignorante in economia) ma per adesso è cosi
Ci sono tanti bitcoin in buy e sell e con un basso volume non si rompono i muri |
|
|
|
Forse è il momento di ricomprare |
|
|
|
Sto sincronizzando poi vi dico se funziona tutto, una guida così dettagliata è rimasta sottovalutata, merita un tip! Pubblica un tuo address  |
|
|
|
dunque... sto cercando questi dati ma si trova un sacco di dati daily ma con tf intraday quasi niente. ho trovato questi dati qua, http://api.bitcoincharts.com/v1/csv/, ma la qualità è pessima per poterne ricavare uno storico un minimo affidabile per fare dei back test. su torrent non si trova niente. Qualcuno ha qualche risorsa da condividere con un minimo di 3 anni di storico? Mi basta un qualsiasi formato, poi lo converto io. mi servirebbe i dati OHLC. se non avete HL, mi basta OC. grazie! Vuoi creare un sito tipo bitcoinwisdom/bitcoinity? |
|
|
|
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! |
|
|
|
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: /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 $ 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 $ /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: $ 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. |
|
|
|
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 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 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.0http://wiki.supernet.org/wiki/How_To_Use_Bitcoin_RPC_In_IguanaVengono 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! |
|
|
|
Auguri di buon anno a tutti... dai ke in questi primi giorni del 2017 credo ke il BTC superi la soglia psicologica dei 1000 dollarucci lo avevo detto .. forse ero andato un po lungo ..ma si sfondano entro questa notte... piu ke sfondare il problema a questo punto è .. quale sarà il tetto? poi si salirà o si scenderà? ;-) happy 2017 bitcoin Nessuno lo può sapere, nessuno, eccetto uno. Angrynerd. |
|
|
|
Vorrei iniziare a far del trading con bitcoin, come potrei iniziare?
Con una laurea in Economia e Finanza. |
|
|
|
Nessuno lo dice,ma x me Paolo77, l'account, è egli stesso il tipo che s è fregato l'account e che ora tenta di rivenderlo x 2 btc
Cioè quasi 2000€, ovvero un prezzo totalmente fuori mercato.
È veramente uno schifo
Se cosi' fosse credo si possa parlare di estorsione o ricatto che a naso direi che son reati che è meglio evitare ... al quale si aggiunge il reato di furto di identità e di dati informatici ... Pvvio che al cracker non frega nulla in quanto si colleghera' da tor e avrà il suo sistema per proteggersi ... Non capisco pero' come mai non ci sia un sistema di recupero credenziali consegnando al titolare l'accesso. Esiste, ma purtroppo è il recupero password via email. Dovremmo cominciare ad utilizzare informazioni extra come numero di telefono o 2FA. |
|
|
|
ragazzi io credo che entro i primi 10 giorni di gennaio 2017, se non prima... sfondiamo i 1000$ tranquillamente Io credo che per il 2020 sfondiamo i 10.000,00 $/ BTC. Cordiali saluti. Credo sia alquanto surreale, il grande pump lo abbiamo ricevuto quando la Cina è entrata nel mercato, ora ci siamo tutti. |
|
|
|
È in atto un bellissimo pump e non c'è tanta attenzione a riguardo, ripopolate questo thread! Nel frattempo, condivido questa opera d'arte:  |
|
|
|
|
Ma non esisteva una opzione per scaricare solo gli ultimi blocchi in bitcoin core?
|
|
|
|
FORBES di Gennaio parla della rivoluzione nel mondo della Finanza  MUORO. Non so se ve ne siete accorti, ma angrynerd ci ha sempre preso, all 100% al contrario. Quando comprava sono sempre scesi, quando ha venduto sono sempre saliti. È il diventato l'oracolo dei bitcoin. |
|
|
|
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. |
|
|
|
|
Quest'anno babbo natale ci regala un pump da 829€/btc. HODL.
|
|
|
|
|
Show Posts
