Tuning full node

[arulbero]

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

[gbianchi]

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 ?

[arulbero]

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.

[arulbero]

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

[gbianchi]

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

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

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

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

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

[arulbero]

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.

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 

[gbianchi]

certo che e' pieno di gente che si interessa ai full node eh ?

[arulbero]

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

Riassumendo:

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

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

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

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


* Riguardo al pruning, ho cercato informazioni per capire cosa si perde rispetto a un full node che mantiene copia dell'intera blockchain. A parte ovviamente non essere in grado di fornire ai nuovi peer della rete i blocchi più vecchi, da qualche discussione sul forum tipo questa -> https://bitcointalk.org/index.php?topic=1325796.msg13551728#msg13551728 mi pare di capire che per quanto 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  

[gbianchi]

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

Riassumendo:

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

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

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

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


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

Effetti:

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

Direi tutte buone notizie  

appena ho un attimo lo provo.

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

[arulbero]

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.

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?

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.

[arulbero]

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

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.

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.

[arulbero]

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://bitcointalk.org/index.php?topic=1348256.msg13752092#msg13752092