[IMPORTANTE] Upgrade a bitcoin core 0.16.3

[arulbero]

Questa lentezza di adeguamento mi fa dubitare di quanto  possa funzionare "il modello",
nel senso che piu' la rete cresce, piu' sara' lenta a recepire modifiche.

Supponiamo che fra due anni ci siano 20.000 full node e viene fuori un altro bug cosi' pesante, e che
la rete ci metta 1 mese ad adeguarsi, esponendo nel frattempo tutti i partecipanti ad un lungo periodo
di "dita incrociate e speriamo in dio", come fondamentalmente sta succedento tutt'ora, mentre scrivo.

Come modello di sicurezza e di "store of value" non mi pare il massimo.

Come "store of value" invece io non vedo un grosso problema, i bug di per sè non "dovrebbero" mai riguardare i bitcoin depositati, ma al più potrebbero riguardare (come in questo caso) eventuali transazioni che verrebbero cancellate nel giro di qualche decina massimo di blocchi.

In sostanza il momento delicato è solo quello subito dopo una transazione (per chi la riceve), se mai invece dovesse uscire un bug per il quale i bitcoin depositati su un indirizzo da 20mila blocchi risulterebbero a rischio allora tutto il sistema imploderebbe, su questo non ho dubbi.


Io vedo bitcoin come un sistema che ti garantisce con probabilità crescente in un tempo ragionevolmente contenuto lo stoccaggio di valore. E' vero che normalmente si dice che 6 transazioni di fatto equivalgono a sicurezza di irreversibilità, però il bug di questi giorni (e non solo) ci dice che nei 3mila e rotti giorni di vita del bitcoin ci sono stati più momenti nei quali la "sicurezza" entro le 6 conferme era solo illusoria (nel senso che la probabilità di una riorganizzazione della chain era - come ora - molto più alta del consueto).

In definitiva l'idea che in 1 ora in media si abbia la conferma "definitiva" di una tx è un'approssimazione molto grossolana, e soprattutto chi dovesse movimentare grosse cifre non dovrebbe mai, alla luce degli ultimi eventi, considerare definitiva una transazione per almeno un giorno o due.

[gbianchi]

Come "store of value" invece io non vedo un grosso problema, i bug di per sè non "dovrebbero" mai riguardare i bitcoin depositati, ma al più potrebbero riguardare (come in questo caso) eventuali transazioni che verrebbero cancellate nel giro di qualche decina massimo di blocchi.

Non ne sono tanto sicuro.

proviamo a immaginare questo scenario:

domani (spero di non portare sfiga) qualcuno USA il bug attuale,e scamma di brutto qualcun altro.
ovviamente questa cosa avra' un grande eco mediatico

"Bitcoin non e' sciuro" "Scoperto BUG bitcoin che lo rende inaffidabile" o robe simili.

Ovviamente tutto cio' avrebbe un'influenza estremamente negativa sulla credibilita'
della rete e in generale di tutto il mondo delle crypto.

Come ripercussione, probabilmente ci sarebbe anche un impatto su investimenti,
adoption, e quindi anche prezzo.

quindi anche un bug che non INFICIA direttamente il  "numero di bitcoin posseduti"
inficia pero' sulla credibilita' della rete, e quindi sul suo valore, probabilmente il suo valore piu' profondo.

Io per primo non sono cosi' tranquillo in questi giorni, evito di fare transazioni,
voglio capire meglio cosa succede.

Insomma resto convinto che la velocita' di risoluzione e PROPAGAZIONE delle patch di eventuali bug
(che succedereanno di sicuro, la perfezione non e' umana) sia un parametro IMPORTANTISSIMO nella
valutazione complessiva di una rete come Bitcoin.

Per capirci meglio, secondo me dovrebbe esserci nel design un "sistema a premio"
per incentivare il piu' velocemente possibile la diffusione patch di importanza vitale.

Ovviamente non ho analizzato tecnicamente come si potrebbe fare, lo dico solo
per far capire il concetto, di quanto sia importante secondo me tenere conto nel
progetto anche la possibilita' di BUG e come gestirli il piu' velocemente possibile.


EDIT in questo istante, viene indicato che il 48% dei full node e' protetto,
quindi la maggioranza sono ancora buggati, procedendo a questa velocita' serviranno
ancora 3 giorni per mettere in sicurezza un altro 3% che portera almeno il 51% dei full node
ad essere protetti. E non so se ancora la situazione sarebbe cosi' "fuori pericolo",
e ci sarebbero voluti 11 giorni ad arrivare a questo risultato. Decisamente troppi
secondo me.

[arulbero]

In questo post:

https://bitcointalk.org/index.php?topic=5037728.msg46172458#msg46172458

Gregory Maxwell (uno degli sviluppatori di Core) afferma, contrariamente a quanto stiamo discutendo qui, che

1) non c'è affatto grossa urgenza di aggiornare i nodi

2) il fatto che un nuovo aggiornamento richieda del tempo prima che si propaghi per la rete è un bene, non un male

If a user isn't accepting transactions on a node or mining with it, there is no particularly urgent reason to upgrade.  There are plenty of upgraded nodes on the network now.

The reason the notices encourage people to upgrade urgently is not because all actually need to, but because figuring out if you really need to or not is hard, so the best advice is for everyone to do it.

[...]

... against the risk of a malicious update being deployed.  The fact that upgrades take a while makes me feel confident rather than frightened.

It's like the advice goes, "if you never miss a flight, you're probably wasting too much time in airports".  If we never had reason to wish updates went faster, we'd probably be excessively exposing users to the risk of a bad update.

If there ever were a really serious issue where updates had to happen or else, we'd be probably advising people to stop accepting confirmations and to potentially to turn their nodes off.

[gbianchi]

It's like the advice goes, "if you never miss a flight, you're probably wasting too much time in airports".  If we never had reason to wish updates went faster, we'd probably be excessively exposing users to the risk of a bad update.

If there ever were a really serious issue where updates had to happen or else, we'd be probably advising people to stop accepting confirmations and to potentially to turn their nodes off.

[/quote]

come argomentazione non mi sembra tanto acuta.

nel senso che per gli upgrade "normali", per il normale sviluppo del software e' correttissimo che il
processo sia lento e piu' controllato possibile.

Ma qui parliamo di un bug (anche se non questo, diciamo un possibile bug futuro grave e potenzialmente disastroso)

e questa affermazione

"If there ever were a really serious issue where updates had to happen or else, we'd be probably advising people to stop accepting confirmations and to potentially to turn their nodes off."

e' veramente poco scientifica, "se un giorno verra' fuori un bug serio probabilmente avviseremo la gente di spegnere i loro nodi"
ma in che modo? e come incentivarli a spegnerli?  e se alcuni nodi sono accesi proprio per motivi malevoli?

potrebbe averlo detto anche gesu' cristo in persona, ma non mi pare che sia un modo di argomentare scientifico,
anzi forse mi spavento ancora di piu' se lo sviluppo viene affrontato con questo spirito!


BItcoin e' (era?) un esperimento e doveva servire a scoprire e correggere i punti deboli.
L'impressione che ho e' che ormai la gente abbia cosi' tanti interessi personali coninvolti
che tende sempre a minimizzare i problemi, invece che tentare di risolverli o mitigarli in modo oggettivo.

[Makkara]

1) non c'è affatto grossa urgenza di aggiornare i nodi

2) il fatto che un nuovo aggiornamento richieda del tempo prima che si propaghi per la rete è un bene, non un male

In realtà non dice esattamente quello che scrivi sopra, o meglio, lo dice, ma in un contesto leggermente diverso e il significato cambia di parecchio.

[arulbero]

1) non c'è affatto grossa urgenza di aggiornare i nodi

2) il fatto che un nuovo aggiornamento richieda del tempo prima che si propaghi per la rete è un bene, non un male

In realtà non dice esattamente quello che scrivi sopra, o meglio, lo dice, ma in un contesto leggermente diverso e il significato cambia di parecchio.

Hai ragione, forse ho semplificato un po' troppo per amore di sintesi. Provo allora a puntualizzare meglio anche la mia posizione.


Il punto fondamentale della questione per me è che ci sono 2 situazioni ben differenti:

a) un conto è un bug che modifica inavvertitamente il protocollo
b) un conto è il problema del 51% attack (che vuol dire effettuare un attacco alla rete rispettando il protocollo)

Di norma un nodo (full node) della rete è sostanzialmente autonomo, nel senso che è in grado in piena autonomia di stabilire se la blockchain che va aggiornando segue il protocollo. In un certo senso un nodo potrebbe anche funzionare da solo. Questo è un punto importante, io sono in grado da solo di stabilire, guardando il contenuto dei blocchi nel mio pc, se un certo insieme di regole (che sono ormai predefinite da tempo, hf a parte) vengono rispettate o meno.
Faccio notare che nel caso del bug in questione nel giro di 1 giorno chi era veramente interessato ha potuto aggiornare il proprio sistema.

Da questo punto di vista che la rete sia formata da 3 nodi o 30000 nodi è indifferente, così come è indifferente se l'80% dei nodi è "malevola" (=violare le regole in modo consapevole o meno), nel senso che anche avendo la maggioranza della "forza di validazione e trasmissione" dei blocchi, il loro comportamento non mi fa deragliare in una catena non valida. Quindi ripeto un nodo onesto se ne frega dell'onestà degli altri nodi (e anche dell'onestà dei miner).

L'unico punto delicato del sistema bitcoin è attaccarlo rispettandone le regole, e cioè con un 51% attack. Ma questo non si può fare appunto violando le regole.

Riassumendo, se io ho un nodo aggiornato, e mi premuro di aggiornarlo immediatamente soprattutto appena esce un bug importante, nessuno mi può imbrogliare. La mia tranquillità non può e non deve basarsi sull'onestà del comportamento degli altri nodi o sulla loro sollecitudine ad aggiornarsi (come invece mi sembra suggerisca gbianchi), io rischio di essere vittima di una "vera" doppia spesa solo nel  caso in cui una parte della rete mini per un po' di tempo dei blocchi di nascosto e poi li immetta di colpo in rete, cioè nel caso (legittimo dal punto di vista del protocollo) nel quale la maggioranza dell'hash power non corrisponda a quello che sembra.

E' in questo senso che io ho interpretato il discorso di Maxwell, se la sicurezza della rete dipendesse dalla onestà dei nodi allora sì che avremmo un grosso problema di sicurezza.

Ovviamente da questo discorso rimangono tagliati fuori tutti coloro che usano wallet leggeri, senza blockchain, e che quindi si fidano sempre di qualcun altro, questi sì che devono sperare che coloro di cui si fidano siano onesti, ma non è questo mi pare lo spirito di bitcoin.

[arulbero]

Bug del kernel di Linux:

https://thehackernews.com/2018/09/linux-kernel-vulnerability.html?m=1

Periodo di bug, nessun software per quanto controllato ne è esente, questo mi fa riflettere sulla probabilità che il software che si sta usando attualmente (relativo a bitcoin o meno) possa avere delle vulnerabilità che verranno sfruttate da qualcuno.

Per esempio i calcoli sulla sicurezza della rete bitcoin vengono di norma fatti supponendo che tutte le regole teoriche vengano effettivamente rispettate dai software che le implementano, ma si è visto che ritenere che il software sia "perfetto" è una grossolana approssimazione. Anzi, il rischio di perdere soldi per un bug è più alto del rischio che l'algoritmo ecdsa venga "risolto" oppure che ci sia un attacco del 51%.

Per la cronaca il bug di bitcoin è stato risolto (dalla sua scoperta) in meno di 10 ore ( https://bitcoincore.org/en/2018/09/20/notice/ ). Ma il bug è stato presente per circa 2 anni in più versioni di Bitcoin Core.
La probabilità di essere colpiti direttamente da questo bug dipende dalla probabilità che qualche malintenzionato si accorgesse del bug in questi due anni x la probabilità che, nel caso di un attacco, avessimo usato la rete per transare proprio nel periodo dell'attacco (prima del rilascio del fix).

La prima probabilità è molto difficile da stimare, la seconda dipende dalla velocità di reazione degli sviluppatori che devono rilasciare la patch (ottima, meno di 10 ore dalla scoperta) e dalla frequenza con cui effettuiamo/riceviamo transazioni.

Invece non mi è ancora ben chiaro se il fatto che il resto della rete aggiorni in fretta contribuisca in qualche modo anche alla mia sicurezza.

[alexrossi]

Forse un client semplice senza segwit ne tutto ciò che è possibile mettere in opt out potrebbe migliorare le cose?