In brevissimo (tralascio dettagli e sfumature altrimenti dovrei scrivere un intero articolo :)): opzione è già presente, semplicemente non è attiva di default ma va attivata manualmente. Timore principale di Carvalho (oltre ad altri ben più sensati, come quello dell’eccessiva attività su Core) è che questo porterà molti a sfruttarla facendo fuori i casi d’uso dei business che lavorano con 0-conf (Atm per esempio, ma anche la stessa azienda di Carvalho).
Personalmente sono un po’ combattuto perché A) Viva il libero mercato: una transazione senza conferme (nel lungo periodo) non dovrebbe essere considerata valida (c’è Lightning), per cui se l’utilizzo di FullRBF elimina alcuni casi d’uso, pace. Se amiamo il libero mercato amiamo che ci si debba adattare alle novità per non essere tagliati fuori.
Ma B) c’è n’è davvero bisogno? Risposta è no e Carvalho ha ragione quando dice che si stanno proponendo troppe cose da implementare su Core. Basta, non ha senso, Core funziona. Meglio concentrarsi su un paio di cose importanti (come sottolinea spesso Giacomo Zucco, per esempio, il soft fork CISA) e poi basta, si lavora su Lightning, RGB, layer successivi. C’è tanto da fare. A un certo punto Core non va più toccato. Quindi, dato che non è un upgrade fondamentale per Bitcoin, io non credo che aggiornerò il mio nodo (salvo che ulteriori opinioni molto ben argomentate mi facciano cambiare idea 😄)
Ciao Federico, non mi è chiara una cosa: le transazioni che erano state inserite nel blocco 4a, una volta che la catena continua con 4b-5b-6b....che fine fanno ? vengono reinserite nei blocchi successivi ? e se quando erano state inserite nel 4a risultavano avere una conferma, poi come si contano le conferme successive ? Grazie ☺️
Ottima domanda! Quando il nodo si accorge che la catena giusta è l’altra, come scritto, scarta il blocco 4a. Questo significa che le transazioni al suo interno tornano in mempool, cioè quel “limbo” in cui le transazioni attendono di essere inserite in un blocco. Le transazioni, che essendo nel blocco 4a avevano 1 conferma, perdono quella conferma e tornano in mempool. Verranno poi inserite nei blocchi successivi, quindi 6b, 7b ecc. È il motivo per cui si considera che una transazione possa essere considerata definitivamente scolpita nella blockchain solo dopo 6 conferme (6 blocchi) anche se un fork di 6 blocchi è quasi impossibile. Già è piuttosto raro un fork di 2 blocchi, la stragrandissima maggioranza sono fork di 1 blocco come nell’esempio dell’articolo. Quindi, recap: blocco scartato, transazioni tornano in mempool perdendo la conferma che avevano, vengono reinserite in uno o più blocchi successivi acquisendo di nuovo la prima conferma. Una volta ottenuta la prima conferma si aggiungeranno la seconda, la terza, la quarta ecc man mano che vengono minati blocchi sopra a quello in cui sono state inserite.
P.S: potresti spiegare anche la tua idea riguardo il prossimo aggiornamento 24.0.0 di Bitcoin Core relativamente alla diatriba 0Conf ?
Difficile esaurire la risposta in poche righe.
In brevissimo (tralascio dettagli e sfumature altrimenti dovrei scrivere un intero articolo :)): opzione è già presente, semplicemente non è attiva di default ma va attivata manualmente. Timore principale di Carvalho (oltre ad altri ben più sensati, come quello dell’eccessiva attività su Core) è che questo porterà molti a sfruttarla facendo fuori i casi d’uso dei business che lavorano con 0-conf (Atm per esempio, ma anche la stessa azienda di Carvalho).
Personalmente sono un po’ combattuto perché A) Viva il libero mercato: una transazione senza conferme (nel lungo periodo) non dovrebbe essere considerata valida (c’è Lightning), per cui se l’utilizzo di FullRBF elimina alcuni casi d’uso, pace. Se amiamo il libero mercato amiamo che ci si debba adattare alle novità per non essere tagliati fuori.
Ma B) c’è n’è davvero bisogno? Risposta è no e Carvalho ha ragione quando dice che si stanno proponendo troppe cose da implementare su Core. Basta, non ha senso, Core funziona. Meglio concentrarsi su un paio di cose importanti (come sottolinea spesso Giacomo Zucco, per esempio, il soft fork CISA) e poi basta, si lavora su Lightning, RGB, layer successivi. C’è tanto da fare. A un certo punto Core non va più toccato. Quindi, dato che non è un upgrade fondamentale per Bitcoin, io non credo che aggiornerò il mio nodo (salvo che ulteriori opinioni molto ben argomentate mi facciano cambiare idea 😄)
grazie mille, aspetterò anch’io allora 👍
Ciao Federico, non mi è chiara una cosa: le transazioni che erano state inserite nel blocco 4a, una volta che la catena continua con 4b-5b-6b....che fine fanno ? vengono reinserite nei blocchi successivi ? e se quando erano state inserite nel 4a risultavano avere una conferma, poi come si contano le conferme successive ? Grazie ☺️
Ottima domanda! Quando il nodo si accorge che la catena giusta è l’altra, come scritto, scarta il blocco 4a. Questo significa che le transazioni al suo interno tornano in mempool, cioè quel “limbo” in cui le transazioni attendono di essere inserite in un blocco. Le transazioni, che essendo nel blocco 4a avevano 1 conferma, perdono quella conferma e tornano in mempool. Verranno poi inserite nei blocchi successivi, quindi 6b, 7b ecc. È il motivo per cui si considera che una transazione possa essere considerata definitivamente scolpita nella blockchain solo dopo 6 conferme (6 blocchi) anche se un fork di 6 blocchi è quasi impossibile. Già è piuttosto raro un fork di 2 blocchi, la stragrandissima maggioranza sono fork di 1 blocco come nell’esempio dell’articolo. Quindi, recap: blocco scartato, transazioni tornano in mempool perdendo la conferma che avevano, vengono reinserite in uno o più blocchi successivi acquisendo di nuovo la prima conferma. Una volta ottenuta la prima conferma si aggiungeranno la seconda, la terza, la quarta ecc man mano che vengono minati blocchi sopra a quello in cui sono state inserite.
grazie mille, anche perché se devo orangepillare gli amici, devo prima capire per bene io 😜