Qui la gente è parecchio contraria a questa soluzione per cui non se ne parla.
... o e' per questo o e' perche' nessuno c'ha capito nulla
![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
Sono abbastanza sorpreso come un argomento del genere e di tale importanza non abbia documentazione in italiano se non le FAQ di bitcoin.org
... pensa io non ho trovato nulla nemmeno nelle faq... stiamo parlando di queste giusto?
https://bitcoin.org/it/faqin generale trovare buona documentazione in italiano e' quasi impossibile almeno per gli argomenti tecnici riguardanti il funzionamento del protocollo.
anche se in inglese credo che queste slide siano comunque molto comprensibili:
https://www.bitcoinhk.org/media/presentations/2016-03-16/segregated-witness/assets/player/KeynoteDHTMLPlayer.html#0io l'ho capita cosi':
semplificando (molto), quando si crea una transazione questa contiene input, output e la signature/firma (della chiave privata) dell'indirizzo che sta spendendo i btc.
queste 3 informazioni vengono date in pasto ad un algoritmo di hash che ne ricava l'id della transazione.
in pratica con il Segregated Witness si permette (ma non si obbliga) che le signature non vengono salvate insieme alle transazioni stesse dentro i blocchi ma spostate in un albero separato.
questo permette ancora di controllare che un blocco contenga le transazioni che dice di contenere, ma non che le transazioni in se siano valide.
l'idea e' che i fullnode continueranno (ovviamente) a controllare la validita' delle transazioni accedendo alle signature che stanno in questo nuovo albero, mentre i light client controlleranno solamente che le transazioni inserite in un blocco siano coerenti con l'hash dello stesso.
per fare un esempio con un lightclient (che non accede alle signature del nuovo albero) potrai controllare che bob abbia effettivamente mandato dei soldi ad alice, ma non puoi controllare che effettivamente bob abbia la chiave privata necessaria a spendere i soldi che ha mandato ad alice; semplicemente si fida che se la transazione sta in un blocco sia valida.
tra l'altro questo funzionamento e' analogo a quello che gia' succede ai lightclient visto che dei blocchi scaricano/controllano solo l'header.
tutto questo comporta i seguenti vantaggi:
- si libera spazio nei blocchi e quindi ci stanno piu' transazioni (da notare che non diminuisce la quantita' di dati da gestire in generale, i dati vengono semplicemente spostati fuori dai blocchi).
- togliendo le signature, si toglie dal transaction id la parte "malleabile" delle transazioni e quindi si risolve il problema del transaction malleability.
- siccome solo una parte dei nodi vorra' scaricare le signature (specialmente quelle dei vecchi blocchi) si riduce il traffico della rete.
.. questa e' la parte piu' macroscopica del SW poi ci sono anche altri cambiamenti minori che portano altri vantaggi.