Sto sincronizzando poi vi dico se funziona tutto, una guida così dettagliata è rimasta sottovalutata, merita un tip! Pubblica un tuo address  Eccolo: 12RVQhs5skiwRYRzbYyVu5BFHwovUaxpB5 e grazie  |
|
|
|
Vi linko un articolo molto lungo ma anche molto interessante sulla situazione economica attuale internazionale, in particolare in esso si spiega il perchè si sta andando (e si è già arrivati in alcuni paesi) verso tassi di interessi negativi, tassi che da alcuni risparmiatori sono paradossalmente accettati poichè è il prezzo che pagano per sentirsi (falsamente) sicuri della custodia del loro denaro; i tassi negativi invece di favorire gli investimenti spingono le persone a tenere soldi in casa o a investire in riserve di valore (o almeno percepite come tali) come il mattone nel caso dei paesi scandinavi; vari governi stanno attuando una conseguente lotta contro l'uso del contante come riserva di valore (i tagli più grossi vengono ritirati esplicitamente in alcuni paesi, in altri stanno comunque diminuendo) sperando di dirottare quel denaro verso un'economia che gira sempre più piano poichè la capacità produttiva ormai supera la domanda in molti settori. L'articolo accenna anche alla situazione italiana, molto preoccupante per quanto riguarda l'aumento dei prestiti "deteriorati": Italy’s non-performing loans have gone from about 5 percent in 2010 to over 15 percent today
In confronto la "bolla" del bitcoin non è niente ... |
|
|
|
nella pratica quindi come potrei fare per provare ad inviare la transazione? devo installare quel client modificato? se è un clone di core immagino che scaricherà l'intera blockchain.
Penso proprio di sì, servirà l'intera blockchain. Ma soprattutto poi ci deve essere un miner che utilizza quel client con quella opzione attivata che accetti la tua transazione nella sua mempool e riesca a minare un blocco. |
|
|
|
Ho notato che nell'ultima versione di Bitcoin Knots --> http://bitcoinknots.org/ (si trova anche nella pagina https://bitcoin.org/en/choose-your-wallet ) c'è la possibilità per i miner di disabilitare i controlli sulle transazioni non standard -acceptnonstdtxn : option to skip "non-standard transaction" checks
quindi in questo caso si apre una possibilità per la tua transazione dust, a patto di trovare un miner che utilizzi quel client con quella opzione attivata. Qui si trova una lista di 3 client che modificano Core senza creare fork. |
|
|
|
I'd like to point the fellow readers' attention to my signature. If you care to remember, you saw there around 500000 keys/s per CPU core, today maybe shortly some 617 000 keys/s per CPU core and now we are at ~ 712000 keys/s per CPU core. It's all on the same machine (my notebook E3-1505M CPU). So what's the reason for the speed bump? It's simple. Pieter Wuille can't program. Or RyanC or both. Exaggerating - of course. There's nothing wrong with their programming skills - mine are just better.  The secp256k1 library wants to convert a field element to a 32-byte big endian value like this: ............................................................. This seems a little bit awkward to me. All these computations and n(i|y)bble bashing must certainly eat up CPU cycles. My take on it (5x52 field): static void hrdec_fe_get_b32(uchar *r, const secp256k1_fe *a) {
r[31] = a->n[0] & 0xFF; // i = 0
r[30] = (a->n[0] >> 8) & 0xFF; // i = 1
r[29] = (a->n[0] >> 16) & 0xFF; // i = 2
r[28] = (a->n[0] >> 24) & 0xFF; // i = 3
r[27] = (a->n[0] >> 32) & 0xFF; // i = 4
r[26] = (a->n[0] >> 40) & 0xFF; // i = 5
r[25] = ((a->n[0] >> 48) & 0xF) // i = 6
| ((a->n[1] & 0xF) << 4);
r[24] = (a->n[1] >> 4) & 0xFF; // i = 7
r[23] = (a->n[1] >> 12) & 0xFF; // i = 8
r[22] = (a->n[1] >> 20) & 0xFF; // i = 9
r[21] = (a->n[1] >> 28) & 0xFF; // i = 10
r[20] = (a->n[1] >> 36) & 0xFF; // i = 11
r[19] = (a->n[1] >> 44) & 0xFF; // i = 12
r[18] = a->n[2] & 0xFF; // i = 13
r[17] = (a->n[2] >> 8) & 0xFF; // i = 14
r[16] = (a->n[2] >> 16) & 0xFF; // i = 15
r[15] = (a->n[2] >> 24) & 0xFF; // i = 16
r[14] = (a->n[2] >> 32) & 0xFF; // i = 17
r[13] = (a->n[2] >> 40) & 0xFF; // i = 18
r[12] = ((a->n[2] >> 48) & 0xF) // i = 19
| ((a->n[3] & 0xF) << 4);
r[11] = (a->n[3] >> 4) & 0xFF; // i = 20
r[10] = (a->n[3] >> 12) & 0xFF; // i = 21
r[9] = (a->n[3] >> 20) & 0xFF; // i = 22
r[8] = (a->n[3] >> 28) & 0xFF; // i = 23
r[7] = (a->n[3] >> 36) & 0xFF; // i = 24
r[6] = (a->n[3] >> 44) & 0xFF; // i = 25
r[5] = a->n[4] & 0xFF; // i = 26
r[4] = (a->n[4] >> 8) & 0xFF; // i = 27
r[3] = (a->n[4] >> 16) & 0xFF; // i = 28
r[2] = (a->n[4] >> 24) & 0xFF; // i = 29
r[1] = (a->n[4] >> 32) & 0xFF; // i = 30
r[0] = (a->n[4] >> 40) & 0xFF; // i = 31
}
Have you seen this version of secp256k1 library? https://github.com/llamasoft/secp256k1_fast_unsafe |
|
|
|
Signature verification isn't really the limiting factor in Bitcoin Core performance anymore in any case.
I thought signature verification was the biggest limiting factor in IBD process (obviously with slow CPU). |
|
|
|
ok grazie, per curiosità che sito/programma hai usato per creare la transazione?
coinb.in per creare e firmare, https://blockchain.info/it/decode-tx per visualizzarla in formato leggibile. |
|
|
|
ah ok, ora provo a correggere. Ma nella casella "Address, WIF key or Multisig Redeem Script:" cosa devo mettere? la chiave privata?
Mai usata, ho creato questa transazione senza firma: 0100000001a4149949ed8e2aee21174b3fa85288561777e347795d0162093735436a9423bc000000001976a914a90cf97578df33b7d261105f3ba7b7297fd3f77d88acffffffff01e0c81000000000001976a914ed766419e42b2b7bc1121fa2da949a104d9fbafa88ac00000000
e poi l'ho firmata con la tua chiave privata: 0100000001a4149949ed8e2aee21174b3fa85288561777e347795d0162093735436a9423bc000000008b48304502210088e67c2c15c180ef0ab1aa080fd0be96def4047c39a4f220b40f29d7edf3832e022020864f5f4edee7d5c508171bf7c11234c661e3513ccdb323c05b17287353d7a50141041e18446ed1b491d776f8593efbd514b4fa0536996406d3983a5b76eaa8958d1bd67cb498be16c276008d89c13eb79e0287936c2339bbfadd2f5ba48a604415f5ffffffff01e0c81000000000001976a914ed766419e42b2b7bc1121fa2da949a104d9fbafa88ac00000000
{
"lock_time":0,
"size":224,
"inputs":[
{
"prev_out":{
"index":0,
"hash":"bc23946a4335370962015d7947e37717568852a83f4b1721ee2a8eed499914a4"
},
"script":"48304502210088e67c2c15c180ef0ab1aa080fd0be96def4047c39a4f220b40f29d7edf3832e022020864f5f4edee7d5c508171bf7c11234c661e3513ccdb323c05b17287353d7a50141041e18446ed1b491d776f8593efbd514b4fa0536996406d3983a5b76eaa8958d1bd67cb498be16c276008d89c13eb79e0287936c2339bbfadd2f5ba48a604415f5"
}
],
"version":1,
"vin_sz":1,
"hash":"dbfe0f0893e18ed3706c07bda7d937accf67aa587f2fa33ddba4f09e8c0c6e70",
"vout_sz":1,
"out":[
{
"script_string":"OP_DUP OP_HASH160 ed766419e42b2b7bc1121fa2da949a104d9fbafa OP_EQUALVERIFY OP_CHECKSIG",
"address":"1NeayR8k319gy3ygDs1SBkdTw4VpY5AbMc",
"value":1100000,
"script":"76a914ed766419e42b2b7bc1121fa2da949a104d9fbafa88ac"
}
]
}
|
|
|
|
beh però la mia domanda era, ipotizzando che la prima transazione venga accettata, la seconda è fatta in modo corretto? Ho provato a farla con coinb ma non so se ho selezionato gli input correttamente.
No, devi selezionare il primo input (index = 0), con index = 1 stai cercando di spendere il secondo output {
"lock_time":0,
"size":223,
"inputs":[
{
"prev_out":{
"index":1,
"hash":"bc23946a4335370962015d7947e37717568852a83f4b1721ee2a8eed499914a4"
},
"script":"47304402201e143becfbc35268575711e73958bc0153bde0704bb52c54e585097b833cabd8022028fcca1f746d847289ab85bd91b5e1a8e543ea6fb11da3a14e4d9e34a20bbc230141041e18446ed1b491d776f8593efbd514b4fa0536996406d3983a5b76eaa8958d1bd67cb498be16c276008d89c13eb79e0287936c2339bbfadd2f5ba48a604415f5"
}
],
"version":1,
"vin_sz":1,
"hash":"c6de7d06cc99d9eb017925528cd5dd3d866fc02c1fce7dd98069d17d0bab69b0",
"vout_sz":1,
"out":[
{
"script_string":"OP_DUP OP_HASH160 ed766419e42b2b7bc1121fa2da949a104d9fbafa OP_EQUALVERIFY OP_CHECKSIG",
"address":"1NeayR8k319gy3ygDs1SBkdTw4VpY5AbMc",
"value":1100000,
"script":"76a914ed766419e42b2b7bc1121fa2da949a104d9fbafa88ac"
}
]
}
|
|
|
|
Se hai firmato quest'ultima transazione con la firma relativa all'indirizzo 1GQrjuC59UuDv3LqbhPHX5mREDY4521f12 (quello a cui erano destinati i bitcoin inizialmente), rimarrebbe comunque un output non speso nella prima transazione: 0.00000000 btc --> 1FWY5DxbgVSBbCwCDMwsgSPUCKQKWfjYWa Motivo per cui non penso possa essere accettata neanche la seconda transazione. Il problema è che se venisse confermata la vecchia transazione si creerebbe un output "dust" nel database degli UTXO, e questo non è consentito. Ricordo qual era la tua vecchia transazione che ha dato origine a tutta la questione: {
"lock_time":370500,
"size":258,
"inputs":[
{
"prev_out":{
"index":0,
"hash":"c5a020009a7f9a2c0b9a2167ee95fc833c87b2df4e2bf8e85356c4fa810ece47"
},
"script":"48304502205814f0c588383a38c00b7f9d2317f2aeb2649e60dd341e603b22ae79f334f83c02210094a35f42d1c9f32ea700e66354ecd457ab2bcf0247865cb037be886569a5ac7f014104227f4a6de87d345dc08601920c1ab8b9bf4a76868e053f5f90faf307bcf0d72b014be36394a1f8a98bd8f2e5bb2243464fa67eee14e5cfc0888d7f15b7b2a110"
}
],
"version":1,
"vin_sz":1,
"hash":"bc23946a4335370962015d7947e37717568852a83f4b1721ee2a8eed499914a4",
"vout_sz":2,
"out":[
{
"script_string":"OP_DUP OP_HASH160 a90cf97578df33b7d261105f3ba7b7297fd3f77d OP_EQUALVERIFY OP_CHECKSIG",
"address":"1GQrjuC59UuDv3LqbhPHX5mREDY4521f12",
"value":1299300,
"script":"76a914a90cf97578df33b7d261105f3ba7b7297fd3f77d88ac"
},
{
"script_string":"OP_DUP OP_HASH160 9f27c31c0bf89cb4958e7fc99c0f9117623b4e4b OP_EQUALVERIFY OP_CHECKSIG",
"address":"1FWY5DxbgVSBbCwCDMwsgSPUCKQKWfjYWa",
"value":0,
"script":"76a9149f27c31c0bf89cb4958e7fc99c0f9117623b4e4b88ac"
}
]
}
Per non inquinare gli UTXO bisognerebbe riuscire a sostituire l'ultimo pezzo della transazione con qualcosa del genere: {
"script_string":"OP_RETURNquellochevuoi",
"value":0,
"script":"6a13quellochevuoi"
}
ma non avendo più la firma iniziale, non c'è modo di fare questa modifica senza alterare l'hash che deve essere poi firmato. In teoria si potrebbe mantenere la firma iniziale che si trova nello scriptSig di input, ma allora bisognerebbe riuscire a modificare a tentativi la stringa "quellochevuoi" fintanto da riprodurre lo stesso sha256 iniziale, cioè dovresti ottenere una collisione in sha256  |
|
|
|
|
Vista in un altro modo, 1 centesimo di euro (la frazione più piccola di euro) vale ufficialmente meno di 1000 satoshi.
|
|
|
|
Procedura per attivare il pruning su Windows 7: Premessa: ho scaricato e scompattato https://bitcoin.org/bin/bitcoin-core-0.12.1/bitcoin-0.12.1-win64.zipnella cartella bitcoin-0.12.1 io ho 3 cartelle: -bin (con dentro tutti gli eseguibili) -include (1 file) -lib (1 file) + ci puoi aggiungere eventualmente anche un file wallet.dat (se hai già un vecchio wallet) Se tu hai inoltre nella tua cartella altri vecchi file, blocchi, ecc. questi non ti servono e cancellali pure (ma non il file wallet.dat!) Osservazione: in generale è meglio mettere tutte le opzioni direttamente nel file di configurazione, è più pratico. E' sufficiente solo stabilire dove starà questo file e comunicarlo a bitcoin-qt (lo stesso discorso vale se utilizzi bitcoind e vale anche per bitcoin-cli). Il file di configurazione lo devi creare tu. ************************************************************************************************************* ************************************************************************************************************* Procedura: 1) crea sul desktop un collegamento al file C:percorso/bitcoin-0.12.1/bin/bitcoin-qt.exe a cui aggiungi l'opzione -conf=file_di_configurazione (che creerai poi nel punto 2) nel mio caso ad esempio ho inserito la seguente stringa nel comando da lanciare attraverso il collegamento sul desktop: C:\Users\Antonio\Downloads\bitcoin-0.12.1\bin\bitcoin-qt.exe -conf=C:\Users\Antonio\Downloads\bitcoin-0.12.1\bitcoin.conf
2) nel percorso che hai indicato con l'opzione -conf crea un file di testo bitcoin.conf (attenzione: se usi l'estensione .conf devi rinominare il file in modo da cambiare l'estensione .txt in .conf) oppure inserisci direttamente nel punto 1) -conf=C:\Users\Antonio\Downloads\bitcoin-0.12.1\bitcoin. txt se preferisci chiamarlo così, puoi mettere il nome che vuoi. Nota: di default Core cerca un file di nome bitcoin.conf in C:\Users\tuonome\AppData\Roaming\Bitcoin, ma quest'ultima è una directory "nascosta", difficile da trovare, pertanto io non l'ho usata (ma se tu vuoi usarla puoi inserire il file bitcoin.conf lì e non usare nemmeno l'opzione "-conf=" nel collegamento sul desktop). In questo file bitcoin.conf inserisci le seguenti voci: server=1
rpcuser=tuonome
rpcpassword=quellochevuoi
datadir=C:\Users\Antonio\Downloads\bitcoin-0.12.1\
prune=1000
e poi salvalo. Le prime 3 voci non sono obbligatorie, ma ti servono se vuoi interrogare Core via RPC attraverso linea di comando (bitcoin-cli). 1000 vuol dire 1000 mega, scegli tu il valore che preferisci, maggiore di 550. Tieni conto che l'indice dei blocchi (...blocks/index: attualmente sono 68 mega) e il database degli UTXO (chainstate: attualmente sono 2 giga) invece sono a parte, quindi utilizzerai in totale sempre di più del valore che imposterai con il pruning. Ovviamente come datadir puoi impostare la cartella che vuoi, non necessariamente quella contenente il programma come ho fatto io e non necessariamente la stessa di bitcoin.conf. Procedura finita. Clicca sull'icona di bitcoin-qt e sei a posto (nel senso che aspetterai qualche giorno per la sincronizzazione ) ************************************************************************************************************** ************************************************************************************************************** Se vuoi verificare cosa sta succedendo, hai diverse opzioni: 1) Aiuto -> Finestra di debug -> Informazioni: vedrai i blocchi man mano che si sincronizza 2) aprire il file debug.log che si trova nella cartella che hai specificato in datadir (in maniera equivalente: Aiuto -> Finestra di debug -> Informazioni -> Apri file log del debug) 3) Aiuto -> Finestra di debug -> Console e lì inserisci il comando che ti serve 4) per fare il controllo 3) via riga di comando è necessario aver impostato le prime 3 voci nel file bitcoin.conf e poi: vai nella cartella bitcoin-0.12.1\bin da esplora risorse, tieni premuto il tasto shift e clicca con il tasto dx del mouse dentro la finestra, clicca quindi su "Apri finestra di comando qui" e si apre un prompt dei comandi, a quel punto digita: bitcoin-cli -conf=file_di_configurazione comando ad esempio: bitcoin-cli -conf=C:\Users\Antonio\Downloads\bitcoin-0.12.1\bitcoin.conf getblockchaininfo
e verificherai cosa sta facendo Core direttamente da linea di comando.
|
|
|
|
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 |
|
|
|
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 --> https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruningBlock 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-pruningWith 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 |
|
|
|
|
Prima transazione dell'anno, tutto ok!
|
|
|
|
Bitcoin Core 0.13.1, blockchain completely synched, Armory 0.95.1 fresh installation, Ubuntu 16.10. Just a little glitch: if I execute only ArmoryDB, it fails because /home/antonio/.armory doesn't exist and it gets stuck on this error: antonio@ubuntu:~$ ls .armory
ls: impossibile accedere a '.armory': File o directory non esistente
antonio@ubuntu:~$ /usr/bin/ArmoryDB
/home/antonio
/home/antonio/.armory is not a valid path
logging in /home/antonio/.armory/dbLog.txt
-INFO - 1483277052: (main.cpp:23) Running on 1 threads
-INFO - 1483277052: (main.cpp:24) Ram usage level: 4
antonio@ubuntu:~$ ls .armory
ls: impossibile accedere a '.armory': File o directory non esistente
"logging in /home/antonio/.armory/dbLog.txt" is then a false message. If I manually create only the .armory directory (not the databases subdirectory), then is ok: antonio@ubuntu:~$ mkdir .armory/
antonio@ubuntu:~$ ls .armory/
antonio@ubuntu:~$ /usr/bin/ArmoryDB
/home/antonio
/home/antonio/.armory/databases is not a valid path
logging in /home/antonio/.armory/dbLog.txt
-INFO - 1483277785: (main.cpp:23) Running on 1 threads
-INFO - 1483277785: (main.cpp:24) Ram usage level: 4
-INFO - 1483277785: (BlockUtils.cpp:1338) blkfile dir: /home/antonio/.bitcoin/blocks
-INFO - 1483277785: (BlockUtils.cpp:1339) lmdb dir: /home/antonio/.armory/databases
-INFO - 1483277785: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 1483277785: (BlockUtils.cpp:1521) Executing: doInitialSyncOnLoad
-INFO - 1483277785: (DatabaseBuilder.cpp:169) Reading headers from db
-WARN - 1483277785: (lmdb_wrapper.cpp:1175) No headers in DB yet!
-INFO - 1483277785: (DatabaseBuilder.cpp:208) Found 1 headers in db
-INFO - 1483277785: (DatabaseBuilder.cpp:51) updating HEADERS db
-INFO - 1483277792: (DatabaseBuilder.cpp:268) parsed block file #0
-INFO - 1483277796: (DatabaseBuilder.cpp:268) parsed block file #1
-INFO - 1483277801: (DatabaseBuilder.cpp:268) parsed block file #2
-INFO - 1483277804: (DatabaseBuilder.cpp:268) parsed block file #3
-INFO - 1483277808: (DatabaseBuilder.cpp:268) parsed block file #4
-INFO - 1483277812: (DatabaseBuilder.cpp:268) parsed block file #5
-INFO - 1483277815: (DatabaseBuilder.cpp:268) parsed block file #6
-INFO - 1483277819: (DatabaseBuilder.cpp:268) parsed block file #7
.....
-INFO - 1483284971: (DatabaseBuilder.cpp:268) parsed block file #726
-DEBUG - 1483284972: (Blockchain.cpp:242) Organizing chain
-INFO - 1483284982: (DatabaseBuilder.cpp:56) updated HEADERS db in 7197s
-INFO - 1483284982: (BlockUtils.cpp:1636) Enabling zero-conf tracking
antonio@ubuntu:~$ ls .armory/
databases dbLog.txt
The warning "/home/antonio/.armory/databases is not a valid path" in this case is only a warning, and Armory resolves the issue by itself. Question #1: is it ok to terminate ArmoryDB with "CTRL + C" ? I didn't figure out another way. Question #2: now if I execute /usr/bin/armory (after quitting ArmoryDB and Bitcoin Core), I get: File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
2017-01-01 17:20 (ERROR) -- SDM.py:791 - ValueError in bkgd req top blk
Traceback (most recent call last):
File "/usr/lib/armory/SDM.py", line 765, in __backgroundRequestTopBlock
numblks = self.proxy.getinfo()['blocks']
File "/usr/lib/armory/bitcoinrpc_jsonrpc/authproxy.py", line 105, in __call__
resp = json.loads(resp, parse_float=decimal.Decimal)
File "/usr/lib/python2.7/json/__init__.py", line 352, in loads
return cls(encoding=encoding, **kw).decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
and the program gets stuck. I need instead to use the three commands: - /usr/bin/local/bitcoind --daemon
- /usr/bin/ArmoryDB
- python2 /usr/lib/armory/ArmoryQt.py
to make Armory work. Why? |
|
|
|
Se fallisce per mancanza di mining diventa inutilizzabile e non saresti in grado di trasferire la proprietà e la chiave privata non la pagherebbe nessuno proprio per il rischio di non essere sicuri di essere gli unici possessori.
Cosi' al volo non mi vengono in mente altri fallimenti che potrebbero tenere il valore di 5USD (esempio).
Nel secondo caso, se il mining venisse abbondonato ma l'algoritmo rimanesse crittograficamente sicuro, la blockchain rimarrebbe un pezzo di storia immodificabile contenente tantissime transazioni. Negli ultimi giorni di vita del mining, crollo verticale del prezzo e della potenza computazionale, qualcuno potrebbe voler accaparrarsi qualche/molti btc per poter risultarne l'ultimo possessore effettivo, per essere cioè il destinatario finale di una lunga catena di transazioni della prima criptovaluta della storia, sapendo che da lì a poco la blockchain smetterà per sempre di muoversi. |
|
|
|
|
Show Posts
