Bitcoin Detox 2: Segwit, Taproot e Lightning Network

Segwit, Taproot e Lightning Network

Speaker: Gabriele
Martedì 2 agosto 2022 ore 18:00

Una breve introduzione a due dei più importanti aggiornamenti avvenuti sulla rete di Bitcoin uno più recente ed uno meno, con un’introduzione anche a LN e al suo funzionamento di base.

– Differenze tra Hard Fork e Soft Fork
– Segwit
– P2SH, Segwit Wrapped & Native SegWit
– Transaction Malleability & Lightning Network
– Any One Can Spend
– Taproot
– BIP340: Schnorr Signature
– Pay To Taproot – P2TR

—-
Link della live sui vari social:

Linkedin: https://www.linkedin.com/feed/update/urn:li:ugcPost:6958436195571785730
Youtube: https://www.youtube.com/watch?v=qqx54xKN7OM
Telegram: https://t.me/bitcoindetox
Facebook: https://www.facebook.com/1548239255249886/posts/7900725366667878/
Twitch: https://twitch.tv/Gambaru_Tech

Gabriele:

Ciao a tutti e benvenuti. Bitcoin Detox è una serie di eventi live in cui si parla di Bitcoin, Blockchain e criptovalute nelle sezioni di Bitcoin Pills e Crypto Pills. In generale parleremo di Bitcoin nelle Bitcoin Pills appunto, e a volte, quando lo riteniamo interessante da un punto di vista tecnologico, di privacy, anche di altre cripto, facendo appunto delle Crypto Pills. Non siamo qui per scillare l’ultima criptovaluta che farà la prossima rugpull, ma per fare formazione e informazione sul mondo di Bitcoin, nella Blockchain e delle criptovalute. Nel mondo delle criptovalute esistono sono molti punti di vista diversi. Uno di questi è rappresentato da coloro che si chiamano Bitcoin Maximalist o Bitcoin Toxic Maximalist. Per costoro tutto ciò che non è e non riguarda Bitcoin è uno scam, una truffa, non ha valore e non merita di essere neanche menzionato. E di fatto hanno ragione praticamente quasi sempre. E pur sposando appieno gli ideali dei Bitcoin Maximalist e dei Toxic Maximalist che hanno usato questi termini dispregiativi usati da terze persone indossando una sorta di tuta da supereroe, a noi piace anche parlare di altro. Per noi oggi Bitcoin rimane l’unica criptomoneta che ha veramente senso, ma la tecnologia a nostro parere non ha un colore e per questo a volte parleremo anche di argomenti diversi. Bitcoin Detox è organizzato da Gambaru Tech. Seguiteci sui nostri social e visitate il nostro sito web per scoprire altre informazioni. 

Veniamo all’argomento del giorno. Parleremo di SegWit, Taproot e un minimo di Lightning Network. Iniziamo proprio con Lightning Network. Gli smart contract ci sono anche su Bitcoin. Molti pensano che sia una prerogativa di Ethereum, ma di fatto non è così. L’unica differenza è che gli smart contract che si possono avere su Bitcoin sono molto più semplici. Ethereum al contrario, avendo degli smart contract molto complessi, ha reso chiaramente evidente a tutti che la sua crescita è insostenibile. Questo è un grafico molto famoso di una persona che stava tracciando la crescita di Ethereum, ma poi ad un certo punto ha smesso. Ultimamente sono un po’ diminuite le dimensioni dei nodi però sono sempre insormontabili, sempre gigantesche. Tutti quanti gli addetti del settore sanno benissimo che Ethereum per questo motivo per questa crescita di dati enormi che ha continuamente generato da la grande potenza degli smart contract che di fatto possono generare dei veri e propri programmi a differenza di quelli su Bitcoin che sono piu semplici, ha creato una grandezza della Blockchain tale, per cui la maggior parte delle persone ormai non hanno più il suo nodo molte dapp e applicazioni si appoggiano a Infura, che è un nodo di terze parti, rendendo il tutto molto più centralizzato e meno affidabile da un punto di vista decentralizzazione e quindi di non-attaccabilità. 

Lightning Network è uno degli esempi più illustri di small contract e scritto su Bitcoin. Anche Bitcoin ovviamente ha i suoi problemi. Ha un problema di scalabilità. Abbiamo la possibilità di avere circa 3000 transazioni per blocco, con una media di un blocco di dieci minuti sono 18000 transazioni all’ora più o meno e quindi sono 430.000 transazioni al giorno, in definitiva molto poche per soddisfare una richiesta globale. Quindi una soluzione è che Lightning Network lo vedremo nel dettaglio è bello anche pensarla come una cosa che viene dal passato remoto perché da un certo punto di vista, se guardiamo Lightning Network, è un po come se si usassero degli assegni certificati non da una banca terza ovviamente e quindi da una terza parte, ma certificati dalla Blockchain e gli Smart Contract che sono su questa Blockchain. Quello che viene effettuato sono delle transazioni off-chain cioè per poter migliorare l’efficienza delle transazioni, la velocità e mantenere la Blockchain scalabile quindi al contrario di Ethereum come abbiamo visto per esempio come abbiamo visto di Bitcoin è più scalabile perché la crescita dei dati non è esponenziale, quindi non aumenta tanto nel tempo ma è lineare. E per mantenere questo approccio, questa resilienza della rete di Bitcoin, quello che si usa è fare delle transazioni off-chain. Quindi Lightning Network sono delle transazioni che vengono fatte di fatto tra delle entità al di fuori della Blockchain di Bitcoin.

Adesso vediamo un pochino più nel dettaglio, come per esempio due entità che chiameremo Alice e Bob possono effettuare delle transazioni utilizzando Lightning. La prima azione che Alice e Bob devono fare per poter usare Lightning Network è creare un canale di pagamento. La creazione di un canale si fa attraverso uno Smart Contract che viene “deployato”, messo sulla Blockchain di Bitcoin. E quindi si crea quello che è un payment channell, un canale di pagamento che di fatto non è altro che una relazione finanziaria tra due nodi o due channell partner. Quindi il canale di pagamento è gestito da un processo predefinito basato sulla crittografia usata dai channell partner, quindi dall’entità che fa che costruiscono in questo modo per ridistribuire e di spostare il bilancio del canale verso una parte o verso l’altra. Quindi il payment channell, oltre ad avere queste due parti, ha anche un bilancio che viene depositato all’inizio e che poi viene spostato tra queste due parti. Quindi un canale di pagamento è una relazione finanziaria tra due nodi che versano dei fondi su un indirizzo MultiSig, un indirizzo controllato da più chiavi private attraverso un rigoroso protocollo crittografico.

Alice apre un canale. Prima di tutto Alice per aprire un canale crea una nuova coppia di chiavi. Invia a Bob la sua chiave pubblica, chiedendo di aprire un canale e se Bob è d’accordo, accetta, risponde e condivide anche lui la sua chiave pubblica. Così, con queste due chiavi pubbliche si può creare appunto questo MultiSig, un indirizzo da cui è possibile stendere dei coin solamente se entrambe le firme sono d’accordo. E quindi avviene la creazione appunto di questo MultiSig e poi c’è la prima funding transaction. Quindi Alice in questo genera la funding transaction, per esempio da a questo indirizzo MultiSig che loro insieme hanno pre-generato di cui entrambi detengono una parte del controllo cento K di Satoshi, che non propaga ancora. Quindi Alice prepara questa transazione, non la propaga, rimane come transazione uno delle transazioni che Alice fa e poi effettua una seconda transazione, una transazione di refund che indica che quei soldi che lei ha depositato lì tornano a lei con il bullock time, quindi all’interno di un certo range di tempo.

Che cosa fa quindi Alice, propaga questa transazione e invia a Bob la firma di questa seconda transazione e il transaction ID della precedente la funding transaction. Bob manda Alice la signature della transazione di refund, e quindi Bob conferma ad Alice che anche lui è d’accordo nel firmare la transazione di refund. Non serve scambiarsi la transazione intera, in quanto entrambe le parti possono ricostruirla. L’unica cosa che serve è che vengono scambiate le reciproche firme. Ora che i suoi fondi sono assicurati dalla refund transaction, Alice può propagare la funding transaction. Quindi che cosa fa Alice, prima fondamentalmente genera due transazioni. La prima se la tiene, la seconda chiede a Bob di firmarla. A questo punto, quando lei è confidente di avere la seconda transazione che gli permette di rientrare in possesso dei soldi, qualora Bob volesse agire in modo malvagio, può effettuare la transazione della prima, quindi della funding transaction perché è assicurata da una refunding transaction e in caso di attacco o di problema può recuperare i soldi che ha versato nel canale. A questo punto quello che succede è una serie di commitment transaction, quindi c’è un avanzamento di scambi e di transazioni. Quindi ogni volta che le parti devono spostare i fondi firmano una nuova commitment transaction.

Non serve che la propaghino, ma semplicemente la aggiornano e continuano a scambiarsi i fondi su questo canale. Oggi poi con l’aggiornamento di Bolt si possono creare canali in cui entrambe le parti depositano lo stesso ammontare, quindi non c’è soltanto Alice che deposita, ma sono entrambi. Quindi il processo visto nel dettaglio ricapitolando: Alice crea una coppia di chiavi pubbliche e private e informa Bob che intende aprire un canale e, tramite un messaggio open channell dal protocollo Lightnng Network, quindi comunicando la sua chiave pubblica a Bob. Con il messaggio accept channel bob accetta il nuovo canale e condivide con Alice la sua chiave pubblica, che servirà appunto a creare il terzo passaggio indirizzo MultiSig un due di due, quindi un indirizzo MultiSig creato da due chiavi private di cui servono entrambe per poter spostare i coin che quell’indirizzo stesso detiene. Alice crea una funding transaction da un suo wallet con 100k di Satoshi, ma non trasmette ancora la funding transaction alla rete, prepara una seconda transazione, la commitment transaciton nota anche come refund transaction e invia la signature di questa seconda transazione il transaction id della funding transaction quindi soltanto di transaction id della prima a Bob con il messaggio che dice “funding created” cioè “io ho creato la funding”.

Ora la refund transaction che spende l’output della funding quindi della prima rimandando tutti i soldi ad Alice, ha bisogno di una seconda firma perché questa possa essere effettiva sulla Blockchain. Quindi, dice Bob, non hanno bisogno di scambiarsi intere transazioni perché possono ricostruirle separatamente, ma si devono scambiare le firme della stessa transazione. A questo punto, per confermare infatti Bob deve inviare un messaggio “funding signed” con la sua firma. Ora che i suoi fondi sono assicurati dalla refund transaction Alice può trasmettere la funding transaction. In questo modo, seguendo il protocollo Lightning, l’unico rischio per Alice sarebbe il pagamento delle fee per la refunding transaction nel caso in cui Bob sia malevolo. Dato che Alice fin dall’inizio ha fatto una Refund Transaction e dato che Bitcoin è censorship resistant, non c’è modo per Bob di impedire direttamente ad Alice di propagare la prima commitment transaction anche dopo aver speso effettivamente del bilancio con nuove commitment transaction. Quindi, per evitare questo comportamento scorretto da ambo le parti, il protocollo di Lightning introduce una penalità che rende non logico né profittevole il tentativo. In pratica, ogni commitment transaction è formata anche da un segreto diviso a metà tra le parti.

Prima di firmare una nuova proposta di commitment transaction, il segreto viene condiviso. Questo segreto, se propagato agli smart contract sulla rete di Bitcoin, permette di revocare la transazione e di svuotare il canale. Per questo tutte le commitment transaction hanno un lock time. Per questo, per avere sempre un po di “skin in the game” i canali non possono mai svuotarsi completamente.

Adesso vediamo invece SegWit e Taproot, che sono due aspetti due aggiornamenti che sono stati fatti nel corso del tempo su Bitcoin e che in particolare SegWit hanno reso possibile Lightining network e ha migliorato la possibilità di fare smart contract evolvendo il potenziale di smart contract della rete di Bitcoin. La prima cosa che vorrei fare è una piccola premessa tra hard fork e soft fork in programmazione hard e soft. Comunque “fork” che indica proprio la forchetta come simbolo che parte da un’asticella e poi si divide in varie biforcazioni è proprio quando il codice cambia, quindi, ci sono soprattutto nell’ambito open source, ci potrebbero essere dei fork in cui magari alcuni programmatori iniziano a scrivere il codice in una direzione e altri in un’altra e quindi si crea una biforcazione in una diramazione delle strade del codice. Quindi si parla di fork quando cambia qualcosa all’interno del codice sorgente di un programma.

In particolare, la differenza che c’è fra Hard e Soft è la differenza sull’impatto che questa modifica o questo cambio al codice sorgente ha sul software in produzione, sul software che le persone stanno realmente utilizzando. Quando si parla di hard fork solitamente è una modifica invasiva, è una modifica che non permette retrocompatibilità, mentre quando si parla di soft fork, è una modifica molto più light, studiata per essere retrocompatibile e soprattutto per rispettare anche chi sta magari facendo girare delle versioni del software un po più vecchie. Tipicamente in Bitcoin quello che si fa è sempre un soft fork cioè si cerca di evitare gli hard fork. Gli hard fork ci sono stati nel mondo collegati a Bitcoin, ma non sulla rete Bitcoin. Sono stati degli hard fork, cioè delle copie del codice di Bitcoin per cambiare prese da alcuni gruppi da alcune persone che magari volevano una versione di Bitcoin diversa che poi sono tutte quante morte nel corso degli anni. Però fondamentalmente quelli sono stati casi di hard fork, ma non direttamente al codice di Bitcoin sono stati tentativi di attacco a Bitcoin delle copie di Bitcoin per cercare di portarle sulla visione di 2 o 3 persone in quel momento si erano incastrate su un’idea e volevano a tutti i costi portarla a termine.

Quindi tendenzialmente Bitcoin tende a fare dei soft fork, quindi delle modifiche gentili, più rispettose degli utenti e soprattutto retrocompatibili. SegWit, ovvero Segregated Witness è un soft fork, una modifica all’architettura per le transazioni che permette alle firme delle transazioni di essere salvate in una struttura dati separata. Cioè nell’ambito di un blocco le informazioni venivano raccolte in un certo modo, adesso con SegWit vengono raccolte in un altro modo. Quando si va a generare l’hash di una transazione, prima di SegWit questo hash comprendeva anche i dati delle signatures, cioè la testimonianza, la witness appunto. Con SegWit questo viene spostato e c’è quindi un Merkle Tree, una sezione a parte in cui vengono salvate queste informazioni. SegWit ha dato libertà d’uso, cioè un soft fork, come abbiamo visto tipico e non hard fork quindi ha permesso anche a chi aveva del software obsoleto di continuare a partecipare alla rete senza essere estromesso. Ci sono due tipi di indirizzi introdotti da SegWit. Uno è il SegWit Wrapped, che fondamentalmente è uno smart contract, quindi si utilizza uno smart contract come quello che viene tuttora utilizzato per generare un MultiSig in cui viene appunto creato un pay-to-script-hash (P2SH), quindi viene “wrappato” un indirizzo SegWit e questo è compatibile anche con i wallet vecchi che non sapevano o non sanno o non ci sono aggiornati a SegWit.

E questa è la struttura di un MultiSig questo è l’Hash di un MultiSig, un MultiSig di N chiavi e il SegWit Wrapped che sta dentro un pay-to-script, appunto, è semplicemente un indirizzo per la retrocompatibilità. Quindi, avendo un indirizzo che inizia col tre proprio come un MultiSig, è tuttora compatibile anche a tutti quanti col Wallet che prima di Segwit capivano degli indirizzi MultiSig. Poi c’è invece l’indirizzo nativo, quello che viene introdotto con Segwit e che quindi necessita tutti i software e wallet di un aggiornamento per funzionare. Perché prima questo tipo di indirizzo che inizia con DC1 non esisteva semplicemente perchè l’indirizzo di SegWit nel software non c’era, quello che poi è più conveniente usare. Come funziona SegWit. In seguito abbiamo visto che le firme vengono messe in un albero di Merkle separato, segregato. Quindi le firme che sono arrivate al punto di witness, testimonianze, sono raccolte in un Merkle tree chiamato il Witness Tree. Perché tutto questo? Se noi pensiamo alla Blockchain, all’immutabilità a Bitcoin immutabile, eccetera eccetera, di fatto, però, c’era un problema. Se noi vediamo il transaction I.d. che viene generato da un hash del transaction data quindi dei dati delle transazioni, ci dobbiamo chiedere “ma questo è modificabile?” Di fatto è modificabile perché lo SHA quindi l’hash di un numero che è zero zero uno è diverso dal hash di un numero che è uno. Dal punto di vista, diciamo formale, un valore zero zero uno è uguale a uno, oppure un valore cinque o un valore cinque meno uno, più uno, sempre cinque è nel secondo caso. Ma l’hash di una stringa, di un’informazione data in quel modo è diverso dall’hash quindi questi due non sono uguali. Quindi cosa succede? Era un problema noto come Transaction Malleability. Succede che questo hash di fatto, non è più così immutabile o non lo era prima di SegWit. Questo perché? Avendo nel hash, venendo calcolato anche il dato della firma, quindi della Witness, modificando leggermente la firma, andandola leggermente a manipolare era possibile modificare l’hash, creare un nuovo transaction ID a fronte della stessa transazione e quindi Bob poteva pagare Alice firmando due transazioni e dare ad Alice solo un Transaction ID nascondendo il secondo.

La Transaction Malleability ovviamente, per come abbiamo visto e come funziona l’implementazione attuale di Lightning rendeva Lightning impossibile. Il fatto stesso che Alice debba firmare una transazione che non propaga e poi sulla base di quella transazione e quindi di quello UTXO generarne una nuova e lavorare quindi in questo modo, costruendo una serie di transazioni, anche le altre in mezzo, le commitment transaction, sulla base di un hash che però può cambiare perchè il hash è collegato a un UTXO quindi collegato a una catena di output che vengono spesi, se qualcuno può invalidare semplicemente perché propaga un altro Transaction ID con la stessa transazione questa catena Lighting non poteva esistere e quindi SegWit era effettivamente un prerequisito di Lightning. Un’altra informazione importante legata a SegWit è l’aspetto dell’ “Anyone Can Spend”, cioè all’interno delle informazioni del blocco esiste un campo che si chiama “Post Script Sig” che quando è rappresentato da una transazione di SegWit è vuoto. Quindi fondamentalmente un client che non riconosce SegWit potrebbe vedere quella transazione come “Anyone Can Spend” perché non c’è una firma. Di fatto una transazione è un UTXO, una quantità di coin e può essere spesa da chiunque. Cioè non è veramente così, però può essere vista da un client che non si è aggiornato a SegWit. Questo ovviamente se si è trattato soltanto di FUD (paura incertezza dubbio) nel passato, perché comunque il soft fork di SegWit era stato ampiamente adottato da tutti i miners, c’erano stati segnali di un’adozione e quindi fondamentalmente il nodo che vedeva la transazione SegWit come come “Anyone Can Spend” non avrebbe mai trovato il consenso, non sarebbe mai riuscito di fatto a spendere quella transazione.

Sicuramente una cosa SegWit l’ha fatta: ha incrementato la dimensione del blocco. Di fatto c’è stato un aumento da un megabyte, teoricamente fino a quattro megabyte e anche perché lo spazio occupato dalla signature è stato spostato dal calcolo della quantità. Inoltre, SegWit ha reso possibile dei sistemi di Sidechain e Liquid e dei contratti peg-in e peg-out tipici delle sidechain.

Vediamo invece adesso Taproot. Taproot ha un soft fork che, come abbiamo visto SegWit, è molto più recente rispetto a SegWit e è un soft fork della rete di Bitcoin che migliora la capacità di scripting e anche la privacy e ovviamente riduce anche i costi di fee perché diminuisce lo spazio necessario per effettuare smartcontract anche complessi. Abilita una cosa chiamata MAST, che rende gli smarcontract più efficienti e privati, permettendo di rivelare solo piccole porzioni di un codice di uno smart contract e non tutto lo smart contract. Per esempio, Taproot rende anche distinguibili i canali Lightning da normali transazioni qualora si chiudano in modo consensuale. L’aggiornamento Taproot è formato da diversi pezzi che lo formano e per capirlo vanno visti e compresi individualmente. MAST appunto, Merkleized Abstract Syntax Trees è rappresentato da due aspetti distinti che sono i Merkle Tree e gli AST (Abstract Syntax Trees). Combinando questi due si possono ottenere script molto più complessi, in quanto non serve più ricordare tutto lo script, ma solo una parte di essi Il Merkel Tree è  una specie di albero, avete presente gli alberi delle genealogie che partono da un capostipite e poi si dividono con tutte quante le persone e le famiglie e si allargano come un albero di Natale a cono con la base larga verso il basso. Il Merkle Tree è la stessa cosa però invece che persone nell’albero ci sono hash. Quindi l’hash principale, quello che sta in cima è l’hash radice e poi sotto tutti quanti i vari documenti che sono connessi e rendono possibile la creazione di un Merkle Tree, salvando per esempio in Blockchain soltanto l’hash radice quindi quello in alto, si può di fatto ricavare tutto quanto il documento e dimostrare l’esistenza anche di Petabyte di dati. 

 Abstract Syntax Tree invece è un sistema per catalogare e spezzettare il software, quindi il codice scritto in piccole parti, per poterlo indicizzare bene. Quindi  coadiuvando queste due tecniche quello che si riesce a fare è: nel momento in cui mi serve una parte specifica di elaborazione di un programma, io vado a rivelare sulla Blockchain, quindi a dimostrare attraverso il Merkle tree e l’Abstract Syntax Trees soltanto un pezzetto del mio programma e non tutto quanto il programma.Quando ho bisogno che questo venga eseguito sulla blockchain. 

Un esempio di smart contract: se Maria ha dieci Bitcoin in un indirizzo Bitcoin, può impostare un script che consenta a suo marito di utilizzare quei soldi dopo un po, nel caso che succedesse qualcosa e poi non potesse spenderli. Maria può spendere i Bitcoin che ha su quell’indirizzo in qualsiasi momento, ma se per qualche motivo – passato del tempo, diciamo sei mesi – i Bitcoin sono rimasti sul suo conto, il marito di Maria può farne uso. Anche il marito di Maria, prevedendo ogni situazione, può aggiungere un altro script dove ugualmente, se per qualche motivo non può usare i suoi fondi in quattro mesi, i suoi figli possono avere i soldi. Tutta questa catena di script e condizioni per spendere i fondi richiede molto spazio sulla rete, oltre ad esporre dei dati pubblici sensibili, indipendentemente dal fatto che siano soddisfatti o meno. Prima di Taproot tutte queste informazioni A) dovevano risiedere sulla Blockchain, quindi comunque, siccome Bitcoin è resiliente e cresce in maniera lineare non permette a enormi smart contract enormi programmi, ma solo piccoli, diventa difficile fare cose complesse. E inoltre comunque loro, Maria e il marito, devono esporre tutte quante le loro informazioni sensibili per potersi assicurare una famiglia felice o comunque un passaggio sereno in caso di disastro. Taproot risolve proprio questo problema perché permette di neutralizzare tanto l’hash di una radice di un Merkle Tree dello smart contract e poi, soltanto in caso di necessità, si va a rivelare un’informazione e quindi una porzione del codice di quello smart contract. L’algoritmo delle firme di Schnorr è un’altra componente importante di Taproot, perché è un tipo di firma che effettivamente migliora tantissimo l’utilizzo dei Multisig per esempio rendendo possibile anche  sistemi come Decentralized Autonomous Organization direttamente su Bitcoin perché e non è stata usata prima, anche se effettivamente le Schnorr Signatures esistevano anche quando Bitcoin esisteva semplicemente perché c’era un brevetto e quindi non si potevano utilizzare software open source. Poi, anche se questo brevetto era da poco scaduto e quindi in teoria si poteva usare, però non era stato fatto il test. Siccome era una cosa che era stata brevettata e quindi usata in ambiti chiusi, nessuno nell’ambito open source aveva esperienza e aveva utilizzato molto queste Signatures di Schnorr quindi all’inizio, quando Bitcoin viene rilasciato nella sua prima versione, non utilizza la licenza. Oggi sono state introdotte con l’aggiornamento di Taproot. I vantaggi Schnorr Signature che erano ben visibili adesso li vediamo.

Con un “Pay To Script Hash” e o il P2TR serve ad attivare delle nuove funzionalità di Taproot e del TapScript, sfruttando quindi il potenziale che abbiamo prima di MAST e anche il potenziale delle firme di Schnorr. Esse per intenderci hanno una particolarità. Mentre per esempio se io prima della Schnorr Signature volevo fare Multisig con 1000 indirizzi, 500 di 1000, questa cosa qua era impossibile perché fondamentalmente tutte quante queste firme dentro un blocco non ci stavano e quindi non si potevano creare degli indirizzi complessi, per esempio no, ma soltanto limitati a quelli che potevano essere nel blocco. Le firme di Schnorr, invece, possono essere sommate. Cioè una firma di Schnorr può essere sommata proprio come si fa un’operazione di un numero più un altro. Quindi immaginiamo di rappresentare due firme di Bitcoin con un numero uno e il numero due, uno è il numero N2, e uno è il numero N3 e sono due firme. Con Schnorr si può fare N2 più N3 e si ottiene N5 che ha un’unica firma che occupa lo stesso spazio di una ma ne contiene due. E questo si può fare per n volte per tutte le firme del bisogno, quindi rende molto, molto, molto più versatile la possibilità di utilizzare molte firme e ottimizzando lo spazio richiesto dalla Blockchain.

La non fungibilità degli UTXO è un grave problema per Bitcoin. Purtroppo ogni UTXO è diverso dall’altro, data la storia indelebile che ha la Blockchain. Strumenti di Chain Analysis possono identificare e etichettare gli UTXO. Per questo la privacy è importante. E questo rende Taproot un aggiornamento indispensabile.

Bitcoin si evolve lentamente. È vero, molti dicono questa cosa, per me si evolve molto velocemente, ma non certo alla velocità con cui millantano di evolversi certe shitcoin, ma semplicemente perchè Bitcoin è serio e le shitcoin no. Questo perché Bitcoin è resiliente e poi cerca sempre di essere retrocompatibile.

Qui abbiamo visto degli indirizzi di Bitcoin in questo talk. Il primo indirizzo legacy che inizia con la 1. L’indirizzo rappresenta degli smart contract quindi Multisig e Wrapped Segwit e poi i Native Segwit. In queste slide ci sono anche varie risorse, link che lascio poi a disposizione sul canale o dove volete, le slide che saranno rilasciate a chiunque le voglia e poi le linkiamo in tutti i punti social. Io ho finito, vi ringrazio per l’attenzione e vi ricordo che per qualsiasi domanda, qualsiasi cosa, potete venire sul nostro canale Telegram, che è questo, che vi lascio in sovra impressione, dove siamo contenti di confrontarci, parlare e sentire tutte le domande. Vi ringrazio ancora. È tutto, concludo la trasmissione.