Soft fork tramite Segregated witness

[ZuonKing]

Sono abbastanza sorpreso come un argomento del genere e di tale importanza non abbia documentazione in italiano se non le FAQ di bitcoin.org

Anche cercando su google e nella parte italiana di questo forum, non ho trovato nulla.

Avete qualcosa da leggere in italiano a tal proposito?

grazie
Zuon King

[Sandro kensan]

Qui la gente è parecchio contraria a questa soluzione per cui non se ne parla. Io invece sono molto favorevole e mi sono letto diversi articoli su questa questione ma tutti in inglese.

[picchio]

Qui la gente è parecchio contraria a questa soluzione per cui non se ne parla. Io invece sono molto favorevole e mi sono letto diversi articoli su questa questione ma tutti in inglese.

Si riesce a dare due dritte affinchè si possa capire +- di cosa si tratta?

[Sandro kensan]

Si riesce a dare due dritte affinchè si possa capire +- di cosa si tratta?

è un sistema per aumentare le dimensioni dei blocchi, aumento limitato e che sposta il problema più avanti negli anni. Si dovrà mettere mano alla limitatezza dei blocchi in modo più deciso, probabilmente con un hard fork. Si è optato per un soft fork perché sostanzialmente faceva paura un hard fork per via delle tante incognite e perché i bitcoin sono giovani e occorre fare esperienza.

In più ma non secondariamente si è cercato il consenso delle parti interessate (i miners asiatici) e questo è stato trovato nel Segregated witness o meglio in un soft fork che è il punto cruciale in cui si sono ritrovate concordi le parti interessate.

Si andrà avanti qualche anno e poi occorrerà rimettere mano al problema. Per questo diverse persone anche importanti propongono soluzioni alternative che hanno a che fare tutte con un hard fork che però genera o può generare due blockchain parallele con eventuale perdita di soldi, discredito e articoli sui giornali.

Il sistema trovato è un compromesso e risolve anche un problema tecnico che non ho per nulla compreso ma che era una debolezza strutturale del protocollo.

Più che una questione tecnica è una questione umana in quanto si confrontano due soluzioni: una più rischiosa e definitiva e un'altra di compromesso, poco rischiosa ma dai benefici limitati nel tempo. Dipende dalla filosofia di ogni uno/a di noi propendere per l'uana o l'altra più che da questioni tecniche. Chi ci rimette soldi, invece, va più con i piedi di piombo e ha scelto la soluzione meno rischiosa.

[leevancleef]

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

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/faq

in 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#0

io 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.

[ZuonKing]

nel link che ho già postato a parte oltre a parlare della vicenda satoshi, ci sono ulteriori interessanti considerazioni sul funzionamento dei BTC e sul soft fork

http://motherboard.vice.com/it/read/perche-e-importante-sapere-chi-e-satoshi-nakamoto