"extra pruned node" da pochi mega.....è possibile?

[nondormomai]

Premetto: sto leggendo molto sulla timechain e ho qualche lacuna che
sto lentamente colmando.

Mi ero interessato a tirare su un full node, e in rete ho trovato diversi tutorial.
Non tanto per partecipare al mining (non ho la strumentazione adatta), quanto per contribuire alla sicurezza.
Per ora non mi sono avventurato, in quanto vorrei dedicare un vecchio laptop a questo esperimento e prima devo aggiornarlo a livello hardware.

Nel mentre, mi è venuta questa idea, che volentieri condivido.

Mi chiedevo se era possibile scaricare - o creare - e tenere aggiornata una versione "extra pruned" della timechain, con soli tre o quattro dati identificativi per ogni singolo blocco:
1) numero progressivo del blocco, eventualmente con timestamp UTC, dal blocco genesi fino all'ultimo minato
2) hash del blocco esposto nell'header
3) numero nonce.

In sostanza, vorrei tralasciare il contenuto del blocco, ovvero le transazioni, che rappresentano la parte più pesante. Magari il
software potrebbe permette, ma solo dopo aver scaricato la versione ulta light, di scegliere quali o quanti blocchi scaricare integralmente.

Sarebbe una versione davvero molto leggera del nodo, e contribuirebbe alla sicurezza del sistema ovvero alla immutabilità della chain.

Ad occhio, non dovrebbe pesare più di qualche mega, e forse potrebbe girare persino su telefono tramite App.
E volentieri, per spirito di collaborazione, lo installerei, facendolo girare in background, visto che consumerebbe davvero poche risorse.

Si tratterebbe, come dire?, una sorta di "layer di consenso", il cui scopo è in qualche modo contribuire, seppur di poco, alla immutabilità della catena.
Se dovessi fare un metafora, è come avere a fine serata i saldi di una rete di registratori di cassa, senza avere tutti i movimenti.

Sarebbe possibile?

[mendace]

Non sono sicurissimo di quello che ti sto dicendo ma Il contenuto effettivo delle transazioni non è strettamente necessario per il funzionamento del nodo, ma solo per la validazione delle transazioni e il calcolo dello stato del conto, quindi in sostanza sarebbe possibile fare ciò che stai chiedendo tieni presente che mantenere solo le informazioni ridotte dei blocchi potrebbe comportare problemi di sicurezza e fiducia nella blockchain, poiché non si potrebbe più verificare l'integrità delle transazioni senza accedere ai dati originali. Inoltre, il nodo non potrebbe partecipare attivamente al processo di convalida delle transazioni e di creazione dei blocchi.

Il mio consiglio è quello di creare un nodo standard full.

[nondormomai]

Grazie.

Sono convinto dell'utilità di un full node. Ma per ora, non fa per me.

Come utente alle prime armi, troverei molto utile la possibilità di tirare su un nodo ultra leggero, senza partecipare alla validazione, ma solo come archivio di 3, 4 campi di ogni blocco.

Certo, non saprei cosa c'è dentro un blocco, ma sarebbe comunque una forma di backup ultraleggero.

Poi, avendo a disposizione un hardware adeguato, passerei a scaricare tutti i blocchi integri (comprensivi di transazioni), senza senza partecipare alla validazione ma solo come archiviazione.

Non so se si può fare con il Bitcoin Core, che credo faccia scaricare fin da subito tutti i blocchi, occupando quasi 0,6 o 0,7 Tera ad oggi.

[gbianchi]

Premetto: sto leggendo molto sulla timechain e ho qualche lacuna che
sto lentamente colmando.

Mi ero interessato a tirare su un full node, e in rete ho trovato diversi tutorial.
Non tanto per partecipare al mining (non ho la strumentazione adatta), quanto per contribuire alla sicurezza.
Per ora non mi sono avventurato, in quanto vorrei dedicare un vecchio laptop a questo esperimento e prima devo aggiornarlo a livello hardware.

Nel mentre, mi è venuta questa idea, che volentieri condivido.

Mi chiedevo se era possibile scaricare - o creare - e tenere aggiornata una versione "extra pruned" della timechain, con soli tre o quattro dati identificativi per ogni singolo blocco:
1) numero progressivo del blocco, eventualmente con timestamp UTC, dal blocco genesi fino all'ultimo minato
2) hash del blocco esposto nell'header
3) numero nonce.

In sostanza, vorrei tralasciare il contenuto del blocco, ovvero le transazioni, che rappresentano la parte più pesante. Magari il
software potrebbe permette, ma solo dopo aver scaricato la versione ulta light, di scegliere quali o quanti blocchi scaricare integralmente.

Sarebbe una versione davvero molto leggera del nodo, e contribuirebbe alla sicurezza del sistema ovvero alla immutabilità della chain.

Ad occhio, non dovrebbe pesare più di qualche mega, e forse potrebbe girare persino su telefono tramite App.
E volentieri, per spirito di collaborazione, lo installerei, facendolo girare in background, visto che consumerebbe davvero poche risorse.

Si tratterebbe, come dire?, una sorta di "layer di consenso", il cui scopo è in qualche modo contribuire, seppur di poco, alla immutabilità della catena.
Se dovessi fare un metafora, è come avere a fine serata i saldi di una rete di registratori di cassa, senza avere tutti i movimenti.

Sarebbe possibile?

Credo che tenere una sintesi del genere o non tenere niente sia piu' o meno equivalente.

supponiamo che n sia l'ultimo blocco del quale hai la sintesi.

dalla sintesi del blocco n-1 non riesci a ricavare se la sintesi del blocco n e' valida o no, perche' ti mancano tutti i dati
per fare questa verifica, e neppure la sintesi del blocco  n-2 ti serve a stabilire se quella di n-1 va bene e cosi' via via fino alla sintesi gel genesis block.

Quindi a sto punto non vedo per quale motivo dovresi portarti dietro tutte queste sintesi che fondamentalmente non ti servono a niente.

[usque_ad_finem]

Sono molto poco pratico, chiedo scusa se quel che scrivo non servirà a nulla.

Con il core wallet si può fare questo:

https://bitcoin.org/en/full-node#reduce-storage

Anni fa creai un core wallet su windows, "all'antica" col mitico wallet.dat per capirci, e feci qualcosa di simile seguendo le istruzioni per risparmiare un sacco di spazio. Sono anche abbastanza sicuro di non aver scaricato mai tutta la blockchain, perchè appunto anche se ai tempi era più snella, ricordo bene che non avevo spazio. Credo che le cose siano andate così: cambiai qualche parametro nel file config limitando l'uso dei gb sul disco, poi il core wallet cominciò a scaricare. Dovette comunque scaricare tutta la blockchain, però man mano buttava via i dati vecchi perchè appunto sforava costantemente il limite. Poi appunto spero di non aver detto boiate...

Ovviamente, come dice gbianchi, penso che alla fine dei conti l'unico motivo per utilizzare quella possibilità sia se si vuole un core wallet ma non c'è spazio sufficiente per la blockchain, altri motivi non ce n'è, la blockchain non l'hai tutta, per cui penso (sempre da ignorante) che di "utilità sociale" non ce ne sia, perchè il tuo nodo non serve a nulla...

[fillippone]

Non credo la tua sia un’idea valida.
Credo che la versione più pruned possibile debba comunque avere tutto l’UTXO set disponibile, e quindi di certo non ci si può limitare ai pochi dati che dici tu.

Mantenere un nodo non è cosa particolarmente difficile, ed anche il costo non è proibitivo, basta un vecchio laptop ed un HD da 1Tb.

Se pensi che questa spesa sia alta, pensa cosa vuol dire avere un full node di ETH…

[nondormomai]

Anzitutto vi ringrazio per i messaggi.

Io personalmente continuo a sostenere, nonostante ritengo comunque validi gli argomenti di chi dice che è inutile, che l'idea potrebbe avere un senso.

Come detto, sostengo un approccio molto graduale alla questione "full node".
Prima o poi me ne farò uno, ma prima mi piacerebbe passare per qualcosa di molto leggero, e sinceramente se ci fosse una versione così me la scaricherei sullo smartphone.

Capisco che se manca il contenuto del blocco non ho le transazioni.
 Però ne avrei l'hash, il che non mi pare poco.
In sostanza, sarebbe come avere un excel gigante con 789071 righe (i blocchi minati ad oggi), e per ogni riga avere 3 colonne:
colonna A numero del blocco
colonna B hash del blocco
colonna C golden nonce

e già da questo capite quanto io non sia pratico di informatica.... eh eh eh


Grazie!

[DensBTC]

Anzitutto vi ringrazio per i messaggi.

Io personalmente continuo a sostenere, nonostante ritengo comunque validi gli argomenti di chi dice che è inutile, che l'idea potrebbe avere un senso.

Come detto, sostengo un approccio molto graduale alla questione "full node".
Prima o poi me ne farò uno, ma prima mi piacerebbe passare per qualcosa di molto leggero, e sinceramente se ci fosse una versione così me la scaricherei sullo smartphone.

Capisco che se manca il contenuto del blocco non ho le transazioni.
 Però ne avrei l'hash, il che non mi pare poco.
In sostanza, sarebbe come avere un excel gigante con 789071 righe (i blocchi minati ad oggi), e per ogni riga avere 3 colonne:
colonna A numero del blocco
colonna B hash del blocco
colonna C golden nonce

e già da questo capite quanto io non sia pratico di informatica.... eh eh eh


Grazie!

Secondo me stai facendo confusione, scaricare e avviare un FullNode è un'operazione molto molto molto più semplice che procurarsi dei SATS o installare Office o il driver di uno scanner, scarichi la versione adatta al tuo sistema Operativo, avvii l'installazione, aspetti che si sincronizza e hai finito e praticamente hai fatto tutto in 4 click, se scarichi la versione Linux su Widows o viceversa semplicemente non ti si avvia. Quello che vuoi fare tu è un'indice di blocchi che ti compila una tabella, non è difficilissimo se hai un full node da interrogare, sai come interrogarlo, sai programmare in C o perlomeno in Pyton, sai trovare e usare le librerie adeguate... facile per un programmatore.

Quindi se proprio sei alle primissime armi, scaricati un full node e avvialo, basta un vecchio pc un po' di spazio e una linea internet qualunque.
La prima cosa che ho fatto quando ho scoperto Bitcoin è stato avviare un full node, non ero ancora in grado di comprare bitcoin o di fare una transazione ma il mio full node già faceva il suo lavoro. Se invece hai dubbi in merito alla privacy... bè avere un Full Node la aumenta anche se non ci metti davanti nessuna VPN o TOR, se non usi nessun sistema di mascheramento la tua privacy su internet è già compromessa per tutto quello che fai e quindi che ti frega del FullNode, se invece usi già sistemi di offuscamento usali anche per il nodo così come sai già fare per la posta o i porno, non cambia nulla.
Se non mi credi scaricati Core e fai una prova, ti garantisco che è un software fatto molto bene, molto ben documentato e assolutamente molto "compatibile" è rarissimo trovare software che funzionano così bene "brainless" se sei riuscito ad iscriverti ad un forum puoi operare tranquillamente un Full Node

[nondormomai]

Quindi in sostanza occorre sempre partire da un full node e poi selezionare lo stock di informazioni che si desidera trattenere.

Peccato.  

Volentieri avrei fatto qualche prova scaricando prima il dataset "leggero" per poi passare a scaricare magari tutta la chain.

In effetti, il mio progetto è proprio

un'indice di blocchi che ti compila una tabella, non è difficilissimo se hai un full node da interrogare, sai come interrogarlo, sai programmare in C o perlomeno in Pyton, sai trovare e usare le librerie adeguate... facile per un programmatore.

Al di là del tecnicismo (non sono un programmatore e non saprei da dover partire), mi chiedevo se comunque questa mia idea aiuta la sicurezza in termini di immutabilità della chain.
Avere un archivio con tutti gli identificativi del blocco, ora e data di validazione,  i rispettivi cash e i rispettivi golden nonce, per quello che posso capire io (ed è il motivo per cui mi confronto qui), potrebbe essere una valenza in termini di sicurezza, non tanto delle transazioni quanto della integrità della chain, ma vedo che il mio progetto non riscuote molte simpatie......  

Ad ogni modo, grazie!

[gbianchi]

Al di là del tecnicismo (non sono un programmatore e non saprei da dover partire), mi chiedevo se comunque questa mia idea aiuta la sicurezza in termini di immutabilità della chain.
Avere un archivio con tutti gli identificativi del blocco, ora e data di validazione,  i rispettivi cash e i rispettivi golden nonce, per quello che posso capire io (ed è il motivo per cui mi confronto qui), potrebbe essere una valenza in termini di sicurezza, non tanto delle transazioni quanto della integrità della chain, ma vedo che il mio progetto non riscuote molte simpatie......  

Ad ogni modo, grazie!

Come ti ho spiegato NON aiuta, perche' le poche informazioni che ti vorresti archiviare NON sono sufficenti
a darti una garanzia di congruenza dei dati.

Non si tratta di simpatia o antipatia, ma di verifica delle informazioni: se il nodo non ha modo di verificare
che le informazioni archiviate  siano corrette, non puo' garantire che la sua copia di blockchain sia corretta.

Ti faccio un esempio ancor piu' pratico:

supponi che tu al tempo t abbia costruito una chain sintetizzata come dici tu.
supponi che al tempo t+1 un virus (strutturato apposta) ti modifichi la chain sintetizzata.
al tempo t+2 tu non hai modo di verificare se cio' e' successo, quindi ti troveresti sempre nel dubbio
se le tue info sono corrette o no, senza possibilita' di auto-verifica, per fare una verifica dovresti
interrogare altri nodi della chain.

Tra l'altro se la maggioranza dei nodi fosse fatta cosi',  sarebbe un vero guaio per la rete.

[babo]

la butto li, ho letto che vorresti un dataset leggero
scusa allora a cosa ti serve un nodo? tanto avere appunto solo il dataset leggero che ti costruisci tu partendo da dati che puoi prendere online

ma la prima cosa che ti devichiedere e', cosa mi serve? cosa ci devo fare?

[DensBTC]

Tra l'altro se la maggioranza dei nodi fosse fatta cosi',  sarebbe un vero guaio per la rete.

Sarebbe una schifezza molto simile alla rete Eth, dove vantano un buon numero di Full Node ma in realtà gli unici veri Full Node sono quelli che vengono definiti Archive e sono gli unici ad avere in pancia tutta la blockchain, sono enormi e costosissimi da operare, non si riesce a capire quanti sono ma curiosando un po' in giro e incrociando i vari IP si va a finire su poche macchine in 2 o tre datacenter, in pratica il "Libro Mastro" di Eth sta in 3 capannoni operati da Amazon... e chi controlla quei "Full Node Archive" può riscrivere o cancellare la storia di Eth...

[nondormomai]

Vi ringrazio dei contributi.

Sono ancora molto naive del settore e mi piace condividere questa idea, anche per vedere se sta in piedi.

Per come la vedo io, ma posso sbagliare e questa discussione serve anche a questo, avere un dataset leggero è meglio che non avere nulla.

Il sistema di concatenazione degli Hash, se ho capito bene, permette di avere certezza che il contenuto non sia stato modificato. Ma qui mi è stato spiegato che non è così e devo dire che non l'ho capito molto....... ma è un mio limite......

In qualche modo, la cosa si congiunge al discorso "ZKproof": metto su un sistema che assicura che i blocchi siano sempre quelli senza esporne il contenuto.
Questo, a mio sommesso parere, ne favorisce la diffusione.

Parto dal mio caso: io volentieri installerei un full node, ma con una logica "a cipolla". insomma partirei da un layer di dataset molto leggero, per poi valutare se scaricare anche tutto il contenuto di tutti i blocchi, se l'hardware me lo contente.

In questi giorni mi sto adoperando per un full node, con un SSD specifico, e senza intenzione di fare minino o utilizzare il wallet nativo. Sto lottando per lasciare la cartella con tutti i dati della chain su un server che sto installando qui in casa, come fosse un disco remoto al quale accedono i devices e i computer della casa. Insomma, sperimento, sbaglio e vado avanti.......




Non conoscevo la situazione della chain di ETH, ma capisco che la centralizzazione lì è molto molto molto più forte...............

[gbianchi]

Il sistema di concatenazione degli Hash, se ho capito bene, permette di avere certezza che il contenuto non sia stato modificato. Ma qui mi è stato spiegato che non è così e devo dire che non l'ho capito molto....... ma è un mio limite......

Le minime informazioni che ti servono per rigenerare (o verificare) gli hash della catena sono:

Hash del blocco = hash256(hash256(
Versione 4 byte di versione del blocco,
Hash Blocco precedente,
MerkleRoot hash del blocco attuale,
Time 32 bit di timestamp del blocco,
Nonce 32 bit di nonce
)

(Il tutto deve essere codificato in little-endian, ossia i byte meno significativi dei vari componenti sono a sinistra)

se ti salvi ALMENO questo dati, puoi creare una catena di hash verificabili e quindi non modificabili singolarmente,
questa procedura e' descritta al punto 8 del white-paper per un cosidetto nodo SPV:

https://bitcoin.org/bitcoin.pdf

Ovviamente qui hai i vari merkle root che non sono verificabili, in quanto formati dall'hash di tutte le transazioni che hai "prunato",
ma almeno fatto cosi' puoi verificare la catena.

[nondormomai]

Il sistema di concatenazione degli Hash, se ho capito bene, permette di avere certezza che il contenuto non sia stato modificato. Ma qui mi è stato spiegato che non è così e devo dire che non l'ho capito molto....... ma è un mio limite......

Le minime informazioni che ti servono per rigenerare (o verificare) gli hash della catena sono:

Hash del blocco = hash256(hash256(
Versione 4 byte di versione del blocco
Hash Blocco precedente
MerkleRoot hash del blocco attuale
Time 32 bit di timestamp del blocco
Nonce 32 bit di nonce
)

(Il tutto deve essere codificato in little-endian, ossia i byte meno significativi dei vari componenti sono a sinistra)

se ti salvi ALMENO questo dati, puoi creare una catena di hash verificabili e quindi non modificabili singolarmente,
questa procedura e' descritta al punto 8 del white-paper per un cosidetto nodo SPV:

https://bitcoin.org/bitcoin.pdf

Ovviamente qui hai i vari merkle root che non sono verificabili, in quanto formati dall'hash di tutte le transazioni che hai "prunato",
ma almeno fatto cosi' puoi verificare la catena.

Ma grazie!

Troppo complicato per me. Me lo rileggo e prima o poi ci arrivo....... eh eh eh

[bastisisca]

Ma grazie!

Troppo complicato per me. Me lo rileggo e prima o poi ci arrivo....... eh eh eh

Nel caso dovessi capirci qualcosa non ti scordare di farci sapere come hai fatto.
Anche a me interessa fare le stesse cose che stai facendo tu.
Grazie

[nondormomai]

Ma grazie!

Troppo complicato per me. Me lo rileggo e prima o poi ci arrivo....... eh eh eh

Nel caso dovessi capirci qualcosa non ti scordare di farci sapere come hai fatto.
Anche a me interessa fare le stesse cose che stai facendo tu.
Grazie

Ho fatto qualche tentativo ma non sono arrivato a nulla.

Ricapitoliamo.....

Avendo un vecchio hardware con pochissimo spazio mi era venuta in mente l'idea di runnare un nodo che definirei "light", ovvero senza scaricare tutta la chain, ma solo alcuni dati.
Pensavo che
1) numero progressivo del blocco, eventualmente con timestamp UTC, dal blocco genesi fino all'ultimo minato
2) hash del blocco esposto nell'header
3) numero nonce
sarebbero stati sufficienti.

Mi avete detto che la cosa non ha senso perché i dati non sarebbero tali da garantire la validità della chain.
In sostanza, è come sei io creassi un dataset che resta sempre sincronizzato con la chain. Cosa succede in caso si verifichi una discrepanza tra i miei dati e quelli della chain? al massimo si dimostra che io sono de-sincronizzato, mentre la chain principale va avanti fregandosene di me.

Allora facciamo un ragionamento diverso.
Lo scenario di partenza è sempre lo stesso: un hardware con poco spazio, che non posso espandere. Mi scarico l'ultima versione di bitcoin core, che dovrebbe essere la 26.

Le domanda sono :
A) esiste un modo per avviare la sincronizzazione a partire dal blocco temporalmente più recente verso i più vecchi e non dal blocco genesi in avanti (quindi un pruned node, ma con direzione temporale dal recente al vecchio)?
B) se ciò è possibile, esiste un modo per fermare limitare la sincronizzare solo ai 1000 blocchi più recenti, in modo da non saturare l'hard disk?

Grazie della vostra collaborazione

[fillippone]

Innanzitutto, occhio al quote del messaggio: il tuo post è finito interamente dentro il quote del messaggio di bastisisca (devi scrivere dopo il tag [/quote], non prima).

Per quanto riguarda le tue domande, non saprei aiutarti. ed ho il sospetto che l'affaire Ordinals non aiuti chi vuole avere un pruned node.
Hai provato, nel caso, a chiedere nella sezione internazionale?

[gbianchi]

Le domanda sono :
A) esiste un modo per avviare la sincronizzazione a partire dal blocco temporalmente più recente verso i più vecchi e non dal blocco genesi in avanti (quindi un pruned node, ma con direzione temporale dal recente al vecchio)?
B) se ciò è possibile, esiste un modo per fermare limitare la sincronizzare solo ai 1000 blocchi più recenti, in modo da non saturare l'hard disk?

Grazie della vostra collaborazione

in bitcoin core ci sono alcune api che ti potrebbero servire per fare il discorso che dici tu:

getblockcount che ti torna quanti blocchi ci sono attualmente nella blockchain,
getblockhash che ti torna l'hash di un blocco data la sua altezza, ossia il numero di blocco.
getblock che ti torna il contenuto di un blocco dato il suo hash

quindi la cosa e' teoricamente fattibile.

Pero' in questo modo non riesci a riprodurti un set di UTXO consistente, ossia non sei certo delle UTXO,
perche' non sai se il tuo indirizzo (tuoi indirizzi) sono stati movimentati in blocchi piu' vecchi che non hai caricato....

Inoltre un altro problema che vedo e' che in ogni caso dovresti avere un provider di servizio centralizzato che ti fornisce questi dati
per avviare i clienti "ridotti", e quindi la gente deve fidarsi di tale provider di servizi.