Spesso parliamo di full node, nella realtà i nodi si stanno ulteriormente specializzando.
Ci sono nodi che possono limitarsi a tenere copia della blockchain e a fornire blocchi su richiesta senza mai validare nulla,
ci sono nodi che validano tutto ma mantengono solo una piccola parte della chain,
ci sono nodi che controllano solo i blocchi e non le transazioni (e questo tipo di lavoro ha requisiti hardware molto contenuti)
Vi rimando a proposito a questo interessante post:
https://bitcointalksearch.org/topic/m.13752092
Topic: Tuning full node (Read 6545 times)
Ho guardato un po' in giro, penso di aver capito il funzionamento del nodo con pruning attivato:
questo nodo deve inizialmente scaricare tutta la blockchain, in modo da costruirsi da sè il database degli UTXO corretto (+ l'indice di tutti i blocchi); a differenza dei full node, appena la catena dei blocchi scaricati e validati supera un certo spazio occupato, allora il nodo comincia a eliminare i blocchi più vecchi.
Comunque è in grado di valutare il bilancio del proprio wallet con lo stesso grado di attendibilità con cui lo fa un full node, nonchè di fornire il classico servizio di consulenza ai client SPV. Inoltre è in grado di verificare perfettamente la validità di tutte le transazioni che gli arrivano (e quindi è in grado anche di ritrasmetterle a sua volta agli altri peer).
L'unico vero suo limite dal punto di vista della rete è legato al fatto che non è in grado di fornire i blocchi troppo vecchi (che non ha più) ai nuovi peer che si collegano alla rete.
Per quanto riguarda invece il wallet installato nel nodo, alcune funzioni che implicano il rescan (tipo importaddress e importprivkey) non possono funzionare, poichè i raw data non ci sono più.
EDIT:
[da qui https://www.reddit.com/r/Bitcoin/comments/46f67s/bitcoin_v0120_has_been_tagged_for_release/d04ksz9
sembra che quelle funzioni siano possibili ma senza il rescan; bisognerà verificare se sarà proprio così e se il wallet indicherà almeno il bilancio corretto rispetto alle chiavi private importate.]
Ecco a cosa servono i raw data in un full node (oltre a creare i database degli UTXO e l'indice dei blocchi):
Queste sono quindi le uniche funzionalità perse dai nuovi nodi con pruning attivato.
questo nodo deve inizialmente scaricare tutta la blockchain, in modo da costruirsi da sè il database degli UTXO corretto (+ l'indice di tutti i blocchi); a differenza dei full node, appena la catena dei blocchi scaricati e validati supera un certo spazio occupato, allora il nodo comincia a eliminare i blocchi più vecchi.
Comunque è in grado di valutare il bilancio del proprio wallet con lo stesso grado di attendibilità con cui lo fa un full node, nonchè di fornire il classico servizio di consulenza ai client SPV. Inoltre è in grado di verificare perfettamente la validità di tutte le transazioni che gli arrivano (e quindi è in grado anche di ritrasmetterle a sua volta agli altri peer).
L'unico vero suo limite dal punto di vista della rete è legato al fatto che non è in grado di fornire i blocchi troppo vecchi (che non ha più) ai nuovi peer che si collegano alla rete.
Per quanto riguarda invece il wallet installato nel nodo, alcune funzioni che implicano il rescan (tipo importaddress e importprivkey) non possono funzionare, poichè i raw data non ci sono più.
EDIT:
[da qui https://www.reddit.com/r/Bitcoin/comments/46f67s/bitcoin_v0120_has_been_tagged_for_release/d04ksz9
sembra che quelle funzioni siano possibili ma senza il rescan; bisognerà verificare se sarà proprio così e se il wallet indicherà almeno il bilancio corretto rispetto alle chiavi private importate.]
Ecco a cosa servono i raw data in un full node (oltre a creare i database degli UTXO e l'indice dei blocchi):
Quote
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
Queste sono quindi le uniche funzionalità perse dai nuovi nodi con pruning attivato.
Quote
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.
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.
appena ho un attimo lo provo.
Sì ma guarda che la nuova versione, la 0.12, esce solo tra una settimana.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.
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.
Il problema è capire innanzitutto per bene che cosa vuol dire "verificare una transazione" per un full node, da lì secondo me si può dedurre poi cosa può e cosa non può fare un nodo che invece ha una chain troncata.
Non penso che sia proprio come dici tu, poichè un nodo prima di propagare una qualsiasi transazione deve verificarla; se propaga una transazione che si rivela sbagliata aumenta il lavoro della rete e potrebbe anzi essere visto come un tentativo di truffa.
Io suppongo che per un full node "verificare una transazione" consista sostanzialmente nel verificare che tutti gli input che quella transazione sta cercando di spendere siano presenti nel database degli UTXO, database che un full node si è costruito per la prima volta quando ha scaricato la blockchain dal primo blocco (il database è stato aggiornato poi ad ogni nuovo blocco scaricato e verificato).
Se un nodo invece ha solo gli ultimi 10000 blocchi, la domanda è: come si è costruito il database degli UTXO?
Secondo me così come si è fidato di qualcun altro per scaricare il primo degli ultimi 10000 blocchi (non ha verificato che tutti i blocchi precedenti al quel "primo" blocco fossero validi), così probabilmente si è dovuto scaricare anche il database degli UTXO aggiornato a quel "primo" blocco; da quel momento in poi è stato in grado di aggiornare in autonomia il database degli UTXO a ogni blocco successivo.
Ma sono solo supposizioni; riporto qui di sotto alcuni passi di "Mastering Bitcoin" dove si spiega la cosa nella speranza che qualcuno possa capire meglio di me come funziona esattamente la verifica, almeno nel caso dei full node. Per chi si intendesse di programmazione, le funzioni del codice di Bitcoin Core che si occupano della verifica delle transazioni sono CheckTransaction e CheckInputs.
In particolare mi sfugge il seguente criterio
"A matching transaction in the pool, or in a block in the main branch, must exist"
cioè un full node deve controllare che ci siano effettivamente le transazioni d'"origine" per la transazione attuale? Mi sembra impossibile che per ogni nuova transazione ci sia bisogno di ricontrollare a ritroso potenzialmente tutti i blocchi, ma non basta controllare il database degli UTXO?
Quote
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.
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.
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://bitcointalksearch.org/topic/m.13551728 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
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://bitcointalksearch.org/topic/m.13551728 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.
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://bitcointalksearch.org/topic/m.13551728 mi pare di capire che per quanto riguarda 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 appartengano 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
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://bitcointalksearch.org/topic/m.13551728 mi pare di capire che per quanto riguarda 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 appartengano 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
certo che e' pieno di gente che si interessa ai full node eh ? 
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.
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.
Ho visto che c'è anche la versione free di quel programma (veeam backup free edition), le darò un'occhiata per vedere come funziona con la mia virtual machine creata con vmplayer.
Grazie della dritta
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) ...
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.
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) ...
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) ...
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...)
Per fare un paragone con le "vecchie" banche, attualmente io ho un conto corrente presso una banca online, e a parte i 34 euro di bollo non ho altre spese (bonifici gratuiti, pagamento con bancomat gratuiti).
Ovviamente la differenza sostanziale con il sistema Bitcoin è che i soldi non sono direttamente in mio possesso ma parcheggiati e affidati alle cure di qualcun altro di cui ho deciso di fidarmi.
D'altra parte sarebbe possibile oggi mantenere un full node con 34 euro l'anno?
Forse per il momento si riesce a farlo solo come sto facendo io, che ogni 2 giorni avvio per qualche ora il programma, aspetto che si sincronizzi, controllo il bilancio del wallet e poi spengo tutto. In questo modo limito il più possibile l'uso della banda e della corrente (ma basta poi un qualsiasi intoppo e rischio di impiegare 72 ore-macchina per ripristinare il tutto!). In sostanza controllo solo i blocchi ma non le transazioni della mempool. In effetti non è proprio un full node, quanto un node part time con una ricaduta positiva sulla rete molto limitata.
Il dubbio che ho da un po' di tempo a questa parte è sull'efficienza effettiva del sistema della blockchain (discorso che viene ben prima di quello dell'implementazione del protocollo in Bitcoin Core o di quello della dimensione dei blocchi). Questo sistema della blockchain viene lodato da più parti per l'innovazione che ha portato. Io riconosco l'innovazione e anche il grado di sicurezza con il quale grazie a esso oggi si può affermare che una certa transazione sia avvenuta in un certo momento.
Quello che mi suona strano è che un sistema che richieda che tutti gli N nodi della rete replichino N volte lo stesso lavoro di validazione della chain e delle transazioni della mempool possa essere un sistema davvero efficiente.
Se il bitcoin si diffondesse come i dollari (non succederà mai) e io avessi ancora un full node, sarebbe come se tutte le transazioni mondiali passassero attraverso il mio pc che dovrebbe convalidarle una a una!
Mi pare evidente che così com'è il sistema non può funzionare, ossia non è scalabile, e soprattutto è costosissimo (come hai notato tu per muovere x magari devo spendere 2x per controllare tutte le altre transazioni che non mi riguardano, e che saranno sempre molte di più in rapporto al numero di transazioni che mi coinvolgono direttamente). Il sistema ha funzionato bene finora perchè la comunità Bitcoin era piccola (controllare tutte le transazioni di un villaggio è poco costoso), ma adesso sta diventando veramente difficile, e a meno di svolte tecniche importanti che io mi auguro, il futuro è di pochi full node specializzati.
EDIT: coloro i quali dichiarano che le transazioni bitcoin sono quasi gratuite, di fatto o non tengono conto dei costi di mantenimento del full node oppure semplicemente usano wallet SPV e quindi si fidano di altri***, se tutti facessero così il bitcoin perderebbe di valore perchè sarebbe facilissimo rubare in un ambiente in cui tutti si fidano di tutti
***EDIT2: in sostanza i wallet SPV fanno affidamento sul fatto che gli altri nodi a cui si rivolgono non si fidino a loro volta di altri nodi ma svolgano al contrario in prima persona il lavoro di controllo (di fatto i full node lavorano gratis anche per i SPV).
È un po' la differenza che intercorre tra un "sentito dire" e una "conoscenza verificata di prima persona". Se la maggior parte dei nodi parlassero solo per sentito dire, non si sarebbe mai sicuri della verità di nessuna affermazione che gira per la rete.
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...)
per quello che ho scritto che bitcoin si sta allontanando da un vero sistema p2p...
parlando di numeri, bitcoin ha ad oggi circa 6.700.000 indirizzi attivi, stimiamo un numero di utenti, facciamo circa 1.000.000 di utenti con estrema approsimazione,
ossia se supponiamo per semplificare che un utente ha in media 6.7 indirizzi.
esistono circa 5.500 full node attualmente https://bitnodes.21.co/
quindi un full node ogni 180 utenti (dato approssimativo ma che rende l'idea di ordine di grandezza)
quel che e' peggio e' che gli utenti stanno aumentando, e i full node diminuendo, quindi questo rapporto tende a peggiorare,
e ad allontanarsi sempre di piu' da un modello p2p.
e questa, purtroppo, non e' la mia opinione, e' un dato di fatto.
EDIT: poi come dico io, se uno e' consapevole puo' fare quel che vuole. Ma quanti sono consapevoli che attualmente
bitcoin non e' piu' un vero sistema p2p, e che proseguendo questo trend lo sara' sempre di meno ?
...
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')
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')
Sul discorso di ricompensa per i full node, io la vedo così:
l'unico vero lavoro dimostrabile è quello dei miner, che per questo vengono ricompensati (il loro è un lavoro competitivo e sempre più difficile, dove per forza di cosa solo i migliori e i più capaci sopravvivono riuscendo a spartirsi le ricompense e le fee);
il lavoro dei full node invece non è dimostrabile, anzi è falsificabile molto facilmente; inoltre il lavoro dei full node più che un servizio per gli altri è in primo luogo un servizio per se stessi. La validazione delle transazioni e dei blocchi è infatti un lavoro che in primis si fa per se stessi, per essere in grado di riconoscere la validità dei pagamenti ricevuti. Il lavoro di trasmissione di transazioni (altrui) e di blocchi agli altri nodi viene invece ricompensato con la ricezione di altre transazioni e blocchi da altri nodi (che contribuiscono così in maniera determinante a rendere affidabile il giudizio del nostro full node).
Tu sostieni che la mancanza di ricompensa sia una carenza progettuale, dal mio punto di vista invece in una rete veramente P2P se tutti facciamo lo stesso lavoro, chi dovrebbe pagare chi? Perchè?
Il concetto che sta alla base del Bitcoin è che si tratta di un mezzo di pagamento senza bisogno di fiducia, ovvero un sistema nel quale ogni utente deve essere nella condizione di poter controllare da solo la validità di una qualsiasi transazione che riceve (validità che dipende sostanzialmente dalla validità di tutte le altre transazioni che si sono succedute dall'inizio della storia del bitcoin, e questo è il punto che regge tutto ma anche il problema). La condizione di assenza di bisogno di fiducia si traduce nel full node; chiunque abbia un wallet e gestisca transazioni di una certa importanza dovrebbe avere un full node e non affidarsi ai full node di altri utenti.
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).
mi fa piacere che stai "toccando con mano" la pensatezza della cosa, magari mi dai una mano a
sensibilizzare la gente su questo tema
Questa pesantezza è dovuta all'aumento delle transazioni e quindi dell'utilizzo del sistema Bitcoin; semplicemente il lavoro di controllo da fare (il prezzo da pagare per la mancanza di fiducia) sta aumentando oltre le possibilità economiche (e di tempo) dell'utente medio. Non sono in grado di capire se a livello tecnico il problema sia risolvibile o meno.sensibilizzare la gente su questo tema
Dal mio punto di vista la "mancanza di fiducia" sta diventando un lusso che pochi possono permettersi man mano che il sistema diventa più complesso; e non mi riferisco solo alle questioni puramente economiche: quante persone pensi siano in grado semplicemente di capire a livello tecnico il bitcoin per non parlare delle implicazioni più generali sottese a ogni scelta tecnica? Non è forse un enorme paradosso dichiarare di aver costruito un sistema che permette a tutti di potersi non fidare e controllare direttamente tutto, quando nella realtà la stragrande maggioranza delle persone è costretta a fidarsi invece di quello che le si dice?
L'esperimento bitcoin rischia di produrre dei risultati inattesi anche per i suoi creatori, e cioè potremmo avere in un futuro prossimo dei full nodi specializzati e forse a pagamento (vi ricordano qualcosa le banche?) senza i quali non potremo processare i nostri pagamenti. A questi full node concederemo la nostra fiducia, poichè fare altrimenti risulterebbe troppo costoso.
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
-->
https://bitcointalksearch.org/topic/m.13390925
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://bitcointalksearch.org/topic/m.13329111
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
--> https://bitcointalksearch.org/topic/m.13390925
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://bitcointalksearch.org/topic/m.13329111
Quote
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.
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.
eh come ti ho scritto varie volte, per ora le risorse richieste per un full node sono veramente ingenti,
(se non fai una prova di 10 minuti e ritieni che sia finita li')
Poi non ti ho voluto spaventare, ma devi vedere che casini quando arrivano le smitragliate di spam
per cercare di mandare in palla la rete, li' si che c'e' da ridere.... memoria occupata a 8 Gb e piu',
cpu 100% fissa, banda usata a badilate, errori a manetta, finche' non arriva la versione patch .... insomma e' diventato un vero
lavoro sporco tenere su un full node funzionante, e come ripeto sempre, ritengo una grave carenza progettuale
non aver previsto nessuna ricompensa per i full node.
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
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 -->
https://bitcointalksearch.org/topic/m.13390925
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://bitcointalksearch.org/topic/m.13329111
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
--> https://bitcointalksearch.org/topic/m.13390925
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://bitcointalksearch.org/topic/m.13329111
Quote
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.
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.
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
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
direi che come caratteristiche HW per un po' ti gira. a sapere cosa succede da qui ad un paio d'anni e' veramente dura ...
fra un po' pubblico i dati mensili di statistiche, e in dicembre c'e' stata un'impennata di adozione che fa presagire tempi movimentati
ah tieni conto anche della banda internet che ti servira', che non e' poca.
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
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
ciao sono sempre io ... ho fatto qualche esperimento.
HO riavviato il nodo per vedere come si comporta "a mente fresca", ne senso che noterai
che il core ha difficolta' a rilasciare la memoria, quindi se ti arriva ad occupare
5 giga, poi raramente lo vedi tornare indietro.
l'ho fatto ripartire oggi pomeriggio, ed oggi deve essere stato abbastanza calmo
(a parte l'abnorme generazione di blocchi ma quella e' altra cosa)
comunque, dopo appena qualche ora di funzionamento , gia' mi sta occupando 1,5 Gb
direi che questo esclude senz'altro la possibilita' di farlo girare su un raspberry.
HO riavviato il nodo per vedere come si comporta "a mente fresca", ne senso che noterai
che il core ha difficolta' a rilasciare la memoria, quindi se ti arriva ad occupare
5 giga, poi raramente lo vedi tornare indietro.
l'ho fatto ripartire oggi pomeriggio, ed oggi deve essere stato abbastanza calmo
(a parte l'abnorme generazione di blocchi ma quella e' altra cosa)
comunque, dopo appena qualche ora di funzionamento , gia' mi sta occupando 1,5 Gb
direi che questo esclude senz'altro la possibilita' di farlo girare su un raspberry.
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....
Anche a me così a occhio i conti non tornano:
Memory - Bitcoin core generally uses between 50% and 70% of RAM, which leaves more than enough for the streamlined Raspbian OS. When initially downloading the blockchain the raspnode will hit some swap but not much and it isn't needed for normal operation.
Compute power - Bitcoin core generally uses around 10% of one core (out of four) and occasionally jumps to around 30% for a few seconds when verifying a block.
Solo 500/700 MB di RAM utilizzata mi sembra un quantitativo veramente risicato e solo il 10% di un core della sua cpu anche peggio (sul mio portatile, dove ogni tanto faccio girare Core per sincronizzare la blockchain, i valori sono ben più alti). Eppure vendono delle soluzioni dedicate a questo scopo proprio basate sul raspberry 2 https://bitcoinmini.com, chissà con che parametri girerà il Core...
Grazie per la segnalazione!
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....
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
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
Ovviamente imposterei un nodo limitando le dimensioni della memory pool (pensavo di agire soprattutto sui parametri minrelaytxfee e limitfreerelay); la mia idea è che se non posso mantenere proprio un "full" node, almeno vorrei poter contribuire a validare e a propagare un sottoinsieme delle transazioni che passano per il mio.
Ho solo il dubbio se questo modo di procedere sia veramente d'aiuto alla rete o magari al contrario possa in alcuni casi causare dei contrattempi (ad esempio potrebbe succedere che il mio nodo favorisca inconsapevolmente una double spending, dal momento che non può avere un quadro completo di tutte le transazioni che girano per la rete).
Diciamo che in qualche modo un modello sostenibile potrebbe essere quello di rinunciare a un vaglio completo di tutte le transazioni da parte di tutti i nodi (o almeno da parte di quelli poco prestazionali come quello che ho in mente di mettere in piedi io) per passare a un controllo "a campione" e quindi più "approssimativo" ma più capillare (ripeto anche se così facendo il giudizio di validazione risulta meno autorevole).
Al limite estremo sarebbe possibile avere dei nodi che controllino solo che i blocchi della blockchain siano validi e che contengano transazioni valide? Dei nodi cioè che si limitino a validare il lavoro già effettuato dai miner e trasmettano il risultato di questa validazione al resto della rete? E che quindi non abbiano di fatto una propria mempool? Una sorta di validazione solo a posteriori e non a priori delle transazioni (se ho detto qualche stupidaggine ditemelo pure).
Penso in conclusione che sia meglio una rete con 100 mila nodi con capacità di validazione diversa rispetto a una rete costituita solo da poche centinaia di full nodi, tutti "peer" sì, ma anche super prestazionali e costosissimi (questo è il futuro prossimo che di fatto paventi tu, se non si fa nulla per cambiare).
Qualcun altro che abbia un full node e voglia darmi un parere sul mio hardware?
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??
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
ciao raga...
da qualche ora il mio full node sputa questi errori:
>>> Warning: (from bitcoind) WARNING: abnormally high number of blocks generated, 48 blocks received in the last 4 hours (24 expected
che succede ? uno spike mostruoso di hashrate nella rete ?
da qualche ora il mio full node sputa questi errori:
>>> Warning: (from bitcoind) WARNING: abnormally high number of blocks generated, 48 blocks received in the last 4 hours (24 expected
che succede ? uno spike mostruoso di hashrate nella rete ?
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??
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??
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:
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 .
4,9G ./blocks/index/
63G ./blocks
1,2G ./chainstate
16K ./database
EDIT: se qualcuno usa anche Armory, in più si ritroverà
51G .armory/databases/blocks
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:
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 .
(tra parentesi hai visto che sfiga p2pool ? e' una vita che non trova piu' un blocco !!!)
veramente
Mi ricordo di aver aspettato anche una settimana non molto tempo fa per un blocco...me in questo mese è stata cmq fortunata...speriamo arrivi presto..
stanno parlando anche del comando:
che pare risolva il problema...ma io non ho ancora provato.
https://gist.github.com/laanwj/efe29c7661ce9b6620a7
Code:
export MALLOC_ARENA_MAX=1
che pare risolva il problema...ma io non ho ancora provato.
https://gist.github.com/laanwj/efe29c7661ce9b6620a7
grazie, faro' delle prove, comunque con lo script di controllo non ho piu' avuto problemi,
al massimo mi arriva a 3 Giga di occupazione (accettbile) e mi si riavvia in media ogni due giorni
per errori strani tipo quel NSt8ios_base7failureE.
ad esempio questo e' l'ultimo restart:
restart NSt8ios_base7failureE
mer 28 ott 2015, 12.57.36, CET
(tra parentesi hai visto che sfiga p2pool ? e' una vita che non trova piu' un blocco !!!)
stanno parlando anche del comando:
che pare risolva il problema...ma io non ho ancora provato.
https://gist.github.com/laanwj/efe29c7661ce9b6620a7
Code:
export MALLOC_ARENA_MAX=1
che pare risolva il problema...ma io non ho ancora provato.
https://gist.github.com/laanwj/efe29c7661ce9b6620a7
questo è quanto ho capito...potrei sbagliarmi
altro esempio...se guardi i miei nodi ed un nodo diverso in questo momento
http://warp2pool.eu/2/ --- Current block value: 25.12657460 BTC
http://warp2pool.eu/xt2/ - Current block value: 25.12682177 BTC
http://elizium.name/ --- Current block value: 25.07168676 BTC
Puoi notare che probabilmente utilizza una maggiore restrizione rispetto ai miei nodi nell'accettare transazioni con basse fee.
altro esempio...se guardi i miei nodi ed un nodo diverso in questo momento
http://warp2pool.eu/2/ --- Current block value: 25.12657460 BTC
http://warp2pool.eu/xt2/ - Current block value: 25.12682177 BTC
http://elizium.name/ --- Current block value: 25.07168676 BTC
Puoi notare che probabilmente utilizza una maggiore restrizione rispetto ai miei nodi nell'accettare transazioni con basse fee.
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
si si certo quello che mina un blocco che include piu' transazioni costringe tutti i bitcoin qt che non hanno quelle transazioni
nella mempool a farsele passare per poter validare anche loro il blocco.... in pratica c'e' un momento di terrore nella rete
dimenticavo puoi anche usare il comando dbcache....
Diciamo che è una cosa temporanea come tampone allo spam free. Agli stessi autori non piace e stanno lavorando a soluzioni alternative.
Facciamo un esempio tu imposti nel tuo bitcoin-qt minrelaytxfee=0.00005, tutte le transazioni con fee sotto 0.00005 vengono dal tuo bitcoin-qt intese come transazioni free le quali vengono poi limitate dal comando limitfreerelay=10 (nel nostro esempio) e quindi 10*1000 bytes di transazioni free al minuto accettate dal tuo bitcoin-qt.
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
cambia solo la cache per generare il blocco...una volta trovato il blocco bitcoin-qt lo prende in carico senza problemi e ricomincia a caricare una nuova cache con le direttive che hai dato per generare un nuovo blocco.
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.
sai che non ho mai approfondito la cosa ? ricordo che mi lascio' perplesso, poi venni preso da altre storie.
Diciamo che è una cosa temporanea come tampone allo spam free. Agli stessi autori non piace e stanno lavorando a soluzioni alternative.
Facciamo un esempio tu imposti nel tuo bitcoin-qt minrelaytxfee=0.00005, tutte le transazioni con fee sotto 0.00005 vengono dal tuo bitcoin-qt intese come transazioni free le quali vengono poi limitate dal comando limitfreerelay=10 (nel nostro esempio) e quindi 10*1000 bytes di transazioni free al minuto accettate dal tuo bitcoin-qt.
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
Quote
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 !
di fretta e furia deve farsele passare per poterle validare ? boh !
cambia solo la cache per generare il blocco...una volta trovato il blocco bitcoin-qt lo prende in carico senza problemi e ricomincia a caricare una nuova cache con le direttive che hai dato per generare un nuovo blocco.
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.
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:
Quote
-limitfreerelay= Rate-limit free transactions to *1000 bytes per minute (default: 15)
-minrelaytxfee= 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=
-disablewallet Do not load the wallet and disable wallet RPC calls
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.
il fatto che ogni bitcoin-qt puo' comportarsi in modo differente, mi lasciava un po' basito.
In pratica se fai una transazione a bassa fee, (o magari pure free) viene accettata nella mempool di pochi client,
di tutti quelli che hanno questi parametri settati sotto l'importo di quella fee.
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 !
cosi' a occhio e croce non e' cosa buona per l'incremente della dimensione dei blocchi...
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.
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:
Quote
-limitfreerelay= Rate-limit free transactions to *1000 bytes per minute (default: 15)
-minrelaytxfee= 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=
-disablewallet Do not load the wallet and disable wallet RPC calls
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.
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 ?
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 ?
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.
che parametri ci hai messo ? io ci lascio lo script a controllare tutto, ma
anche fare un po' di tuning ai parametri del bitcoin.conf non guasta !
Con blockchain indexata:
Quote
x@PC:/Archiviazione$ du -h Bitcoin/
4,3G Bitcoin/blocks/index
59G Bitcoin/blocks
1,2G Bitcoin/chainstate
4,0K Bitcoin/old
60G Bitcoin/
4,3G Bitcoin/blocks/index
59G Bitcoin/blocks
1,2G Bitcoin/chainstate
4,0K Bitcoin/old
60G Bitcoin/
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 ?
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 ?
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.
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 .
Quote
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.
questo e' il du della mia cartella bitcoin:
52740 ./blocks/index
52798040 ./blocks
16 ./database
1147076 ./chainstate
53947084 .
Oggi posto il mio du con blockchain indexata
dopo l'upgrade alla 0.11.1, la situazione e' molto migliorata, non so se per
coincidenza o per le fix della release.
Comunque l'occupazione si e' stabilizzata intorno ai 2/3 GB (normale)
e non si sono piu' presentati errori.
coincidenza o per le fix della release.
Comunque l'occupazione si e' stabilizzata intorno ai 2/3 GB (normale)
e non si sono piu' presentati errori.
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 .
Quote
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.
questo e' il du della mia cartella bitcoin:
52740 ./blocks/index
52798040 ./blocks
16 ./database
1147076 ./chainstate
53947084 .
Io ne ho 3 Fullm Node
Cmq, prova a fare l'update con 0.11.1
fatto upgrade.
Probabilmente l'approccio (per quanto rozzo) di far ripartire in automatico il bitcoin-qt
se inizia a dare errori strani o ad occupare troppe risorse alla fine e' il piu' efficace....
da quando ho lo scripettino, mi ha riavviato il bitcoin-qt 10 volte, p2pool e' felice,
i programmi delle statistiche girano bene... insomma d'ora in poi lo lascio "sotto controllo",
anzi perfeziono lo script per catturare piu' situazioni dubbie.
Anche perche' ho come l'impressione che le orde di spammatori, forgiatori di transazioni strane,
cercatori di bug aumenteranno sempre di piu'.
EDIT
e' ancora presto, ma ad occhio questa versione (0.11.1) ha davvero risolto qualche
problema nel consumo delle risorse.
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 ?
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
Cmq, prova a fare l'update con 0.11.1
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 ?
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 ?
Quote
"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."
Con il mio portatile è chiedere troppo avere un full node. Comunque sì in pratica il problema non eri tu ma derivava dall'attacco che hai subito.
Ti puoi anche rimettere la versione di bitcoin che ti sei compilato tu
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 ?
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 ?
Per me invece anche la ram a valori regolari, niente di allarmante, consuma circa 5% dei 32 GB a disposizione
boh che dire... io ho un ubuntu 14.04 LTS a 64 bit
Inoltre prima usavo una versione di bitcoin-qt compilata da me, ma per
togliermi ogni dubbio, ho messo su la 0.11.0 ufficiale con apt-get.
Insomma, non credo di avere nulla di particolare.
Forse ho il fatto che sono un full node da quasi 2 anni, e magari qualcuno mi ha preso
di mira sparandomi addosso transazioni "forgiate" proprio per mettermi in crisi il nodo...
sai che internet non e' un ambiente per gente troppo tenera, e bitcoin men che meno
Per me invece anche la ram a valori regolari, niente di allarmante, consuma circa 5% dei 32 GB a disposizione
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.
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.
io sulla CPU non ho mai avuto grossi problemi (al massimo mi va al 50%), invece in ram mi schizza spesso a 7 GB
mentre fino a due mesi fa non superava mai i 2GB.
Comunque io su quel server ho anche un nodo p2pool, che dialoga costantemente con il bitcoin-qt, e appena appare l'errore,
poi anche il nodo p2pool va in errore e non si ripiglia finche' non riavvio il bitcoin-qt.
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.
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.
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.
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.
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.
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
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
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
Non so se è un problema di FULL NODE o più in generale di Bitcoin Core. Anche a me la CPU è schizzata a livelli paurosi e mi da quel messaggio (EXCEPTION: NSt8ios_base7failureE \nnon-canonical ReadCompactSize() \nbitcoin in ProcessMessages()) come "error"
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
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
Jump to: