Bitcoin Forum

Da un po' di tempo ho dei grossi problemi a far girare il mio full node con bitcoin-qt versione 0.11.0

1) l'occupazione di memoria tende a crescere molto, arriva facilmente a 7-8 giga di ram.
Il che non sarebbe neppure gravissimo, se non fosse che quando va in questo stato, non ne torna piu' indietro,
e inizia a rispondere lentissimamente a tutti i programmi che lo usano via RPC (ad esempio p2pool), anzi a volte vanno
proprio in timeout.


2) spesso mi viene fuori questo warning:
Warning: (from bitcoind) EXCEPTION: NSt8ios_base7failureE non-canonical ReadCompactSize() bitcoin in ProcessMessages()
e anche questo non preannuncia nulla di buono in quanto se appare di nuovo il bitcoin-qt diventa instabile

entrambe le cose succedono da circa una decina di giorni, suppongo quindi siano legate.
Considerate che ho il full node da ormai 2 anni, e prima ovviamente non mi era mai successo niente di simile, ne' con le
versioni precedenti di bitcoin-qt, ne' con la 0.11.0 che ho su da quando e' uscita.

Qualcuno ha suggerimenti per fare un po' di debug/tuning risolvere questo problema ?

PS: per ora l'unico sistema orribile che ho trovato e' chiudere il bitcoin-qt e riavviarlo quando va in questo stato (e quando me ne accorgo),
ma spero di trovare qualcosa di meglio :)

intanto che qualcuno trova una soluzione migliore, mi sono fatto questo scripettazzo
che riavvia bitcoin-qt se appare il famigerato errore,  tutto da linea di comando,
Funziona solo in linux, non ci provate neppure in windows.

#!/bin/bash
# script orrendo per riavvirare bitcoin-qt in caso di errore NST8ios
# Glo 13/10/2015

start_bitcoin()
        {
        echo "avvio bitcoin-qt"
        export DISPLAY=:0

        /usr/bin/bitcoin-qt  > bitcoin.log 2>&1 &
        }

stop_bitcoin()
        {
        # provo a terminarlo finche' non c'e' piu' tra i processi
        while true
        do
                bitcoin-cli stop

                if ! ps -ax | grep -v grep | grep -q "bitcoin-qt"
                then
                        break
                fi

                echo "bitcoin gira ancora "
                sleep 1
        done
        }

cnt_bitcoin()
        {
        while true
        do

                if bitcoin-cli getinfo | grep -q "NSt8ios_base7failureE"
                then
                        echo "restart NSt8ios_base7failureE"
                        date

                        stop_bitcoin

                        start_bitcoin

                else
                        sleep 10
                fi
        done
        }

# se per caso c'era un bitcoin-qt attivo
stop_bitcoin
# avvia una sessione bitcoin qt
start_bitcoin
# controlla se bitcoin-qt entra in errore, e se si lo fa ripartire
cnt_bitcoin

a me da quando l'ho fatto mi ha riavviato il client 4 volte.... sembra che l'errore "NSt8ios_base7failureE" appaia abbastanza spesso,
ossia piu' volte al giorno.

Non ho capito ancora bene a cosa e' riferito, pero' di sicuro quando appare il bitcoin-qt
non funziona piu' bene, ed e' molto meglio riavviarlo.

L'errore ce l'ho costantemente ma, almeno nel mio caso, non è collegalo al consumo di CPU che si è normalizzatao ormai.

Per me invece anche la ram a valori regolari, niente di allarmante, consuma circa 5% dei 32 GB a disposizione

ecco cosa stava succedendo:

http://www.coindesk.com/bitcoin-node-numbers-fall-after-spam-transaction-attack/

mi chiedo come mai me ne accorgo solo io... qui un full node non lo ha nessuno ?

"Eventually, the transaction backlog fills-up the RAM memory of the nodes. This causes the node computers to slow down dramatically or even freeze-up. If a node slows down too much, the bitcoin network considers it to be ineffective and 'offline'. My guess is that most of the offline nodes just stop functioning well enough to respond."

ecco cosa stava succedendo:

http://www.coindesk.com/bitcoin-node-numbers-fall-after-spam-transaction-attack/

mi chiedo come mai me ne accorgo solo io... qui un full node non lo ha nessuno ?

Io ne ho 3 Fullm Node  ;D

Cmq, prova a fare l'update con 0.11.1

Bitcoin Core initial synchronization will take time and download a lot of data. You should make sure that you have enough bandwidth and storage for the full block chain size (over 20GB). If you have a good Internet connection, you can help strengthen the network by keeping your PC running with Bitcoin Core and port 8333 open. Read the full node guide for details.

eheh seono ottimisti sul sito bitcoin.org:



questo e' il du della mia cartella bitcoin:

52740   ./blocks/index
52798040        ./blocks
16      ./database
1147076 ./chainstate
53947084        .

ecco cosa stava succedendo:

http://www.coindesk.com/bitcoin-node-numbers-fall-after-spam-transaction-attack/

mi chiedo come mai me ne accorgo solo io... qui un full node non lo ha nessuno ?

x@PC:/Archiviazione$ du -h Bitcoin/
4,3G   Bitcoin/blocks/index
59G   Bitcoin/blocks
1,2G   Bitcoin/chainstate
4,0K   Bitcoin/old
60G   Bitcoin/

Altrochè se me ne sono accorto...ma ho avuto bisogno qualche giorno per capire fosse quello il problema...ho 2 full node per i miei 2 nodi p2pool, in pratica tutte quelle Spam Transaction mi riempivano la ram e facevano crashare bitcoind. Alla fine ho controllato diversi nodi p2pool notando che tutti avevano lo stesso problema....così ho fatto un paio di modifiche al file bitcoin.conf per accettare meno transazioni free ed ho risolto il problema.

-limitfreerelay=<n>    Rate-limit free transactions to <n>*1000 bytes per minute (default: 15)
 -minrelaytxfee=<amt>   Fees smaller than this (in satoshi) are considered zero fee (relaying and mining) (default: 0.00001)
 -disablewallet         Do not load the wallet and disable wallet RPC calls 

minrelaytxfee=0.00005 ---> di default è 0.00001 che è la fee minima
limitfreerelay=10 ---> di default è 15, in pratica limita tutte le transazioni free e quelle al di sotto della soglia impostata su minrelaytxfee a questo limite
disablewallet=1

Se poi così non ti basta puoi sempre aumentare minrelaytxfee o diminuire limitfreerelay ma non esagerare altrimenti ne risentirebbe troppo chi vuole fare una transazione a bassa/zero fee.

info:

Con queste impostazioni bitcoin-qt mi sta intorno ai 2gb di ram...ho comunque messo "monit" a controllarlo ed in caso sfondi la soglia dei 2.5gb o non risponde più alla porta 8333 lo riavvia.

ah i parametri che sono stati introdotti con la 0.10.

sai che non ho mai approfondito la cosa ? ricordo che mi lascio' perplesso, poi venni preso da altre storie.

pero' se viene minato un blocco che include queste transazioni, allora il cuo client cosa deve fare ?
di fretta e furia deve farsele passare per poterle validare ? boh !

Chi fa mining al tuo bitcoin-qt con quelle impostazioni e trova un blocco genererà solo le transazioni che il tuo bitcoin-qt ha accettato.

Se uno fa mining su un altro bitcoin-qt con nessun limite di fee genererà un blocco con sicuramente più transazioni e, probabilmente, più fee nel blocco.

Almeno questo è quanto mi pare di aver capito....ma soprattutto spero di essere stato chiaro  ;)

stanno parlando anche del comando:


che pare risolva il problema...ma io non ho ancora provato.

https://gist.github.com/laanwj/efe29c7661ce9b6620a7

(tra parentesi hai visto che sfiga p2pool ? e' una vita che non trova piu' un blocco !!!)

raga, qualcuno mi posta un du aggiornato di una blockchain bitcoin core
con -txindex attivo ?


voglio attivare -txindex, ma non ho idea di quanto spazio in piu' mi richiede.

questo e' il mio di adesso SENZA -txindex:

53M     ./blocks/index
56G     ./blocks
60K     ./database
1,2G    ./chainstate
57G     .

Secondo voi avrebbe senso acquistare un NUC tipo questo

http://www.ebay.it/itm/GIGABYTE-NUC-BRIX-S-CELERON-3205-NO-RAM-HDD-S-O-BLACK-/252187171577?hash=item3ab786daf9:g:D4IAAOSwt6ZWV1wI

per farci girare un full node?

Al di là del costo (magari se ne trovano di usati, ma d'altra parte bisogna aggiungere anche RAM e hard disk), e settando in maniera opportuna i parametri di Bitcoin Core, le caratteristiche tecniche (tipo velocità del processore) sarebbero sufficienti per sostenere le crescenti richieste computazionali della rete bitcoin? Sufficienti diciamo per almeno i prossimi 2/3 anni??

come ti ho detto nell'altro thread, il mio richiede un memory pool importante,  una notevole percenutale di processore e banda in quantita'.
inoltre l'uso di risorse e' salito molto negli ultimi mesi, in concomitanza dell'apprezzamento del BTC.

Quindi, secondo me devi scortadrti i 2/3 anni... io prevedo che se le cose vanno avanti come adesso,
io non reggo un anno con le mie risorse.

Ma sono anche io curioso di sentire le opinioni degli altri :)

Qualcun altro che abbia un full node e voglia darmi un parere sul mio hardware?

questi sostengono che con un rapsberry si puo' fare.

http://raspnode.com/faq.html#rpipowerful

come ho scritto, io non ci credo, se non altro perche' i rasp2 ha solo 1 GB di ram,
ma visto che costa veramente poco, e tu hai intenzione di fare un nodo ridotto, forse una prova
potresti pure farla....

Grazie per la prova, in effetti anche in rete si trovano diverse critiche sulla lentezza del raspberry e poi i conti non tornavano; non so proprio come facciano a vendere soluzioni dedicate basate proprio sul raspberry.

Inutile girarci intorno, per Bitcoin Core serve un pc. Mi rimane solo da capire se un NUC con 8/16 GB di RAM  e con Intel Core i3 sia sufficiente a darmi dei margini per essere utilizzato in maniera soddisfacente per almeno un paio di anni.
Dopodichè lo riciclerò come pc da regalare a qualche mio parente dalla basse pretese tecnologiche  ;D

Very soon libsecp256k1 will be used for verification, which speeds up initial sync time by 400%-700% and reduces CPU load for all full nodes.
A segregated witness softfork will be done ASAP (within 3-6 months, probably). This will at least double the effective transaction capacity (ie. it is equal to or better than BIP 102), and at the same time it will provide features important for safely scaling even more in the future.
There will not be any hardfork for at least the next ~year.
To pave the way for scalable hardfork max block size increases (which will eventually be necessary), and because it is already dearly needed, improved block/tx broadcasting technology such as weak blocks and IBLT will be implemented, hopefully soon after SegWit.
The BIPs necessary for efficient deployment of Lightning are already in the pipeline and should be rolled out in 2016. Lightning will allow for almost all of the security, features, and decentralization of Bitcoin transactions while drastically reducing the number of on-blockchain transactions that each individual will need to perform. This is expected to be the real eventual solution to scaling.

Sto ancora cercando di capire di quante risorse necessita veramente Bitcoin Core. Io ho installato la versione 0.11.2, che lancio ogni tanto solo perchè si sincronizzi (lo uso perchè il mio wallet di default è Armory, che come sapete ha bisogno del Core per funzionare).

L'altro giorno mi si è bloccato Core, e ho dovuto reindicizzare i blocchi. Ebbene, sono 2 giorni interi che sta reindicizzando e avanza lentissimo (per la cronaca il programma gira su Ubuntu 14.10, che gira su una virtual machine creata con vmplayer sul mio vecchio portatile di 6 anni). La cpu della virtual machine è sempre quasi al 100%!

Se penso che qui sul forum c'è chi asserisce di aver scaricato tutta la blockchain in soli 12 minuti  :P -->
https://bitcointalk.org/index.php?topic=1302157.msg13390925#msg13390925
mi viene male; ma oltre a scaricare la chain bisogna anche validarla, come è possibile metterci così poco?

Per fortuna che la 0.12 promette molto meglio da questo punto di vista https://bitcointalk.org/index.php?topic=1300389.msg13329111#msg13329111

...
Inoltre ritengo una carenza forse ancora peggiore anche la scarsissima discussione sul futuro dei full node,
che ritengo una problema di magnitudo maggiore a quello della dimensione del blocco.

Ma mentre la dimensione del blocco e' diventata una discussione "di moda" e gonfiato piu' di quello che e' in realta',
la carenza progettuale della ricompensa ai full node alla lunga sara' veramente deleteria per la rete,
che pratica aprira' la strada a fare di bitcoin uan rete  p2p solo in teoria (anzi a dirla tutta in realta' e' gia' cosi')

mi fa piacere che stai "toccando con mano" la pensatezza della cosa, magari mi dai una mano a
sensibilizzare la gente su questo tema :)

In sostanza quindi il lavoro del nostro full node è il prezzo che decidiamo di pagare per la mancanza di fiducia che abbiamo negli altri; si badi bene che questa mancanza di fiducia non ha un connotato negativo, anzi, è l'elemento base su cui si innesca l'effetto positivo di credibilità del sistema intero: più utenti decidono di pagare questo prezzo, più sicura diventa la rete (poichè cresce il controllo complessivo degli uni sugli altri).

Giustissimo, infatti cosi' deve funzionare una rete p2p, e cosi' penso fosse nell'idea del progetto.
Peccato che le cose sono andate diversamente, ormai pochissimi possono permettersi di fare un full node.

Come stiamo discutendo tenere su un full ha dei costi, diciamo che per ora siano X euro/anno.
Supponi che tu movimenti in bitcoin X/2 euro anno, ovviamente sarebbe assurdo tenere su un full node.

Inoltre c'e' la complicazione tecnica, ossia potresti non essere in grado di avere le competeze
che ormai servono per tenerlo su (manutenzione del sw, manutenzione della blockchain, manutenzione di un HW adeguato...)

Avrei una domanda relativa alla manutenzione di un full node:
per evitare che un problema nel database dei blocchi costringa a riscaricare e ricontrollare tutta la blockchain, voi fate un backup di tutta la cartella dei blocchi (che contiene a sua volta la cartella degli indici) + la cartella chain state?

--> .bitcoin/blocks
--> .bitcoin/chainstate

È sufficiente un backup di queste due cartelle o bisogna salvarsi qualcos'altro?

Per la cronaca il mio pc dopo 5 giorni sta ancora reindicizzando i blocchi (ne mancano 15000) ...

io l'ho installato su un un host vmware vsphere, in pratica e' una macchina virtuale
che viene backuppata in toto tutte le notte, da un prodotto che si chiama veeam backup & replication,
fatto apposta per i backup (ed evantuali restore rapidi) di VM.

Per chi fosse interessato, la versione 0.12 di Core ha implementato delle migliorie per chi volesse far girare un quasi full node con poche risorse -> https://github.com/bitcoin/bitcoin/blob/0.12/doc/release-notes.md

Riassumendo:

1) se si raggiunge una certa soglia si può limitare il traffico in upload dovuto in gran parte alla richiesta da parte dei nuovi nodi dei blocchi storici (vecchi più di una settimana); inoltre in tal caso si disconnetterebbero i peer SVP che chiedono di impostare un loro filtro; sempre nel caso si raggiungesse la soglia, alle cosiddette "free transaction" (dette anche "priority transaction") verrebbe negato l'accesso alla mempool; altri consigli per ridurre il traffico https://github.com/bitcoin/bitcoin/blob/0.12/doc/reduce-traffic.md

2) è possibile impostare direttamente un limite alla mempool (prima si faceva indirettamente variando la soglia delle fee minime per transazione) e limitare la lunghezza e lo spazio occupato dalle catene di transazioni orfane

3) è possibile utilizzare il pruning* con il wallet attivato (anche se alcuni comandi relativi al wallet non saranno abilitati)

4) il tempo di reindex dei blocchi e della validazione dei nuovi blocchi è più che dimezzato grazie alla nuova libreria libsecp256k1 che va a sostituire OpenSSL


* Riguardo al pruning, ho cercato informazioni per capire cosa si perde rispetto a un full node che mantiene copia dell'intera blockchain. A parte ovviamente non essere in grado di fornire ai nuovi peer della rete i blocchi più vecchi, da qualche discussione sul forum tipo questa -> https://bitcointalk.org/index.php?topic=1325796.msg13551728#msg13551728 mi pare di capire che per quanto la validazione dei nuovi blocchi e il controllo e trasmissione delle transazioni non dovrebbe cambiare nulla; non riesco però a capire come sia possibile verificare la validità di una certa transazione se i suoi input sono molto vecchi, basta forse verificare che appartengono all'UTXO?   ???

Effetti:

con il pruning si può ridurre notevolmente lo spazio occupato,
con la nuova libreria e i parametri della mempool si possono più che dimezzare i tempi di calcolo,
con i parametri relativi al traffico si potrà gestire meglio l'occupazione di banda

Direi tutte buone notizie  :)

appena ho un attimo lo provo.

per la verifica delle transazioni, a intuito dovrebbe funzionare che se riesce a verificare una transazione,
la broadcasta se ok, altrimenti la scarta. se non riesce e verificarla (perche' servono dati che non ha) la broadcasta
lasciando il lavoro a qualcuno altro. Pero' lo suppongo io eh, non ne sono certissimo.

UTXO
Some implementations of the bitcoin client also maintain a UTXO database or UTXO pool, which is the set of all unspent outputs on the blockchain. Although the name "UTXO pool" sounds similar to the transaction pool, it represents a different set of data. Unlike the transaction and orphan pools, the UTXO pool is not initialized empty but instead contains millions of entries of unspent transaction outputs, including some dating back to 2009. The UTXO pool may be housed in local memory or as an indexed database table on persistent storage.

Whereas the transaction and orphan pools represent a single node’s local perspective and might vary significantly from node to node depending upon when the node was started or restarted, the UTXO pool represents the emergent consensus of the network and therefore will vary little between nodes. Furthermore, the transaction and orphan pools only contain unconfirmed transactions, while the UTXO pool only contains confirmed outputs.

[...]


Independent Verification of Transactions

In Chapter 5, we saw how wallet software creates transactions by collecting UTXO, providing the appropriate unlocking scripts, and then constructing new outputs assigned to a new owner. The resulting transaction is then sent to the neighboring nodes in the bitcoin network so that it can be propagated across the entire bitcoin network.

However, before forwarding transactions to its neighbors, every bitcoin node that receives a transaction will first verify the transaction. This ensures that only valid transactions are propagated across the network, while invalid transactions are discarded at the first node that encounters them.

Each node verifies every transaction against a long checklist of criteria:

    The transaction’s syntax and data structure must be correct.
    Neither lists of inputs or outputs are empty.
    The transaction size in bytes is less than MAX_BLOCK_SIZE.
    Each output value, as well as the total, must be within the allowed range of values (less than 21m coins, more than 0).
    None of the inputs have hash=0, N=–1 (coinbase transactions should not be relayed).
    nLockTime is less than or equal to INT_MAX.
    The transaction size in bytes is greater than or equal to 100.
    The number of signature operations contained in the transaction is less than the signature operation limit.
    The unlocking script (scriptSig) can only push numbers on the stack, and the locking script (scriptPubkey) must match isStandard forms (this rejects "nonstandard" transactions).
   A matching transaction in the pool, or in a block in the main branch, must exist.
    For each input, if the referenced output exists in any other transaction in the pool, the transaction must be rejected.
    For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions pool, if a matching transaction is not already in the pool.
    For each input, if the referenced output transaction is a coinbase output, it must have at least COINBASE_MATURITY (100) confirmations.
    For each input, the referenced output must exist and cannot already be spent.
    Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in the allowed range of values (less than 21m coins, more than 0).
    Reject if the sum of input values is less than sum of output values.
    Reject if transaction fee would be too low to get into an empty block.
    The unlocking scripts for each input must validate against the corresponding output locking scripts.

These conditions can be seen in detail in the functions AcceptToMemoryPool, CheckTransaction, and CheckInputs in the bitcoin reference client. Note that the conditions change over time, to address new types of denial-of-service attacks or sometimes to relax the rules so as to include more types of transactions.

By independently verifying each transaction as it is received and before propagating it, every node builds a pool of valid (but unconfirmed) transactions known as the transaction pool, memory pool or mempool.

the raw data is used only to relay blocks to other nodes, to handle reorganizations, to look up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or for rescanning the wallet

0.11.0

This release supports running a fully validating node without maintaining a copy of the raw block and undo data on disk. To recap, there are four types of data related to the blockchain in the bitcoin system: the raw blocks as received over the network (blk???.dat), the undo data (rev???.dat), the block index and the UTXO set (both LevelDB databases). The databases are built from the raw data.

Block pruning allows Bitcoin Core to delete the raw block and undo data once it’s been validated and used to build the databases. At that point, the raw data is used only to relay blocks to other nodes, to handle reorganizations, to look up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or for rescanning the wallet. The block index continues to hold the metadata about all blocks in the blockchain.

The user specifies how much space to allot for block & undo files. The minimum allowed is 550MB. Note that this is in addition to whatever is required for the block index and UTXO databases. The minimum was chosen so that Bitcoin Core will be able to maintain at least 288 blocks on disk (two days worth of blocks at 10 minutes per block). In rare instances it is possible that the amount of space used will exceed the pruning target in order to keep the required last 288 blocks on disk.

Block pruning works during initial sync in the same way as during steady state, by deleting block files “as you go” whenever disk space is allocated. Thus, if the user specifies 550MB, once that level is reached the program will begin deleting the oldest block and undo files, while continuing to download the blockchain.

For now, block pruning disables block relay. In the future, nodes with block pruning will at a minimum relay “new” blocks, meaning blocks that extend their active chain.

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.

Block pruning is also incompatible with -txindex and will automatically disable it.

Once you have pruned blocks, going back to unpruned state requires re-downloading the entire blockchain. To do this, re-start the node with -reindex. Note also that any problem that would cause a user to reindex (e.g., disk corruption) will cause a pruned node to redownload the entire blockchain. Finally, note that when a pruned node reindexes, it will delete any blk???.dat and rev???.dat files in the data directory prior to restarting the download.