Tuning full node

[gbianchi]

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:

-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  

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...

[wariner]

dimenticavo puoi anche usare il comando dbcache....

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.

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  

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 !

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.

[gbianchi]

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

[wariner]

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.

[wariner]

stanno parlando anche del comando:

Code:

export MALLOC_ARENA_MAX=1

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

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

[gbianchi]

stanno parlando anche del comando:

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 !!!)

[wariner]

(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..

[gbianchi]

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     .

[arulbero]

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     .

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

[arulbero]

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??

[gbianchi]

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 ?

[gbianchi]

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

[arulbero]

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

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?

[gbianchi]

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....

[arulbero]

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!

[gbianchi]

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.

[arulbero]

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 

[gbianchi]

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 

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.

[arulbero]

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://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

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.

[gbianchi]

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://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

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.

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