Valore timestamp prossimo blocco, dubbi e curiosità varie

[Wrib]

Ciao a tutti, stavo ripassando il meccanismo con cui viene deciso il timestamp da inserire nel prossimo blocco:

https://learnmeabitcoin.com/technical/block/time/


Affinchè il timestamp che un miner inserisce nel prossimo blocco sia considerato valido deve rispettare queste regole:

1)essere maggiore del timestamp mediano degli ultimi 11 blocchi
2)essere minore del "network adjusted time" + 2 ore

La condizione uno è un'informazione puramente onchain, il che la rende una normalissima condizione di validazione come tutte le altre.

La condizione 2 è una particolarità, è l'unica regola di consenso che non è basata su dati presenti nei blocchi ma su dati locali dei computer:

The two hour rule is really weird. It's the only 'consensus' rule that isn't based on blockchain data but on local data.
John Newbery, Bitcoin Core PR Review Club (Jun 19, 2019)

Questo "network adjusted time" è calcolato da ogni computer del network come il local time di se stesso (localhost) al quale somma gli offset dei locatime che gli comunicano i nodi diretti vicini, è una sorta di stima grezza del tempo attuale ottenuta mediando tra più nodi in modo che le imprecisioni che possono esserci tra le varie macchine si compensino a vicenda. Qui è spiegato meglio: https://learnmeabitcoin.com/technical/block/time/#network-adjusted-time

Quindi tornando alla regola 2, in pratica per validare il timestamp di un nuovo blocco ogni nodo che lo riceve calcola il suo "network adjusted time" ci aggiunge 2 ore di sicurezza e considera valido il nuovo blocco se ha un timestamp minore di tale valore.

Qui c'è il mio dubbio: questa validazione si può fare solo quando si riceve l'ultimo blocco appena minato? Come si applica questa regola di validazione ai nodi vecchi già presenti in blockchain? Mentre il mio full node si sincronizza da zero e rivalida tutto dall'inizio, come fa a sapere quel era il "network adjusted time" di un blocco del passato dato che è un'informazione che si basa sui dati locali del pc (il suo tempo macchina attuale) in un certo preciso momento?

Poi mi viene da pensare al caso di un "inverno del mining", immaginiamo l'evento estremo in cui il mining viene bannato in contemporanea in alcune nazioni del mondo, ma in modo repressivo andando proprio a sequestrare i datacenter senza permettergli di dislocare in altri luoghi del mondo la loro potenza di calcolo. L'inverno del mining durerà fino al raggungimento del blocco di fine epoca quando verrà riaggiustata al ribasso la difficoltà del mining.

Ci troveremo con una difficoltà elevata e una potenza globale di calcolo non sufficiente per creare un blocco ogni 10 minuti, probabilmente un nuovo blocco verrà creato mediamente ogni 20 minuti. Ma estremizziamo l'esempio e immaginiamo che un nuovo blocco in questo "inverno del mining" venga creato ogni 3 ore.

In questo caso penso di aver capito perchè il "network adjusted time" è basato su dati locali e non su dati onchain. Se fosse basato sul timestamp dell'ultimo blocco valido non si potrebbe più creare un blocco valido perchè il timestamp non sarebbe mai entro le 2 ore dall'ultimo. Ma essendo basato sui local time delle macchine non c'è questo problema.

Ho detto qualche inesattezza nel provare a ricostruire il maccanismo? Qualcuno ha delle considerazione/dubbi/curiosità ulteriori rispetto questo argomento? Grazie a tutti coloro che parteciperanno alla discussione

[gbianchi]

...



Affinchè il timestamp che un miner inserisce nel prossimo blocco sia considerato valido deve rispettare queste regole:

1)essere maggiore del timestamp mediano degli ultimi 11 blocchi
2)essere minore del "network adjusted time" + 2 ore


....

La risposta te la sei gia' scritta.

Non e' una vera regola di consenso, ma e' solo una regola per la scrittura del prossimo blocco.

Le regole di consenso possono essere ricalcolate da chiunque in qualsiasi momento e desunte dai soli dati della blockachain.

Questa invece e' logicamente simile al campo timelock, ossia una regola che non permette di scrivere il blocco prima di un certo momento, ma poi non viene piu' riverificata da nessuno.

Da un punto di vista formale non e' elegantissimo, perche' introduce implicitamente due livelli di controllo di consenso:
uno "hard", ossia  il consenso verificabile sempre e comunque da tutti, e uno "soft", ossia verificabile sono in sede di
trasferimento del prossimo blocco dalla mempool alla blockchain.

Ma direi che la comodita' che introduce e' superiore alla perdita di eleganza.

[Wrib]

La risposta te la sei gia' scritta.

Non e' una vera regola di consenso, ma e' solo una regola per la scrittura del prossimo blocco.

Le regole di consenso possono essere ricalcolate da chiunque in qualsiasi momento e desunte dai soli dati della blockachain.

Questa invece e' logicamente simile al campo timelock, ossia una regola che non permette di scrivere il blocco prima di un certo momento, ma poi non viene piu' riverificata da nessuno.

Da un punto di vista formale non e' elegantissimo, perche' introduce implicitamente due livelli di controllo di consenso:
uno "hard", ossia  il consenso verificabile sempre e comunque da tutti, e uno "soft", ossia verificabile sono in sede di
trasferimento del prossimo blocco dalla mempool alla blockchain.

Ma direi che la comodita' che introduce e' superiore alla perdita di eleganza.

Grazie per la risposta.

C'è una cosa che non mi è chiara.

La mempool è un buffer di richieste di transazioni, il miner sceglie tra questo buffer quali transazioni utilizzare per la costruzione del prossimo blocco. Se il miner è il primo a costruire un blocco valido quindi lo invia alla rete. Come si realizza, per il resto dei nodi, la discriminante informatica tra "nodi già validati per i quali non applico la regola del local time + 2 ore" e ultimo nodo appena minato per il quale "applico la regola del local time + 2 ore"?

[gbianchi]

La risposta te la sei gia' scritta.

Non e' una vera regola di consenso, ma e' solo una regola per la scrittura del prossimo blocco.

Le regole di consenso possono essere ricalcolate da chiunque in qualsiasi momento e desunte dai soli dati della blockachain.

Questa invece e' logicamente simile al campo timelock, ossia una regola che non permette di scrivere il blocco prima di un certo momento, ma poi non viene piu' riverificata da nessuno.

Da un punto di vista formale non e' elegantissimo, perche' introduce implicitamente due livelli di controllo di consenso:
uno "hard", ossia  il consenso verificabile sempre e comunque da tutti, e uno "soft", ossia verificabile sono in sede di
trasferimento del prossimo blocco dalla mempool alla blockchain.

Ma direi che la comodita' che introduce e' superiore alla perdita di eleganza.

Grazie per la risposta.

C'è una cosa che non mi è chiara.

La mempool è un buffer di richieste di transazioni, il miner sceglie tra questo buffer quali transazioni utilizzare per la costruzione del prossimo blocco. Se il miner è il primo a costruire un blocco valido quindi lo invia alla rete. Come si realizza, per il resto dei nodi, la discriminante informatica tra "nodi già validati per i quali non applico la regola del local time + 2 ore" e ultimo nodo appena minato per il quale "applico la regola del local time + 2 ore"?

Interessante domanda....

immagino che sul blocco piu' recente (AKA quello con l'altezza massima nella catena che sto controllando, quindi l'ultimo)
si applica il controllo e su tutti gli altri no, poi magari c'e' pure un controllo incrociato con la mempool.

Oppure che se sono nello stato "not synch" con il resto della rete il controllo non si applica, e invece se sono synch si applica (sempre sull'ultimo blocco)

Pero' per la risposta certa dovremmo guardare nel codice.

[gbianchi]

Grazie per la risposta.

C'è una cosa che non mi è chiara.

La mempool è un buffer di richieste di transazioni, il miner sceglie tra questo buffer quali transazioni utilizzare per la costruzione del prossimo blocco. Se il miner è il primo a costruire un blocco valido quindi lo invia alla rete. Come si realizza, per il resto dei nodi, la discriminante informatica tra "nodi già validati per i quali non applico la regola del local time + 2 ore" e ultimo nodo appena minato per il quale "applico la regola del local time + 2 ore"?

Per generalizzare un po', e' il motivo per il quale sono sempre stato MOLTO scettico sugli oracoli.

Introdurre nel meccanismo di consenso "decisioni" che non sono endogene alla blockchain,
costringe ad avere valori controllati una sola volta in fase di scrittura e poi presi per buoni per sempre.

il concetto di oracolo e' estremamente nocivo per la congruita' del consenso.
Fortunatamente, pare sia un concetto definitivamente passato di moda

[Wrib]

Per generalizzare un po', e' il motivo per il quale sono sempre stato MOLTO scettico sugli oracoli.

Introdurre nel meccanismo di consenso "decisioni" che non sono endogene alla blockchain,
costringe ad avere valori controllati una sola volta in fase di scrittura e poi presi per buoni per sempre.

il concetto di oracolo e' estremamente nocivo per la congruita' del consenso.
Fortunatamente, pare sia un concetto definitivamente passato di moda

Eh mi hai proprio sbloccato un ricordo..si parlava di oracoli per varie cose tipo scommesse pagate automaticamente e addirittura di "assasination markets".  Gli oracoli sono un single point of failure, chi controlla o prende il controllo dell'oracolo decide la verità o spegne l'oracolo. E poi quali sono le informazioni del mondo reale degne di nota da essere gestite dall'oracolo?

Per quel che mi riguarda ciò che sta scritto nella blockchain, rispetta le regole di consenso, e ha un numero ragionevole di blocchi successivi, è una sorta di informazione "verità matematica". Le informazioni che arrivano dall'esterno della chain sono soggette a manipolazione umana, come gli oracoli, ma anche il concetto di tracciare prodotti su una blockchain presenta il problema di fidarsi di chi immette dati sulla chain (oltre al problema che non puoi fare l'impronta hash di un oggetto reale come puoi fare per un documento informatico, quindi non stai tracciando un tubo)..

Comunque questa regola del "local time dei nodi vicini +2 ore" per l'ultimo blocco penso di aver capito che sia una regola tutto sommato buona per evitare di scrivere timestamp troppo assurdi partendo dal presupposto che il timestamp di un blocco non sarà mai un tempo perfetto ma un'indicazione di massima. Immagino che se per assurdo tutti i nodi vicini a chi ha appena propagato un nuovo blocco avessero il localtime sballato di 10 ore nel futuro si potrebbe inserire un timestamp sballato di diverse ore, ma va bene così perchè è una situazione talmente rara e allo stesso insignificante per la validità della chain (ci si terrebbe quel timestamp assurdo e pazienza).

[Italian Panic]

Da quel che ricordo quando studiai il processo: i blocchi già verificati ed accettati dalla rete non subiscono più ricontrolli e non sono sottoposti alla regola local time +2, sono considerati immutabili, giustamente. Poi quando un nodo riceve un nuovo blocco viene verificato il timestamp che non abbia ad esempio una data antecedente il precedente e ne verifica il localtime+2 ma solo su questo non sui precedenti.

Sul fatto che scrivi del timestamp+10 potrebbe essere configurato dalla rete come errore/problema bizantino ed il blocco rifiutato perchè outlier rispetto alla norma; però è anche vero che il processo di convalida non si basa sulla verità assoluta ma sul concetto di coerenza complessiva della rete. Quindi se effettivamente hai un timestamp+10 l'importante è che il successivo blocco abbia timestamp successivo a questo.

[Wrib]

Da quel che ricordo quando studiai il processo: i blocchi già verificati ed accettati dalla rete non subiscono più ricontrolli e non sono sottoposti alla regola local time +2, sono considerati immutabili, giustamente. Poi quando un nodo riceve un nuovo blocco viene verificato il timestamp che non abbia ad esempio una data antecedente il precedente e ne verifica il localtime+2 ma solo su questo non sui precedenti.

Grazie per l'intervento!

Si diciamo che questo mi è chiaro come concetto generale. Quello che mi chiedevo era in termini informatici come avviene esattamente la distinzione tra blocchi per i quali questa regola "offchain" non va più riverificata e l'ultimo blocco per il quale va verificata. Ma come ha scritto gbianchi bisognerebbe guardare il codice sorgente..

[bitcoiner180]

Il timestamp di un blocco deve essere maggiore del timestamp mediano degli ultimi 11 blocchi, quindi può anche essere inferiore al timestamp del blocco precedente e so che ci sono dei casi nella blockchain di Bitcoin di blocchi con un timestamp di qualche minuto superiore al blocco successivo.

Non sottovalutate l'importanza del timestamp. Il timestamp è necessario per calcolare quanto tempo la rete ha impiegato per generare gli ultimi 2016 blocchi (ma anche i 2016 precedenti e così via) e dunque serve per sapere qual'è la difficulty richiesta per considerare il prossimo blocco valido. Non solo! I nodi devono anche verificare che tutti i blocchi della catena abbiano un hash che rispetta la difficulty richiesta quindi il timestamp è molto importante per controllare la validità della catena.

[fillippone]

Poi mi viene da pensare al caso di un "inverno del mining", immaginiamo l'evento estremo in cui il mining viene bannato in contemporanea in alcune nazioni del mondo, ma in modo repressivo andando proprio a sequestrare i datacenter senza permettergli di dislocare in altri luoghi del mondo la loro potenza di calcolo. L'inverno del mining durerà fino al raggungimento del blocco di fine epoca quando verrà riaggiustata al ribasso la difficoltà del mining.

Ci troveremo con una difficoltà elevata e una potenza globale di calcolo non sufficiente per creare un blocco ogni 10 minuti, probabilmente un nuovo blocco verrà creato mediamente ogni 20 minuti. Ma estremizziamo l'esempio e immaginiamo che un nuovo blocco in questo "inverno del mining" venga creato ogni 3 ore.

In questo caso penso di aver capito perchè il "network adjusted time" è basato su dati locali e non su dati onchain. Se fosse basato sul timestamp dell'ultimo blocco valido non si potrebbe più creare un blocco valido perchè il timestamp non sarebbe mai entro le 2 ore dall'ultimo. Ma essendo basato sui local time delle macchine non c'è questo problema.

Ho detto qualche inesattezza nel provare a ricostruire il maccanismo? Qualcuno ha delle considerazione/dubbi/curiosità ulteriori rispetto questo argomento? Grazie a tutti coloro che parteciperanno alla discussione

Secondo me questa regola non impedisce affatto la creazione di un blocco ongi tre ore.
Dice solamente che quando un blocco viene minato il timestamp non deve essere superiore a due ore del "netwokr adjusted time", ovvero del tempo medio del network in quel momento. Il timestamp dell'ultimo blocco, a questo fine, non conta (ovviamente conta per la regola del tempo medio degli ultimi 11 bloccchi).

[Wrib]

Poi mi viene da pensare al caso di un "inverno del mining", immaginiamo l'evento estremo in cui il mining viene bannato in contemporanea in alcune nazioni del mondo, ma in modo repressivo andando proprio a sequestrare i datacenter senza permettergli di dislocare in altri luoghi del mondo la loro potenza di calcolo. L'inverno del mining durerà fino al raggungimento del blocco di fine epoca quando verrà riaggiustata al ribasso la difficoltà del mining.

Ci troveremo con una difficoltà elevata e una potenza globale di calcolo non sufficiente per creare un blocco ogni 10 minuti, probabilmente un nuovo blocco verrà creato mediamente ogni 20 minuti. Ma estremizziamo l'esempio e immaginiamo che un nuovo blocco in questo "inverno del mining" venga creato ogni 3 ore.

In questo caso penso di aver capito perchè il "network adjusted time" è basato su dati locali e non su dati onchain. Se fosse basato sul timestamp dell'ultimo blocco valido non si potrebbe più creare un blocco valido perchè il timestamp non sarebbe mai entro le 2 ore dall'ultimo. Ma essendo basato sui local time delle macchine non c'è questo problema.

Ho detto qualche inesattezza nel provare a ricostruire il maccanismo? Qualcuno ha delle considerazione/dubbi/curiosità ulteriori rispetto questo argomento? Grazie a tutti coloro che parteciperanno alla discussione

Secondo me questa regola non impedisce affatto la creazione di un blocco ongi tre ore.
Dice solamente che quando un blocco viene minato il timestamp non deve essere superiore a due ore del "netwokr adjusted time", ovvero del tempo medio del network in quel momento. Il timestamp dell'ultimo blocco, a questo fine, non conta (ovviamente conta per la regola del tempo medio degli ultimi 11 bloccchi).

Forse sono stato un po' contorto, leggendo la tua precisazione confermo che stiamo dicendo la stessa cosa.

Intendevo proprio dire che si è scelto (per calcolare il "network adjusted time") il time locale del network e non il timestamp dell'ultimo blocco per permettere che un blocco venga creato ogni 3 ore in caso di inverno del mining. Se si fosse scelto il time dell'ultimo blocco on chain, nel caso assurdo di inverno in cui un blocco viene trovato in 3 ore la rete si fermerebbe.

[fillippone]

Poi mi viene da pensare al caso di un "inverno del mining", immaginiamo l'evento estremo in cui il mining viene bannato in contemporanea in alcune nazioni del mondo, ma in modo repressivo andando proprio a sequestrare i datacenter senza permettergli di dislocare in altri luoghi del mondo la loro potenza di calcolo. L'inverno del mining durerà fino al raggungimento del blocco di fine epoca quando verrà riaggiustata al ribasso la difficoltà del mining.

Ci troveremo con una difficoltà elevata e una potenza globale di calcolo non sufficiente per creare un blocco ogni 10 minuti, probabilmente un nuovo blocco verrà creato mediamente ogni 20 minuti. Ma estremizziamo l'esempio e immaginiamo che un nuovo blocco in questo "inverno del mining" venga creato ogni 3 ore.

In questo caso penso di aver capito perchè il "network adjusted time" è basato su dati locali e non su dati onchain. Se fosse basato sul timestamp dell'ultimo blocco valido non si potrebbe più creare un blocco valido perchè il timestamp non sarebbe mai entro le 2 ore dall'ultimo. Ma essendo basato sui local time delle macchine non c'è questo problema.

Ho detto qualche inesattezza nel provare a ricostruire il maccanismo? Qualcuno ha delle considerazione/dubbi/curiosità ulteriori rispetto questo argomento? Grazie a tutti coloro che parteciperanno alla discussione

Secondo me questa regola non impedisce affatto la creazione di un blocco ongi tre ore.
Dice solamente che quando un blocco viene minato il timestamp non deve essere superiore a due ore del "netwokr adjusted time", ovvero del tempo medio del network in quel momento. Il timestamp dell'ultimo blocco, a questo fine, non conta (ovviamente conta per la regola del tempo medio degli ultimi 11 bloccchi).

Forse sono stato un po' contorto, leggendo la tua precisazione confermo che stiamo dicendo la stessa cosa.

Intendevo proprio dire che si è scelto (per calcolare il "network adjusted time") il time locale del network e non il timestamp dell'ultimo blocco per permettere che un blocco venga creato ogni 3 ore in caso di inverno del mining. Se si fosse scelto il time dell'ultimo blocco on chain, nel caso assurdo di inverno in cui un blocco viene trovato in 3 ore la rete si fermerebbe.

Ok, perfetto.
Comunque mi hai fatto venire in mente che Valerio Vaccaro aveva qualche anno addietro, introdotto il trustless clock, che si collegava al network di bitcoin per estrarre il temppo medio della rete: